This Week in Security: Iran’s ITG18, ProcMon for Linux, and Garbage Collection Fail

Even top-tier security professionals make catastrophic mistakes, and this time it was the operators at Iran’s ITG18. We’re once again talking about the strange shadowy world of state sponsored hacking. This story comes from the IBM X-Force Incident Response Intelligence Services (IRIS). I suspect a Deadpool fan must work at IBM, but that’s beside the point.

A server suspected to be used by ITG18 was incorrectly configured, and when data and training videos were stored there, that data was publicly accessible. Among the captured data was records of compromised accounts belonging to US and Greek military personnel.

The training videos also contained a few interesting tidbits. If a targeted account used two factor authentication, the attacker was to make a note and give up on gaining access to that account. If a Google account was breached, the practice was to start with Google Takeout, the service from Google that allows downloading all the data Google has collected related to that account. Yoiks.

To Make an Exploit From Scratch, You Must First Invent the Universe

We’ve covered many kernel level exploits in this column, but never have we covered a guide quite like the one just published by Secfault Security. They attempt to bridge the gap between being a developer and an exploit author, walking us through the process of building an actual working exploit PoC based on a Google Project Zero write-up.

ProcMon

ProcMon in action
Image by Microsoft, Licensed MIT

Microsoft is continuing to develop their Linux presence, this time by re-engineering Process Monitor as ProcMon for Linux. A bit of history, Process Monitor is part of the Sysenternals suite, originally developed by [Bryce Cogswell] and [Mark Russinovich], founders of Winternals. Incidentally, they also broke the Sony BMG rootkit story, using sysinternals tools. Less than a year after that story broke, Winternals was acquired by Microsoft, and while [Cogswell] has moved on, [Russonovich] has stayed with Microsoft, and is now the CTO of Azure.

ProcMon is written in C++, and released under the MIT license. It keeps track of the system calls happening on machine in real time, giving a detailed look at the activity of the system. It’s useful for security, debugging, and troubleshooting performance issues. All in all, it’s a really handy tool, and should be a useful part of the sysadmin’s toolbox. The source is available under an OSI approved license, so the various distros should pick up and package ProcMon before long.

Windows Server Containers

Windows Server supports a couple of ways to run processes in containers: HyperV containers, and Windows Server Containers. It’s fairly widely accepted that virtualization based containerization provides a more secure isolation. That is, if a virtualized container is compromised, is far more difficult for an attacker to migrate out and attack the host machine, as compared to a kernel based containerization.

The news is a new way to escape a Windows Server Container. While not encountered as often as on a Linux machine, Windows does support symbolic links. Reading through the deep dive also makes it clear how much modern Windows machines are becoming POSIX machines with a Windows compatibility layer on top. For example, the “C:” directory is actually a global symlink to “\Device\HarddiskVolumeX\”.

If a containerized process could create a global symlink, AKA one that pointed to the root directory, then the container escape would be trivial. As expected, the container security controls don’t allow the isolated processes to create such a symlink during runtime. That said, there is a particular function that can be abused to create the global symlink. The specific function parameters have yet to be disclosed, in order to make in-the-wild exploitation just a bit more difficult.

Password Reset Gone Wrong

The story of a security audit on a website caught my eye this week, put together by [Maxwell “ꓘ” Dulin]. The password reset form is the focus here, and it has a few problems. The first one is a common flaw: the password reset form verifies whether a given email address is in the system. It’s not the worst flaw, but it does give an attacker information — he can guess email addresses, and gets confirmation when there is an account with that address.

The next flaw is a subtle one, the contents of the password reset email are generated using the host sent in the HTTP request. That normally works as expected: A user goes to ourwebsite.com/reset, inputs their email address, and submits the form to generate a password reset request. They get an email with a link back to ourwebsite.com that allows the password reset. An attacker, however, can send a malicious HTTP request to the password reset form, using someone else’s address, and manipulate the Host value. The reset email now points to the injected host. If the user clicks the link in the email, the magic value is sent to host specified by the attacker, who can then go reset the user’s password.

The last flaw [Maxwell] found was the worst of the bunch. The reset token is confirmed when the user first clicks the link sent via email, but it isn’t confirmed when the password is actually updated. You could create your own account, go through the password reset process, and then change the password reset form to point at another user’s account. Because the back-end sees you as already authenticated, it dutifully sets the new password, even if the account specified isn’t yours.

None of us will likely use the little website that this audit was performed on, but the steps described and problems to look for are a good guide for anyone needing doing the same.

Garbage Collection Use After Free

CVE-2019–1367 is an older bug at this point, found being exploited in the wild in 2019, and given a full write-up by Confiant. It’s yet another vulnerability in Internet Explorer’s jscript engine. For a very brief review, jscript.dll is the deprecated IE implementation of Javascript. It’s no longer the default implementation, but can be requested by a web page for compatibility purposes. It appears that jscript.dll is only accessible in Internet Explorer, and neither iteration of Edge support the legacy implementation at all.

This vuln was being actively used by state actors and was a watering hole style attack, where simply visiting the malicious site was enough to compromise. The next page of the write-up goes into the technical details. This is a class of vulnerability that we haven’t covered before. It’s a use-after-free in a garbage collected language.

Garbage collection is the alternative to manually freeing memory when finished with it. One of the advantages is that it is supposed to make use-after-free bugs a thing of the past, so what’s going on here? The garbage collection code in jscript.dll doesn’t properly track the reference count in certain situations. This bug specifically deals with the Array.sort() callback function. Arguments to that function aren’t properly tracked, so the JS instance can be manipulated such that a GC sweep frees an object that will be later accessed.

For the exploit and further analysis of how this flaw was used in the wild, check out part 2 and part 3 of the full write-up.