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