CVE 2015-7547 glibc getaddrinfo() DNS Vulnerability

Posted by jstester007 on March 7th, 2016

Hello w0rld! JUMPSEC researchers have spent some time on the glibc DNS vulnerability indexed as CVE 2015-7547 (It hasn’t got a cool name like GHOST unfortunately…). It appears to be a highly critical vulnerability and covers a large number of systems. It allows remote code execution by a stack-based overflow in the client side DNS resolver. In this post we would like to present our analysis.

Google POC overview

1sts

Google POC Network Exploitation Timeline

draw-io_glibc (1)

Google POC Exploit Code Analysis

First response

 

test

Code snippet

 

alter1

Packet capture snippet

The dw() function calls a “struct” module from python library. According to the documentation, it performs conversion between python values and C structs represented as python strings. In this case, it interprets python integer and pack it into little-endian short type binary data. This is a valid response sent by the “malicious” DNS server when it receives any initial queries. This response packet is constructed intentionally in large size (with 2500 bytes of null), it forces the client to retry over TCP and allocate additional memory buffer for the next response. This also triggers the dual DNS query from getaddrinfo() on the client side, which is a single request containing A and AAAA queries concatnated.

 

Second Response
alter3

Code snippet

 

alter4

Packet capture snippet

This is the second response sent by the malicious DNS server. It is a malformed packet sending large numbers of “fake records” (184 Answer RRs) back to the client. According to google, this forces __libc_res_nsend to retry the query.

Third response
alter5

Code snippet

 

alter5b

Packet capture snippet

 

This is the third response sent by the “malicious” DNS server. It is another malformed packet which is carrying the payload. JUMPSEC researcher has modified the Google POC code to identify the the number of bytes to cause a segmentation fault (possibly overwriting the RET address) of the buffer. It is found that the RET address is being overwritten on the 2079th byte. With the addition of return_to_libc technique, an attacker can bypass OS protection such as NX bit or ASLR and perform remote code execution.

 

Google POC debugging and crash analysis

JUMPSEC has run it through the trusty gdb. It crashes with a SEGMENTATION FAULT which verifies that the DNS response has smashed the stack of the vulnerable client application when running getaddrinfo(). The vulnerable buffer is operated in gaih_getanswer. The entry address has been overwritten with 0x4443424144434241 (ABCDABCD). The state of the register also showing the overflowed bytes.

alter6

SEGFAULT from vulnerable client. RET address is overwritten with “ABCDABCD”

alter7

Backtrack

cropped

Registers

JUMPSEC has also tested it on a few other applications. It was found that the getaddrinfo() function in glibc is commonly used…

alter9

alter10

Iceweasel crashing

Conclusion

The best way to mitigate this issue is to enforce proper patching management. Make sure to update all your systems with the latest version of glibc . If you have any systems exposed on the internet and you want to make sure that this vulnerability is not triggered then the following Wireshark filter could be useful: (DNS.length>2048 to see malformed packets). A DNS response has a maximum of 512 bytes (typically), note that the DNS reply is truncated. Even if the client does not accept large response, smaller responses can be combine into a large one which can also trigger the vulnerability. A possible filter is to monitor the size of the entire conversation as a distinct amount of bytes in total is require to trigger specific responses from vulnerable client and all of them requires more than 2048 bytes.

The above vulnerability can be fixed by patching. If you are running RedHat or CentOS a simple

yum -y update glibc

will update the libc and resolve the issue (remember to restart the service right after the update!).

Reference links

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547

http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html

https://googleonlinesecurity.blogspot.co.uk/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

 

Playing with MS14-060 and MS14-058 [CVE-2014-4113 CVE-2014-4114] : Attacks and Defenses

Posted by XoN on November 10th, 2014

Recently two 0-day exploits were revealed. The first one was given the name Sandworm, however the name convention was mistakenly including the “worm” term as we will see. The second one CVE-2014-4113 is a privilege escalation local exploit for Windows. Sandworm as said, includes the word  “worm” most likely for making the situation more dramatic. A worm is a self-propagating piece of code that does not take human intervention. It is said that Sandworm was used into cyber espionage operations from Russians against NATO, European Union and also against specific industries such as energy sector (by targeting SCADA systems). Vulnerable targets are Windows Office 2010 and 2013.  In order to have a successful attack, someone naive (or convinced!) to execute (open) a powerpoint show file is needed. It is said that CVE 4113 strikes win32k.sys which is the kernel-mode drivers in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012, and allows local users to gain privileges via a crafted application, as exploited in the wild in October 2014.  Win32k.sys is responsible for window management, and any GUI process/thread that will use it. Its related user-mode modules are user32.dll and GDI32.dll. Due to the complex interaction with user-mode applications, there are many problems in Win32k.sys. The exploit was acquired in the wild, and a hacking team called HURRICANE PANDA created it. A null pointer de-reference in win32k.sys is the vulnerability and by abusing the xxxSendMessageTimeout function it is possible to execute arbitrary code.

Attacking

Lets see Sand worm initially… In summary the attack works as follows: a malicious powerpoint show file is sent to victim, victim opens it, then victim connects back to an attacker’s controlled host in order to fetch the payload and finally after downloading it executes it. As it is easily spotted, this attack has many different factors in order to succeed. A single firewall blocking outgoing connections to SMB (Port 445) can stop the attack.

1) Attacker generates the malicious powerpoint file and sends the file to victim. Lets use the metasploit framework for that…

MS14-060 options

MS14-060 options

 

Adding the necessary stuff

Adding the necessary stuff

Keep in mind to escape the “\”.

 

Generating the malicious ppsx

Generating the malicious ppsx

As metasploit informs us, we have to place these files to a shared directory (with public/anonymous access). I had the issue that I was getting prompted for a password (after I was opening the ppsx file). It turns out that some latest versions of Windows are asking for a password even if the folder is publicly available. I changed to Linux world and everything worked fine!

Now… What are these 2 files… First lets see the MtBe.gif file

sandworm gif executable

And what about the aDPN.inf file?

By the way, do you remember the famous autorun.inf files ? These files were responsible for what to be executed when we were plugging a CD-ROM, etc. INF files are also known as Setup Information files (check the wiki page!)

Aha! Renaming!

Aha! Renaming!

 

See the [RxRename] entry… So what it does is that it renames the MtBe.gif file to MtBe.gif.exe file… Why ? Obviously because it will execute it afterwards!

We mount the remote shared dir and we place these 2 files there. We edit the output powerpoint file so it looks more innocent than the “Example / Example” of the default generation [ok I didnt.. but you get the point!] . After we send the file to the victim and we start our handler in metasploit. Patiently waiting…

b00m

b00m

Now lets see our privileges…

Going around WoW64

Going around WoW64

As wee see here the current process is running in the Windows x32 on Windows x64 emulation. That means that if we try to launch a local exploit it will fail saying “Failure::NoTarget, “Running against WOW64 is not supported“”. How to get around this? Easy… We see the processes with “ps” and we migrate to a “native” x64 process.

escaping WoW

escaping WoW

As you see in the picture above we successfully escaped WoW64 and now we can launch our local exploit.

b00m

b00m

 

Defending

Lets take a look at the network activity during this. I will focus on the time that the ppsx file is opening (there is the juicy part ;))

INF file busted

INF file busted

Wireshark shows us that we have a SMB2 Read Response. Right after we see the request file for the .inf file. Hmmm lots of noise…

Downloading the files

Downloading the files

Right after we see the downloading of the files…

And the closing of the files...

And the closing of the files…

And finally the end of the files (notice also the .gif file here)

What else we can see from Wireshark? Lets follow the stream…

Following TCP Stream

Following TCP Stream

Remember this line?

Solutions

Solutions for these 2 vulnerabilities is patching. MS14-058 and MS14-060 are fixing the problems. Here I have to pinpoint that even if a host is vulnerable, by staying behind from a properly configured firewall will be still safe since it wont be able to download the files. This type of malicious files are well known to malware analysts, since they have assigned them as drive-by downloads. The name comes from the fact that at some point the victim host will try to fetch the payload and will execute it right after. From the host perspective in order to mitigate the risk there are couple of choices. Having signatures of the exploit itself could mitigate the exploitation. Also depending on the payload that it will be executed it could be picked up from the AV.