Hey, Apple! All those hackers on the fringes of business in Eastern Europe and North Korea? Somehow the threat of a lawsuit filed by Apple in California doesn’t seem likely to scare them much.
And a bonus story: threat actors find and compromise exposed services in … oh … 24 hours. Fast enough for you?
24 November 2021 – Next time Apple executives argue that they can’t relax rules around their iOS App Store for fear of allowing a malware invasion, let’s remember yesterday, when the company sued Israeli firm NSO in retaliation for allegedly infecting iPhones with spyware. Yes, as secure as Apple claims the iPhone to be, the devices are apparently no match for those with the resources to look for vulnerabilities in its software.
This isn’t news, of course. Apple, like Microsoft and Google, is constantly patching security holes in its software, as news reports demonstrate. The inconsistency between that patch activity and Apple’s security boasts is one the iPhone maker usually prefers not to dwell on. What’s fascinating about Apple’s lawsuit is how it contorts itself to explain away the seeming contradiction that a device that purports to be secure actually isn’t:
“Security researchers agree that [the] iPhone is the safest, most secure consumer mobile device on the market. A recent study found that 98% of mobile malware targets Android devices.”
Translation: No devices are secure, but Apple’s devices are less of a problem than others. Unfortunately, all it takes is one piece of malware to ruin your day – or drain your bank account.
With this lawsuit – which, as The New York Times notes, follows a lawsuit by Meta Platforms against NSO – Apple can add to the pressure on NSO and possibly achieve something.
But what about all those hackers on the fringes of business in Eastern Europe and North Korea? Somehow the threat of a lawsuit filed by Apple in California doesn’t seem likely to scare them. Security vulnerabilities are a fact of life – for owners of iPhones and Android devices. Consumers have to defend themselves by, for instance, not putting sensitive information like driver’s licenses on their phones (much as Apple might want them to). Lawsuits can only do so much. But, of course, that means the consumer is intelligent and … I better stop there.
Moving on …
Researchers set up 320 honeypots to see how quickly threat actors would target exposed cloud services and report that 80% of them were compromised in under 24 hours. Malicious actors are constantly scanning the Internet for exposed services that could be exploited to access internal networks or perform other malicious activity. To know how it is done, how often it is done, and why it is so easy just follow Steve King and Andy Jenkinson on Linkedin. They are my two “go to” cyber guys for everything cybersecurity related.
And Andy, by the way, just published a new book which you ought to put on your Xmas list. It takes the reader on a journey from the terrorist attacks of 9/11 onwards and the massive insatiable appetite, focus and investment by the Five Eyes agencies, in particular the U.S., to build capability of digital eavesdropping and industrial espionage. More details at the end of this post.
To track what software and services are targeted by threat actors, researchers create publicly accessible honeypots. Honeypots are servers configured to appear as if they are running various software as lures to monitor threat actors’ tactics.
In a new study conducted by Palo Altos Networks’ Unit 42, researchers set up 320 honeypots and found that 80% of the honeypots were compromised within the first 24 hours. For those of you familiar with the concepts and protocols, the deployed honeypots included ones with remote desktop protocol (RDP), secure shell protocol (SSH), server message block (SMB), and Postgres database services and were kept alive from July to August 2021. These honeypots were deployed worldwide, with instances in North America, Asian Pacific, and Europe.
And it gets worse. For SSH honeypots which were the most targeted, the mean time for the first compromise was three hours, and the mean time between two consecutive attacks was about 2 hours. Unit 42 also observed a notable case of a threat actor compromising 96% of the experiment’s 80 Postgres honeypots in just 30 seconds.
This finding is very concerning as it could take days, if not longer, to deploy new security updates as they are released, while threat actors just need hours to exploit exposed services.
Do firewalls help? Uh … no. The vast majority (85%) of attacker IPs were observed on a single day, which means that actors rarely (15%) reuse the same IP on subsequent attacks. This constant IP change makes “layer 3” firewall rules (network firewalls) ineffective against the majority of threat actors. And my guess is that’s what all of you have.
What could have better chances of mitigating the attacks is to block IPs by drawing data from network scanning projects which identify hundreds of thousands of malicious IPs daily. However, Unit 42 tested this hypothesis on a sub-group of 48 honeypots and found that blocking over 700,000 IPs had no significant difference in the number of attacks between the sub-group and the control group.
To protect cloud services effectively, Unit 42 recommends that admins do the following:
• Create a guardrail to prevent privileged ports from being open.
• Create audit rules to monitor all the open ports and exposed services.
• Create automated response and remediation rules to fix misconfigurations automatically.
• Deploy next-generation firewalls (WFA or VM-Series) in front of the applications.
Finally, always install the latest security updates as they become available as threat actors rush to utilize exploits for new vulnerabilities as they are published.
KNOW YOUR FIREWALLS!
Discussing firewalls does not rank high on most folks’ lists of ways to have a good time. But if you want to secure modern, microservices-based applications, understanding how your firewall works under the hood is essential. To that end, the following (courtesy of John Morello, Chief Technology Officer at Twistlock) explains one of the important technical nuances of firewalls: the differences between layer 3 and layer 7.
Firewall Basics
In a basic sense, understanding what a firewall does is pretty simple. It blocks certain types of network traffic and allows other types of traffic. In this way, firewalls help to prevent potential intruders from being able to talk to your applications and services, which does much to prevent security exploits (although a firewall is hardly the only security defense that you should include in your security toolset, of course).
But how does a firewall determine which traffic to let in, and which to block? Answering that question requires us to delve a bit deeper into the nuances of how firewalls work—and specifically, firewall layers.
Firewall Layers
When it comes time to tell your firewall which types of traffic are OK to admit and which ones it should block, there are multiple ways to categorize traffic into “OK” and “not OK” categories. Each approach corresponds to a different firewall “layer,” as defined by the OSI model.
Layer 3 Firewalls (Network Firewalls)
One way is to categorize traffic according to IP addresses, port numbers and service protocols. In other words, you could tell your firewall to accept traffic from certain IP addresses while blocking all other traffic (this would constitute a whitelisting strategy). Alternatively, you could blacklist IP addresses that you know to be sources of abuse.
You could make things more granular by configuring your firewall to accept traffic from certain IP addresses only on certain ports, or when the traffic uses a certain protocol.
If you categorize traffic in these ways, you’re operating on layer 3 of your firewall. This is also sometimes known as the network layer. Layer 3 firewalls filter traffic based on the TCP/IP stack. This approach is sometimes also referred to as packet filtering, because you’re essentially allowing and blocking individual network packets depending on where they originated and which ports they want to talk to.
Layer 7 Firewalls (Application Firewalls)
The other common approach to firewall configuration involves layer 7, which is also known as the application layer.
Layer 7 lets you sort traffic according to which application or application service the traffic is trying to reach, and what the specific contents of that traffic are. Rather than simply blocking all traffic on a certain port, you could use an application firewall to accept traffic on that port in general, but block any traffic that contains a known vulnerability (such as a SQL injection attack or a malicious telnet command).
Layer 3 vs. Layer 7
If layer 7 provides the greatest opportunity for advanced firewall configuration, why would we talk about layer 3 at all? The answer is that they’re different tools that mitigate different kinds of risks and it’s not an either/or question. In most cases, you’d use both a L3 and an L7 firewall and the two complement each other.
L3 firewalls make decisions based on a much more narrow set of variables (IPs and ports) than L7 firewalls, which look at a literally infinite amount of unique requests. Thus, L3 firewalls are generally able to have much greater throughput than L7 firewalls. Further, because they address a lower level of the stack, L3 firewalls cover a wider variety of scenarios than an L7 firewall, which has to have protocol-specific logic for handling each kind of traffic flow it protects. L3 firewalls, conversely, simply allow or deny based on source and destination ports, without awareness of the traffic within, and thus work universally across any IP based scenarios.
The lack of protocol awareness, though, is a significant blind spot the L7 firewalls address. Especially as HTTP has become the universal app protocol, attackers are more likely to probe and exploit weaknesses within the app layer. So, if you have just an L3 firewall that allows all traffic to port 80, you’re blind to those risks. An L7 firewall is able to look within the app layer and make decisions regarding whether to allow a request based on what it contains—not just the port it’s trying to reach. This is a more computationally costly operation, but one that provides significantly greater security.
Because of these trade-offs, the best model for most scenarios is to use multiple layers of defense in depth; specifically, have an L3 firewall at the edge that only allows inbound traffic on the specific ports your apps use. Those ports should then be routed to an L7 firewall for deep inspect at the app protocol level. This model leverages the strengths of each approach with the L3 firewall efficiently dropping all packets but those from allowed sources and destined to allowed ports, thus allowing the L7 firewall to focus exclusively on inspecting the content of the requests to those ports.
Conclusion
Ideally, then, you’ll have the ability to use both layer 3 firewall filtering and layer 7 filtering as needed. By being able to filter both at the network level and the application level, you have maximum ability to protect your infrastructure and services against intruders.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Andy Jenkinson just published a new book “Stuxnet to Sunburst: 20 Years of Digital Exploitation and Cyberwarfare“ which takes the reader on a journey from the terrorist attacks of 9/11 onwards and the massive insatiable appetite, focus and investment by the Five Eyes agencies, in particular the U.S., to build capability of digital eavesdropping and industrial espionage. With tens of trillions of dollars moving throughout hundreds of thousands of staff, and many contractors draining the country of intelligence and technical capability, the quest was simple and the outcome horrifying. No one in the world has connected the dots, until now.
From digital eavesdropping and manipulation of the agencies to Stuxnet, this book covers how the world’s first use of digital code and digital certificates for offensive purposes against the Iranians and their nuclear power facilities caused collateral damage. Proceeding to today’s SolarWinds attack, code-named Sunburst, the same methods of exploitation and manipulation originally used by the agencies are now being used against companies and governments with devastating effects. The SolarWinds breach has caused knock-on breaches to thousands of client companies including the U.S. government and is estimated to cost more than one trillion dollars. The monster has truly been turned against its creator and due to the lack of security and defence, breaches are occurring daily at an alarming rate. The U.S. and UK governments have little-to-no answer. The book also contains a chapter on breaches within the COVID-19 sector from research to immunisation and full details on the devastating December 2020 breach of SolarWinds.
I strongly recommend it.