The Log4j Edition
On security, open source, and fallout
Support our daily efforts to make your inbox (and the world) more interesting. Join our paid tier for a nominal feel-good price!
Noah here. In the weekend’s subscriber’s only Executive Edition, I wrote a bit about Log4j, the security issue currently taking the internet by storm. Log4j is open-source software used for logging—capturing the actions that take place in a system. Last week it was discovered that there was a vulnerability in the code that allowed bad actors to run arbitrary code on a server that was using Log4j. This kind of security issue is known as a remote code execution (RCE) vulnerability and is generally very bad. Not surprisingly, you don’t want random people on the internet to be able to tell your computer to do whatever they say.
If you’re looking for a quick explanation, here’s a good one from the Hacker News comment section:
Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bunch of ways to interpolate "variables" into log content. For example something like "Logging from ${java:vm}" will print "Logging from Oracle JVM". I'm not sure but you get the idea. One way to resolve a variable using a custom Java resolver is by looking it up through a remote class hosted in some LDAP server, say "${jndi:ldap://someremoteclass}" (I'm still not quite sure why LDAP comes into the picture). Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file.
Why is this interesting?
We are inundated by stories of huge security vulnerabilities. A few years ago we had Heartbleed, a vulnerability in a security package called OpenSSL, back in April we had the SolarWinds hack and in July we heard about the NSO Group’s Pegasus tool being used to hack the phones of journalists and others.
But there’s something that feels different about Log4j and the vulnerability which most are calling Log4shell and that comes down to complexity. If we look at some of the other recent examples of vulnerabilities that came to public attention most of them were performed by very competent actors. The NSO Group utilized a number of zero-day (never before seen) vulnerabilities to get their spyware through the defenses of company’s like Apple and Facebook. While hacks like these are terrible and there are many measures that could and should be taken to help avoid them, it’s very hard to ensure complete protection of any system from the very best hackers in the world. Look at the lengths the United States and Israel took to hack Iran’s Natanz nuclear facility.
What’s crazy about this Log4j thing is that you don’t need much skill to exploit it. Eric Goldstein, the cybersecurity lead for the US Cybersecurity and Infrastructure Security Agency (CISA) called it an “extremely widespread, easy to exploit and potentially highly damaging vulnerability that certainly could be utilized by adversaries to cause real harm.”
Since I saw the news I’ve been thinking of a 2x2 that looks something like the one below. We’re used to hearing about lots of high-damaging, but hard to exploit vulnerabilities. Stuxnet, which I mentioned above and was used to hack the Iranian nuclear facility, exploited a whole bunch of them, which helped tell researchers the thing was written by professionals. When you hear about stuff that’s easy to exploit it tends to have a fairly minimal blast radius: as annoying as having your personal WordPress hacked can be, it’s still just your personal WordPress. “Notably,” as a Wired article explains, “hackers can introduce the snippet in seemingly benign ways, like by sending the string in an email or setting it as an account username.”
But Log4j is software running across the world, including in lots of servers that are effectively directly accessible by the internet. While most of what folks seem to be seeing right now are crypto miners probing around, we don’t know who knew about it (which governments) or how long the vulnerability has been in the wild (Cloudflare has found examples from the beginning of the month). It’s safe to assume that although it may be easy to exploit, experienced hackers are also very good at hiding their tracks.
In the end, it feels like we’ll be learning the extent of the fallout of this one for a while. (NRB)
[Sponsored link: Atlas Bars are GMO-free and keto-friendly with 15 grams of protein and just a gram of sugar. We’ve tried Atlas and they are very good. Use this link (code WITI20) for WITI readers to get 20 percent off. Get started with the sample pack.]
WITI x McKinsey:
An ongoing partnership where we highlight interesting McKinsey research, writing, and data.
The state of global banking. Thus far, banks have escaped the worst of the pandemic’s economic impact—they didn’t witness any abnormal losses, major capital calls, or “white knight” acquisitions, as in the last financial crisis. There were plenty of effects on the financial-services industry, though: the acceleration of digital banking, the rise of remote work, and the growing importance of sustainability were marked trends. Get a read on the landscape and what can make a difference for long-term performance in the latest edition of McKinsey’s Global Banking Annual Review.
--
Thanks for reading,
Noah (NRB) & Colin (CJN)
—
Why is this interesting? is a daily email from Noah Brier & Colin Nagy (and friends!) about interesting things. If you’ve enjoyed this edition, please consider forwarding it to a friend. If you’re reading it for the first time, consider subscribing (it’s free!).