This Week In Security: Iran’s ITG18, ProcMon For Linux, And Garbage Collection Fail – Hackaday

Even top-tier security professionals make catastrophic mistakes, and this time it was the operators at Irans ITG18. Were 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 thats 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.

Weve 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.

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 Sysinternals 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. Its useful for security, debugging, and troubleshooting performance issues. All in all, its a really handy tool, and should be a useful part of the sysadmins toolbox. The source is available under an OSI approved license, so the various distros should pick up and package ProcMon before long.

Windows Server supports a couple of ways to run processes in containers: HyperV containers, and Windows Server Containers. Its 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 DeviceHarddiskVolumeX.

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 dont 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.

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. Its 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 elses 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 users 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 isnt 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 users account. Because the back-end sees you as already authenticated, it dutifully sets the new password, even if the account specified isnt 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.

CVE-20191367 is an older bug at this point, found being exploited in the wild in 2019, and given a full write-up by Confiant. Its yet another vulnerability in Internet Explorers jscript engine. For a very brief review, jscript.dll is the deprecated IE implementation of Javascript. Its 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 havent covered before. Its 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 whats going on here? The garbage collection code in jscript.dll doesnt properly track the reference count in certain situations. This bug specifically deals with the Array.sort() callback function. Arguments to that function arent 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.

See the article here:
This Week In Security: Iran's ITG18, ProcMon For Linux, And Garbage Collection Fail - Hackaday

Related Posts

Comments are closed.