Tuesday, April 15, 2014

Just one day before of Windows XP end of life, the vulnerability with CVE-2014-0160 was published. A lot of blogs have talked about the OpenSSL vulnerability called "Heartbleed Bug". A lot of security administrators have spent our last days focused on patching this security issue... I believe everything has been already said...

In this post, I'd like to write a brief summary about what has happened with that really interesting and critical topic.

The BUG description

These were some of the sentences written by OpenSSL about the BUG in their web site.

"A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server."

"Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS."

So... Someone could steal information from our servers/clients thanks this bug...

But... what is the heartbeat?

That is what the RFC 6520 says about the heartbeat:

"DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually, such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation, particularly when the application uses unidirectional traffic.  Furthermore, DTLS needs to perform path MTU (PMTU) discovery but has no specific message type to realize it without affecting the transfer of user messages.

"TLS is based on reliable protocols, but there is not necessarily a feature available to keep the connection alive without continuous data transfer."

"The Heartbeat Extension as described in this document overcomes these limitations.  The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately. To perform PMTU discovery, HeartbeatRequest messages containing padding can be used as probe packets, as described in [RFC4821]."

So to avoid renegotiating the secure session continuously (which has a direct impact in the the server performance), Heartbeat was designed to say... "Hey!! Are  you still there?? This session is not finished yet!!!"

How the vulnerability works?

As mentioned above, the security problem resides in the heartbeat. There are hundreds of explanations about this security problem... I've found the picture bellow which describes really well how to take advantage of this vulnerability. It couldn't be explained better.

Click on the picture

POC in the server side

So, are we really able to get 64kb from the memory of a remote server in an easy way? The answer is... YES!!!

Just download the exploit from here and execute it against a vulnerable server and you will see the 64kb from the memory of the server. Sometimes we will get nothing interesting...


... sometimes we will get the usernames and passwords in clear text like you will see in the picture bellow. This image came from a guy who detected that login.yahoo.com was vulnerable to this bug.


I've been testing my vulnerable servers executing the exploit in a loop each second and I was able to get a lot of usernames and password and really interesting information from these vulnerable servers.

Did you think about 64KB of memory RAM weren't enough to steal valuable information?

 POC in the client side

So, are we really able to get 64kb from the memory of a remote client in an easy way? The answer is... YES!!!

Pacemaker is a script written in Python to attempts to abuse OpenSSL clients that are vulnerable to Heartbleed (CVE-2014-0160). When pacemaker.py is executed, it starts to listen in 4433/TCP port by the default. To try to test if a client is vulnerable, just make a connection to this port. If it is vulnerable, you will see a memory dump of 64kb from your client like in the picture bellow.

Example: wget -O /dev/null https://google.com https://localhost:4433


If the client is not vulnerable,  the tool will print something like you can see in this image.

Affected versions

Servers

Any server using OpenSSL 1.0.1 through 1.0.1f (inclusive) is vulnerable.

These versions are not vulnerable.
  • OpenSSL 1.0.1g
  • OpenSSL 1.0.0 branch
  • OpenSSL 0.9.8 branh

Be aware with appliances which have OpenSSL installed like VPN-SSL devices, Firewalls, etc... They could be vulnerable too. Here you can get more info about some of them.

Clients

The list bellow will show you some vulnerable clients tested by Pacemaker.
  • MariaDB 5.5.36
  • wget 1.15 (leaks memory of earlier connections and own state)
  • curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
  • git 1.9.1 (tested clone / push, leaks not much)
  • nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
  • links 2.8 (leaks contents of previous visits!)
  • KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
  • Exim 4.82 (outgoing SMTP)

What should I do?

  1. Detect all your vulnerable servers.
  2. Upgrade your OpenSSL to 1.0.1g version.
  3. Your private keys could have been stolen. Acquire new key certificates, revoke your old ones and install the new ones.
  4. The password of your users could have been stolen. Force them to change them.
  5. Inform your customers if you have been vulnerable.
  6. Beware of the inevitable phishing campaigns.
  7. Deploy signatures in your IDS/IPS to detect how many times you are been attacked.
  8. Detect if you have been compromised.

The OpenSSL Bug timeline

04/07/2014 17:30 UTC It was published the security issue by OpenSSL here.

04/07/2014 18:00 UTC The website "Heartbleed.com" was published.

04/07/2014 19:00 UTC OpenSSL released a new version "openssl-1.0.1g".

04/08/2014 Filippo Valsorda published an open source Heartbleed test

04/09/2014 The exploit "OpenSSL TLS Heartbeat Extension - Memory Disclosure - Multiple SSL/TLS versions" was published.

04/09/2014 The module for Metasploit appeared.

04/09/2014 A script for Nmap was released.

04/09/2014 A stable version of Pacemaker was published.

04/10/2014 The website reverseheartbleed.com was created.



Posted on Tuesday, April 15, 2014 by Javier Nieto

No comments

Monday, April 14, 2014

A few days ago I read this post: WinRar File extension spoofing ( 0DAY ). Here, the author describes for example, how to create a ZIP file with a file inside it which has a JPG extension but when it is opened directly from WinRar, an EXE file is executed.

This vulnerability effects Winrar v4.20 and others could be affected.

In this post, we will create a ".bat" file which will execute a ping command against a Google server (you should think about doing evil actions...), it will be compressed in a ZIP format and using the Hex Editor, we will change the extension to a ".pdf" within the compressed file. When the user opens it, a ".bat" file will be executed instead of opening the "fake" PDF.

These are the steps to follow.

  • Create the ".bat" file. You are able to use ".vbs", ".exe" or whatever... A hacker would use their own malware... In our proof of concept I've used a ".bat" file with the name "Best Security Tools 2014.bat".


  • Compress the file in a ZIP file using WinRar.


  • We can see our file with the extension".bat" inside the ZIP file.


  • If you open the the ZIP file with XVI32 you will see the name of the file twice inside the compressed file.


  • Now, we need  to change the second one. I've renamed the file to ".pdf" and I've saved it.


  • If we open the ZIP file again, we can see a file with a PDF format...


  • ... but if we open it directly from the Winrar, the .bat file is executed...


But if you uncompress the file into a folder, you will see the real file "Best Security Tools 2014.bat" instead of the "fake" file "Best Security Tools 2014.pdf".

So, I think there is nothing more to say about the capabilities this technique has. Imagine mixing this technique with the one used in the Siesta Campaign...


Posted on Monday, April 14, 2014 by Javier Nieto

2 comments

Tuesday, April 08, 2014

Introduction

After 12 years, support for Windows XP ends today, April 8, 2014. That means there will be no more security updates or technical support for Windows XP. So XP has officially died but millions of computers with this operating system installed are still "alive" and will be unprotected against new threats from right now, these are the Zombies-XP. Even thousands of ATM's and other critical infrastructures will be using this OS for a while, nobody knows how long...

And what is the advice from Microsoft? We have two options.

1. To upgrade to a newer Windows operating system like Windows 7 or Windows 8.1.
 
2. "If your current PC can't run Windows 8.1, it might be time to consider shopping for a new one."


Sure, we should upgrade to the lastest Windows OS. If our hardware doesn't support it, we should buy a new computer or hundreds in the case of some companies and install Windows 8.1, working hard to transfer all data from one computer to the another, teach the users to use Windows 8.1, etc... Or maybe it is a great opportunity to move to a free Linux operating system, but that is another issue...

This post is focused on users or companies who are not allowed to upgrade to the lastest Windows OS for different reasons like not being able not afford to buy new computers, to have old software which is not capable of runnig in other OS, to not have staff enough to perform the upgrade, etc...

The main threats we need to deal with

First of all we need to keep in mind the attack vectors we need to fight with.

  • Browser-based attacks. I think these attacks could be the most common attacks at this moment. A website could take advantage of a web browser vulnerability just by visiting it. Also, a website could exploit a plugin enabled in the web browser, like Java or Adobe plugins, in the same way.

  • Network Exploits. New worms could be designed to exploit the Windows XP services running in a computer. Now, they are unprotected so the same worm could work in the future after being discovered.

  • Social Engineering techniques. These techniques try to trick a user into opening a link in an email or open an attachment supposed to be a PDF file or whatever "legitimate" file to infect a machine. Look at the case of the Siesta Campaign.

These attacks vectors are common to other OS, but in this case it is really dangerous if we use one which will not have security updates in the future. We will be vulnerable against ZeroDay threats (that is common to all OS) and known threats. Without having security updated we can't fix the previosly mentioned.

Suggested solutions

Here, I will suggest some advice to try to keep your environment more secure using Windows XP.

  • Most antivirus software manufacturers plan to support Microsoft XP until at least April 2016. So try not to select one which stops supporting XP before that date.

  • Choose a web browser with a long-term support plan like Google Chrome which extends the support for XP users until April 2015. On the other hand, Mozilla Vice President said: "We have no plans to discontinue support for our XP users", so consider using this browser too.
 
  • Try not to use plugins in your browser like Java, Adobe Reader, Adobe flash... but if you need them, be sure they are updated (if there are updates available). I use this site to check if my plugins browser are updated.

  • Don't use not administrative accounts. Most of exploits target desktop software (like web browsers and the plugins we mentioned above) are mitigated if the user account is a standard user.

  • Isolate your Windows XP computers in multiple subnetworks behind your network firewalls. That is really important because your XP is already vulnerable and when it is infected, it will be used by hackers to pivot to other systems in your network to try to get access to your data and network resources.

  • Monitor these isolated networks to find suspicious activities. Monitor your network traffic to look for possible command and control connections, an increase of network activity, internal probing techniques, brute force attempts from these networks, etc...
  • Limit the access to the Internet. It is really important not to give full access to the Internet to your users. You can use proxy rules or URL filtering in your firewalls devices. Just give access to sites which are needed to work. We want to avoid websites with exploit kits or other kinds of attack. Yes, I know, legitimate sites are hacked and begin to spread malware like the case of the attack to php.net but we need to have less risk by limiting the access to other sites. 

  • Teach your users to be careful. Every user could be targeted for attack using social engineering. No matter the position of the employees, each computer is a good entry point to pivot to your network. Advise them to check and be suspicious of each email they receive. If they have doubts, they must ask the security department.


Posted on Tuesday, April 08, 2014 by Javier Nieto

No comments

Wednesday, March 26, 2014

Introduction 

A few weeks ago Trend Micro published in their blog the post below: The Siesta Campaign: A New Targeted Attack Awakens. Here they share their research about a targeted attack suffered by all kinds of industries: Energy, Finance, Health care, Public administration... Some days after that, FireEye published in their blog a post called A Detailed Examination of the Siesta Campaign where they accuse APT1 group or another group that uses the same tactics and tools as the guilty party of these attacks.

Thanks to Trend Micro has shared the malware sample's checksum of one variant, I've been able to get a copy of it to get deep into this issue.

Spear-Phishing and Social Engineer Techniques

It is said (in both posts) that this campaign began with an spear-phishing email with links to archives. The file was named "Questionaire Concerning the Spread of Superbugs February 2014.exe" and it was compressed in a ZIP file hosted in a remote server.

I guess that the attackers used the same technique described in APT1 report written by Mandiant. The file could have a PDF extension but the file name actually includes serveral spaces after “.pdf” followed by “.exe”, the real file extension. In the picture bellow you will see the file that looks like a PDF file.
 

If we change to detail view we will see a PDF file...


... but it actually is not a PDF file... It looks like a PDF but it is an executable file...


That is the way this file will be showed in the Desktop. That really seems a PDF file for a untrained eye.


When we run what appears to be a PDF file, the executable drop a real PDF file and it is opened... The normal user could thing that nothing weird has happened... The user received and e-mail with a PDF and now it is already opened...


... but it drops another executable in the background called UIODesrvr.exe. This file is the real malware.


If we look at all process running in our machine, we will see that this malware is being executed.

Brief Malware Analysis

That file was compiled at 2014/02/19.


The first thing the malware does is to connect to www[.]skyslisten[.]com which seems to be the C&C server. This server isn't currently available.


The User-Agent used by the malware is "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0)".


We can see in our IDA that the first thing the malware does is to check if that code ">SC<" is written within HTML code at the domain mentioned above. If it exists, then it tries to locate some commands written in the web server to be executed. According to Trend Micro, these are the commands used in by this malware.

HTTP code
prefix: “>SC<”

Commands
“run1” open a remote shell
“run2” pipe shell commands from URL1
“run3” pipe shell commands from URL2
“http” pipe shell commands from C2
“x_” sleep for specified number of minutes



This is the typical behavior of a backdoor to begin to start with a lateral movement.

Tracking the attacker

As we said before, the domain www[.]skyslisten[.]com seems to be the C&C server. The picture bellow will show you who registered this domain.


This guy registered microsofthomes[.] com. FireEye says in their report that this  domain is directly connected with the last one mentioned above.

The picture bellow will show you some domains registered by this guy. Only five domains from more than a total of roughly 17,000 domains registered with this same email address said by Trend Micro.

Conclusion

When we talk about APT or Targeted attacks, examples of well-known sophisticated Malware like Stuxnet, Flame, Careto and security breaches suffered by companies like Google, RSA, Adobe, Apple came to my mind ... But as we have seen, it is not necessary to develop a sophisticated malware to perform a Targeted Attack. Obviously, the most sophisticated attack will be most successful...


Posted on Wednesday, March 26, 2014 by Javier Nieto

1 comment

Monday, February 17, 2014

Cuckoo v1.0 was published some months ago but some time has passed since I've had time to install it with my friend cor3dump3d, who has saved me a lot of time...

I have seen some new valuables features in this release. Maybe I will write a post in the future about it but for now, I am going to show you how to avoid to Cuckoo being detected by malware.

It is a trend that the malware uses anti-virtualization techniques in order to avoid being analyzed by Sandboxes like Cuckoo. I've noticed a rise in the malware techniques which use this capability. The modern malware could change their behaviour if it detects that it is being executed in a virtual environment. If you already use Cuckoo to analyze your samples, you also can appreciate other techniques like the detection of debuggers and forensics tools.


We want to maintain our virtual machine hidden from the malware samples, for this reason, we will modify our Sandbox to achieve our goal.

Detecting Virutal Machines with Pafish

A year ago I read here: Hardening Cuckoo Sandbox against VM aware malware that Alberto Ortega had developed a new tool named Pafish. This tool can be executed in a Windows OS and it will detect if it is running in a virtual machine. Some months ago, it was published in the same blog that this tool had been used by some malware developers to add it to their malware in order to detect if the malicious program was running in a virtual environment to change its behaviour. In the link below you have a great post about it: How public tools are used by malware developers, the antivm tale

So we are going to use this free tool to check if our virtual machine could be detected by some anti-virtualization techniques. The tool is available in the link below.


After executing Pafish, we can see the picture below which shows us that Pafish detected that the hard drive has less than 50GB storage. It is just a recommendation that if you are able to give more storage to your virtual machine, just do it!!! Do you know someone who has a computer with less than 50gb? I don't and for this reason, the malware could suspect that it is being run in a virtual environment.


In the picture below you will see how Pafish has detected the Register Keys related with VirtualBox.


This tool creates a pafish.log which contain these lines.
[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] Sandbox traced by checking disk size <= 50GB
[pafish] Hooks traced using DeleteFileW method 1
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 "Identifier"
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\Description\System "SystemBiosVersion"
[pafish] VirtualBox traced using Reg key HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\Description\System "VideoBiosVersion"
[pafish] VirtualBox traced using file C:\WINDOWS\system32\drivers\VBoxMouse.sys
[pafish] End

Hinding our Virtual Machine

I was reading some interesting blogs when I discovered this entry: Installing and hardening the latest Cuckoo Sandbox on Gentoo Linux which saved me a lot of time.

Hubert Kromer has created a modified cuckoomon.dll to avoid being detected by the malware and he shares it with us here.


You only need to replace the original one by the modified DLL in this path:
/path/to/cuckoo/analyzer/windows/dll/cuckoomon.dll
When this DLL is replaced (you don't need to restart Cuckoo) just send to Cuckoo Pafish.exe again. You can see the differences between using this DLL and using the other one.


We can see in the Pafish.log file that our Sandbox is still be traced  but as you can see, we will be able to avoid detection in the majority of traces that we were detected before.
[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] Sandbox traced by checking disk size <= 50GB
[pafish] Hooks traced using DeleteFileW method 1
[pafish] End

Now, we need to figure out how we can avoid being detected by malware by not using the mouse in our automatic analysis. If you have some info about that, just let us know!!!

Posted on Monday, February 17, 2014 by Javier Nieto

5 comments