Apache Log4j and IoT

Yes, this is yet another blog article on the vulnerability in the Apache Log4j Java-based logging framework, which was first disclosed (CVE-2021-44228) in Dec 9, 2021. Many brave souls spent their weekend patching their servers and other computers to version 2.15.0. And then, a new vulnerability was found in its replacement (CVE-2021-45046), which requires an upgrade to 2.16.0.

And then 2.16.0 did not solve CVE-2021-45105 so we are now (Dec 19) on 2.17.0.

There are right now many great articles by brilliant people on how the attack takes place, what you can do to detect whether your (Apple, Linux, Windows) systems are affected, and how to prevent it. Therefore, this article will do the unthinkable and instead focus on the security and privacy impact on Internet of Things (IoT) devices.

The Problem

According to IoT Analytics, the global number of IoT devices should be around 12.3 billion. That is a lot of coffee machines, fridges, Nest thermostats and cameras, Amazon Ring, smart televisions, insulin pumps, and talking toasters. And some of them are voice operated thanks to Alexa, Cortana, and Siri. How many of them have their firmware/OS updated once deployed? Is that trigger by the user, run on a schedule in the device, or pushed from the mothership to the appliance? How many of them can have their firmware/OS updated to begin with? And, so we can keep this on topic, how many of them use log4j?

Even without this new vulnerability, IoT devices are not known for their initial security settings or capability to be upgraded to remain secure. Nest is actually one of the better ones, but attacks to it have been documented, including simply hacking into the users' accounts to identify the patterns and find the best times to rob their houses (ideally when you are away for a few hours).

Some claim the strong point of most of the IoT devices is they are connected using WiFi, as if that makes it more secure than being connected using ethernet or fibre. In other words such a device "is completely a wireless device that has a low tendency for vulnerabilities." That assumes the wireless network is impervious to attacks; the reality is not the case. First it does not require the attacker to be physically in the location; just being in the parking lot suffices. Second, it gives the upper edge for patient criminals. Finally, someone can break into the website used to manage these devices and push some malicious payload which can help scan the target network/traffic in search of vulnerable devices. The log4j one is but another vulnerability in their arsenal.

Privacy Impact

The kill chain here is business as usual:

• Get a foothold through an IoT device
• Upload shellcode and/or packages to this device
• Use device to can the network to learn the way of the land and to locate more potential targets.
• Rinse and repeat until finding useful data, be that in the form of files and passwords or just enabling microphones and cameras.

The attacker who is there just for the joy of breaking in will then post captured pictures and videos, and send messages back to the IoT device owners as shown in the previous video. The more malicious attacker will harvest as much personal data -- account info for other services, medical info, videos and sound recordings -- as possible that not only compromises the current victim but also future ones known by current target.

"So, where's the privacy impact?" you may rightfully ask. When our criminal friend successfully exploited the vulnerability, he committed a security breach. Now, when he then stole medical records, credit card info, account information, and even monitored the house in the last paragraph, he commited a privacy breach; and that is where the money is.

Let's revisit the video I linked earlier. The Merriam-Webster dictionary defines privacy the quality or state of being apart from company or observation. That attacker can view and listen to everything that family does in their home, so per definition this family's privacy is compromised.

Let's now look at it from a business standpoint: the fines imposed by GDPR for exposing personal data from a person (GDPR calls that a Natural Person) is up to 20 million Euros or 4% of the annual global revenue (table stolen from a previous article). I am not saying it will be always that much, but the data protection authority will not be pleased if this was due to devices that were designed so they cannot be updated.

But don't take my word for it. We already mentioned how serious the GDPR is about data breaches. It is now alone; the NIST is also concerned about the IoT security, and created a program to help governments, industry, academia, and consumers become aware of the issue and minimize its impact.

Useful resources

• GDPR explanation of the impact of a data breach to a natural person and, as a result, the importance of notofying the relevant supervirsory authority.
• Log4j Vulnerability guidance from the Cybersecurity & infrastructure Security Agency (CISA), including a link to their github repo.
• Microsoft response to Log4j. You may want to save it since Microsoft tends to delete doc pages and blogs.
• More Microsoft guidance.
• The greatest light of hope that rose above this sea of dispair: the creation of a website for log4j memes

Capturing Network Traffic in Windows Without Wireshark

One of the things that drives me nuts in the Windows community, articles found in help web sites included, is the idea that to solve any problem you need download something and run it. And ideally something off a shady site that must be run in Admin mode. Packet capturing is one example.

Yes, I do know of Wireshark, I like it a lot and think it is a brilliant program; the fact you can run it in Linux, OSX, and Windows is a nice touch. But, like everything else it has its place. So, where is that in my opinion? I think it is great for:

• Packet inspection in a nice visual way
• Following all the packets that make a stream. Ex: if you found a file being transfered, you can find every single packet involved.
• Packet filtering. yes, you can do that in tcpdump, but doing it visually and colourfully is so much nicer. Looking for a rogue DNS in a haystack of data? Just tell wireshark to mark any DNS response in purple!
• The massive list of non-TCP/UDP traffic (say, USB) it can handle.
• Deploying a tap or switch port mirror.
• Lots
• Having in your handy pentest/security laptop.

Now, where do I think it should not be used? Servers. The way I was taught in kitty school is that you should only install in the server the programs you need to provide the services said server is supposed to offer (and to secure that). For instance, some good explaining is required to justify running a VPN service in a web server specially in this age of containers. About normal packet capturing, I understand the occasional need for that in a server, but why installing wireshark in it? If its operating system is Linux, there is a perfectly good tcpdump avaiable: you install it, do what you need, and then remove it after the task is done; there is no need for leaving it in the server "just in case." But, what about a Windows server? There is no tcpdump port on it, so wireshark is the logical alternative.

Or is it? What if I told you Windows has a built-in solution?

Enter netsh trace, which allows you to record network traffic without downloading an extra program. It is not as sophisticated as tcpdump but if all we want is to capture packets, it work just fine. It is command line, but I think we can handle that. Here are the avaiable options:

PS C:\Users\user> netsh trace ?

The following commands are available:

Commands in this context:
?              - Displays a list of commands.
convert        - Converts a trace file to an HTML report.
correlate      - Normalizes or filters a trace file to a new output file.
diagnose       - Start a diagnose session.
dump           - Displays a configuration script.
help           - Displays a list of commands.
show           - List interfaces, providers and tracing state.
start          - Starts tracing.
stop           - Stops tracing.

To view help for a command, type the command, followed by a space, and then
 type ?.

PS C:\Users\user>

Recording

The way I usuall start recording network traffic is (and, yes you need to run it as an Admin)

netsh trace start persistent=yes capture=yes tracefile=packets.etl

Where

• persistent: Keep on logging after a reboot. Default is persistent = no
• start: Start packet capture. To stop it, netsh trace stop.
• tracefile: Is the name (and path) of the file the packets will be saved to. If you just enter the filename, it is saved in the same directory/folder you ran the command from. It is comparable to the -w flag in tcpdump. I strongly suggest to save this file somewhere only you (or the Admin) has access to; there are very few times when having a packet capture file available for all makes sense.

Other useful options:

• maxsize: max size of log file before it gets overwritten. maxsize=250 (MB) is the default; if you set maxsize = 0 it would not stop filling it up until running out of disk space (unlimited).

Inspecting

When you finish capturing you will notice that you now have two new files:

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/24/2017   3:59 PM         650033 packets.cab
-a----        4/24/2017   3:58 PM         524288 packets.etl

For this discussion we will only care about packets.etl. Next step is to take the file out of the server to a system where we can analyze it with wireshark (the right tool for the job). Unfortunatelty Wireshark as of the time this article was created (April 2017) can't read a .etl file; more info on a wireshark bug report that started on 2011 and was last updated 2 years ago. The only way I know to convert is using the Microsoft Message Analyzer, which means you need to install it, import packets.etl, and then export it (Save As->Export) as a .cap file. You could argue that if we have Microsoft Message Analyzer, there is no reason to add wireshark, but while I know how to use wireshark I only know how to use the Microsoft product to convert the packet to a format wireshark can use. I do wish there was a way to do this step from the command line; if someone knows, do post in the comments.

What about real time monitoring?

Do you remember the part about tap or switch port mirror? That is what I would do before putting wireshark in the server. If you have to install wireshark in the Windows server, do keep track of the extra programs you also need to install and ensure they are all removed after you are done.