Top 10 Free Websites to Learn Hacking this 2018

1. KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.
2. Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
3. HackRead: HackRead is a News Platform that centers on InfoSec, Cyber Crime, Privacy, Surveillance, and Hacking News with full-scale reviews on Social Media Platforms.
4. Phrack Magazine: Digital hacking magazine.
5. Exploit DB: An archive of exploits and vulnerable software by Offensive Security. The site collects exploits from submissions and mailing lists and concentrates them in a single database.
6. Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
7. The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
8. SecTools.Org: List of 75 security tools based on a 2003 vote by hackers.
9. Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
10. Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.

Linux Command Line Hackery Series - Part 6

Welcome back to Linux Command Line Hackery series, I hope you've enjoyed this series so far and would have learned something (at least a bit). Today we're going to get into user management, that is we are going to learn commands that will help us add and remove users and groups. So bring it on...

Before we get into adding new users to our system lets first talk about a command that will be useful if you are a non-root user.

Command: sudo
Syntax: sudo [options] command
Description: sudo allows a permitted user to execute a command as a superuser or another user.

Since the commands to follow need root privileges, if you are not root then don't forget to prefix these commands with sudo command. And yes you'll need to enter the root password in order to execute any command with sudo as root.

Command: useradd
Syntax: useradd [options] username
Description: this command is used for creating new user but is kinda old school.
Lets try to add a new user to our box.
[Note: I'm performing these commands as root user, you'll need root privileges to add a new user to your box. If you aren't root then you can try these commands by prefixing the sudo command at the very beginning of these command like this sudo useradd joe. You'll be prompted for your root password, enter it and you're good to go]

useradd joe

To verify that this command has really added a user to our box we can look at three files that store a users data on a Linux box, which are:

/etc/passwd -> this file stores information about a user separated by colons in this manner, first is login name, then in past there used to be an encrypted password hash at the second place however since the password hashes were moved to shadow file now it has a cross (x) there, then there is user id, after it is the user's group id, following it is a comment field, then the next field contains users home directory, and at last is the login shell of the user.

/etc/group  -> this file stores information about groups, that is id of the group and to which group an user belongs.

/etc/shadow -> this file stores the encrypted password of users.

Using our command line techniques we learned so far lets check out these files and verify if our user has been created:

cat /etc/passwd /etc/group /etc/shadow | grep joe



In the above screenshot you can notice an ! in the /etc/shadow, this means the password of this user has not been set yet. That means we have to set the password of user joe manually, lets do just that.

Command: passwd
Syntax: passwd [options] [username]
Description: this command is used to change the password of user accounts.
Note that this command needs root privileges. So if you are not root then prefix this command with sudo.

passwd joe



After typing this command, you'll be prompted password and then for verifying your password. The password won't show up on the terminal.
Now joe's account is up and running with a password.

The useradd command is a old school command, lets create a new user with a different command which is kinda interactive.

Command: adduser
Syntax: adduser [options] user
Description: adduser command adds a user to the system. It is more friendly front-end to the useradd command.

So lets create a new user with adduser.

adduser jane



as seen in the image it prompts for password, full name and many other things and thus is easy to use.

OK now we know how to create a user its time to create a group which is very easy.

Command: addgroup
Syntax: addgroup [options] groupname
Description: This command is used to create a new group or add an existing user to an existing group.

We create a new group like this

addgroup grownups



So now we have a group called grownups, you can verify it by looking at /etc/group file.
Since joe is not a grownup user yet but jane is we'll add jane to grownups group like this:

addgroup jane grownups



Now jane is the member of grownups.

Its time to learn how to remove a user from our system and how to remove a group from the system, lets get straight to that.

Command: deluser
Syntax: deluser [options] username
Description: remove a user from system.

Lets remove joe from our system

deluser joe

Yes its as easy as that. But remember by default deluser will remove the user without removing the home directory or any other files owned by the user. Removing the home directory can be achieved by using the --remove-home option.

deluser jane --remove-home

Also the --remove-all-files option removes all the files from the system owned by the user (better watch-out). And to create a backup of all the files before deleting use the --backup option.

We don't need grownups group so lets remove it.

Command: delgroup
Syntax: delgroup [options] groupname
Description: remove a group from the system.

To remove grownups group just type:

delgroup grownups



That's it for today hope you got something in your head.

Related links

1. Pentest Xss
2. Pentest Report Generator
3. Pentest Services
4. Pentest Nmap
5. Pentest Linux
6. Hacking Health
7. Hacking Jailbreak
8. Hacker Wifi Password
9. Hacking Resources
10. Hackerone
11. Hacker Software
12. Pentest Windows
13. Hacking Simulator
14. Hacking Gif
15. Hacking Wifi
16. Hackerx
17. Hacking For Dummies
18. Pentestgeek
19. Hacking

Networking | Switching And Routing | Tutorial 3 | 2018

Welcome to my 3rd new tutorial of networking (Routing and Switching). In this blog you will able to watch an interesting video about basic device navigation such as changing device (router or switch) name, configuration of login password, configuring a device information, router IP addresses and many more.

What is router?

Router is a network layer device which is the 3rd layer in the OSI model which is used to communicate different networks. It is an intelligent device fixed at the boundary of network that connects to other networks and responsible for end to end delivery of the packet that requires an IP address which is known as the logical address which is the basic identity of the device just like our identity card number or roll number and so on, for the identification of source and destination devices. Router is the gateway of the network having two interfaces such as inbound and the outbound interface through which the traffic comes in from different networks and comes out traffic to the different networks.

What is an IP address?

Internet protocol (IP) address is a numeric label given to each and every device in the network for the identification of the device just like our roll numbers in collages, universities which identity each and every student uniquely everywhere. So same concept here, it is a logical address which is used whenever the device want to communicate outside the network that means to another network.

What is Switch?

Switch is basically layer 2 device, which is used to connect two or more than two devices with each other in the same network. It is an intelligent device which doesn't allow the broadcast. It requires Media access control (MAC) address to communicate within the network. Now let's move to the video for further.

 VISUAL FEATURES 

This tool has a visual crawler. Normal crawlers doesn't parse the ajvascript, this tool does. The visual crawler loads each link of the web site, rendering the html and executing all the javascript as a normal load, then the links are processed from he DOM and clicked.
A visual form cracker, is also available, althow is experimental and only works on some kind of forms.


 SCANNING FEATURES

The web-fu's portscanner, has a database of a common web ports, like 80,81,8080 and so on.
The cracker module, can bruteforce web directories to find new attack vectors, and can fuzz get and post parameters for discovering vulns, and also crack passwords. There are 9 preloaded wordlists, and you can also load a custom wordlist. Prefilters, falsepositive reductor and render will be helpful. The scanners support SSL, if the website can be loaded in the chrome, can be scanned by web-fu.


ENCODERS & DECODERS

The supported encoders and decoders are: base64, urlescape and urlencode


OTHER FEATURES

A web notepad is available, saving the information on the browser localStorage, there is one notepad per site. A cookie editor is also very useful for pentesting. The inteceptor, is like a web proxy but from the inside of the browser, you can intercept a request There is also a session locker and a exploit web search.


CHROME STORE 
Here is the link to the chrome store, the prize is about one euro, very cheap if you compare with other scanners: Web-Fu on Chrome Store


 With webfu, you will do the best web site pentest and vulnerability assessment.

More articles

1. Hacking Games
2. Hacking Books
3. Pentest Windows 7
4. Hacker Prank
5. Pentest With Kali
6. Hacking Online Games
7. Hacking Apps
8. Hacking Typer
9. Hacker News
10. Hacking Ethics
11. Hacking Google

NcN 2015 CTF - theAnswer Writeup

1. Overview

Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
This binary is writed by Ricardo J Rodrigez

When it's executed, it seems that is computing the flag:

But this process never ends .... let's see what strace say:

There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
Maybe we can think about an encrypted flag that is not decrypting because of the lock.

This can be solved in two ways:

• static: understanding the cryptosystem and programming our own decryptor
• dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)

At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.


2. Static approach

Crawling the xrefs to the futex, it is possible to locate the main:

With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:

The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.

we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

The print_key function, do the xor between the key and the flag_cyphertext byte by byte.

And here we have the seed and the first bytes of the cypher-text:

With radare we can convert this to a c variable quickly:

And here is the flag cyphertext:

And with some radare magics, we have the c initialized array:

radare, is full featured :)

With a bit of rand() calibration here is the solution ...

The code:
https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c

3. The Dynamic Approach

First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:

There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.

Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

Ok, just one byte patch,  seed+=1  to  seed+=0,   (add eax, 1   to add eax, 0)

before:

after:

To patch the two infinite loops, just nop the two bytes of each jmp $-0

Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

•  The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
•  Modify the pthread_cond_wait to avoid the futex()
• We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop

Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

With this modifications, the binary will print the key by itself. 

Read more

• Pentest Vs Ethical Hacking
• Hacker Attack
• Pentest Windows 7
• Pentest Book
• Hacking Ethics
• Hacking Websites
• Pentest Security
• Pentest Services
• Pentest Vpn
• Hackerx

Thank You To Volunteers And Board Members That Worked BlackHat Booth 2019

The OWASP Foundation would like to thank the OWASP Las Vegas Chapter Volunteers for taking the time out of their busy schedule to give back and volunteer to work the booth at BlackHat 2019.  It was great meeting our Las Vegas OWASP members and working with Jorge, Carmi, Dave, and Nancy.  
Also, take a moment to thank Global Board Members Martin Knobloch, Owen Pendlebury, and Gary Robinson for also working the booth and speaking with individuals and groups to answer questions on projects and suggestions on the use of our tools to address their work problems.
OWASP can not exist without support from our members.  

Read more

• Pentest Plus
• Pentest Kit
• Hacking Jacket
• Pentest Firewall
• Pentest Ubuntu
• Pentest Tools
• Pentestmonkey
• Hacking Ethics
• Hacking Programs
• Hacking Health
• Pentest Devices
• Pentest Vs Ceh
• Pentest Bootcamp

RFCrack Release - A Software Defined Radio Attack Tool

RFCrack uses the following hardware with RFCat libraries:

YardStick One: 

https://goo.gl/wd88sr

I decided to cleanup my RF testing harness and release it as a tool named RFCrack

Mostly because it has been pain to set up use-case scenarios from scratch for every device I am testing. Rather then release a tool no one knows how to use. The below video will be a quick but comprehensive tutorial to get you started If you've been following the blogs, this will greatly simplify your testing, in the following ways:

• RFCrack handles all of your data conversions. 
• It allows you to capture, replay and save payloads for use anytime 
• It will handle rolling code bypass attacks on your devices. 
• You can jam frequencies and fuzz specific values 
• It will also allow you to scan specific frequencies in discovery mode or incrementally probe them 
• RFCrack will hopefully have keyless entry & engine bypass support in the near future

This is the first release, everything works as intended but there will be plenty of updates as I continue to do research and find reasons to add features needed for testing. I am still making changes and making it more flexible with modifiable values and restructuring code.  If you have any legitimate use case scenarios or need a specific value to be modifiable, hit me up and I will do my best to update between research, if its a legitimate use case.

You can reach me at:
Twitter: @Ficti0n
http://cclabs.io , http://consolecowboys.com

GitHub Code for RFCrack:

https://github.com/cclabsInc/RFCrack

Full RF Hacking Course in Development:

Not all of the attacks in the tool have been covered in the RF hacking blog series and a few more are in research mode, as such, not yet added to the tool but will probably be covered in a full length online class on Hacking with RF which includes all targets and equipment.  Send an email to info(at)cclabs.io if your interested.

Walkthrough Training Video:

Until Next time: 

Cheers, and enjoy the tool for your personal use testing devices, feedback and bug reports are appreciated.  I have another RF blog coming out shortly based on my friends research into hacking garages/gates and creating keyfobs.  I will post when its ready. 

More info

1. Pentest Usb
2. Hacking
3. Pentest Cheat Sheet
4. Pentest Uk
5. Hacking Site
6. Hacking Page
7. Pentest Dns

C++ Std::String Buffer Overflow And Integer Overflow

Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed.
Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors.
Besides the operator[] lack of negative index control, I will explain this later.

Do the compilers doesn't warn about this?

If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:

No warnings so many bugs out there...

In order to reproduce the crash we can load a big string or vector from file, for example:

I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string.
Let see how the compiler write asm code based on this c++ code.

So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings.
Then we see the operator[] when it will crash with the negative index.
In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]

In gdb the operator[] is a  allq  0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">

(gdb) i r rsi
rsi            0xfffffffffffefffe  -65538


The implmementation of operator ins in those functions below:

(gdb) bt
#0  0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2
#6  0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29

Then crashes on the MOVZX EAX, byte ptr [RAX]

Program received signal SIGSEGV, Segmentation fault.

0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
29     cout << "penultimate byte is " << hex << s[i] << endl;
(gdb)


What about negative indexing in std::string::operator[] ?
It's exploitable!

In a C char array is known that having control of the index, we can address memory.
Let's see what happens with C++ strings:

The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.

Note that gdb displays by default with at&t asm format wich the operands are in oposite order:

And having a string that is in the stack, controlling the index we can perform a write on the stack.

To make sure we are writing outside the string, I'm gonna do 3 writes:

 See below the command "i r rax" to view the address where the write will be performed.

The beginning of the std::string object is 0x7fffffffde50.
Write -10 writes before the string 0x7fffffffde46.
And write -100 segfaults because is writting in non paged address.



So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()

Related news

• Pentest Example Report
• Pentest Kit
• Pentest Ftp
• Pentest Online Course
• Pentest Distro
• Hacking For Dummies
• Hacker Tools
• Hacking Vpn
• Hacking To The Gate
• Pentest Plus

How To Hack Any Whatsapp Account In 2020

The article will also be broken down into different subtopics and subcategories. This to make it easy for those who are just interested in skimming through the article to pick the part of WhatsApp hack they are most interested in. Just incase you don't have enough time to go through the entire article.

Search queries like these are a common place; Can WhatsApp be hacked? Can you read WhatsApp messages? How safe is the most popular trade fair in the world? This article gives you all the solution you need to hack any WhatsApp account, as well as how to protect yourself from a WhatsApp hack attack.

Although the messenger is now on an end-to-end encryption, WhatsApp is still not totally safe from espionage. WhatsApp chats and messages can still be accessed and read remotely, and old &deleted WhatsApp chats and messages retrieved.

WhatsApp Spy: Hack WhatsApp Chats and Messages

A very simple solution is to use a software that can hack WhatsApp remotely. All manufacturers offer to read the WhatsApp messages an extra web portal. In addition to the Whatsapp messages but can also spy on other messengers. So you can also have access to social media accounts.

The software may only be installed on a smartphone. If the user of the smartphone has been informed about the installation and effects.

WhatsApp Hacker: 3 Steps to Hack WhatsApp in 2020

You can hack Whatsapp using a second cell phone. No extra SIM card is necessary for this. The guide also works with a tablet. With this method, the other phone only needs to clone WhatsApp messages is internet connection.

The trick to hack Whatsapp successfully is not a software bug. It's the way WhatsApp has developed the setup wizard. Since there are no user accounts with passwords and you log in via the mobile number, here lies the vulnerability. But you can also protect yourself from the Whatsapp hack.

Hack WhatsApp Chat with the Best WhatsApp Hacking Tool

To read Whatsapp messages, the mobile phone number of the target must be known. The cell phone can remain locked. There is no need to install software to hack and read Whatsapp messages. Even with the PIN or fingerprint, the Whatsapp account can be hacked.

STEP 1: Create a New WhatsApp Account

To hack an account from Whatsapp, the app from the App Store must be installed on the second cell phone. After the installation of Whatsapp, target's phone number is entered. A confirmation request must be waited until access to the smartphone of the victim exists.

STEP 2: WhatsApp Account Confirmation

The confirmation of the Whatsapp account is the actual security risk of the messenger. Whatsapp usually confirms the registration via SMS. Occasionally the confirmation will also be sent by automated phone call via a phone call.

Calls and text messages can be read and taken by anyone even when the screen is locked. So that the WhatsApp hack does not stand out, the SMS must be removed from the start screen by swiping.

STEP 3: Enter Confirmation

The stolen verification PIN is now entered on the second smartphone. As a result, the WhatsApp account has been taken over by you. You can read the WhatsApp messages, which respond to this mobile phone number.

The downside to this trick is that the victim immediately notices the Whatsapp hack as soon as Whatsapp is opened. If the victim goes through the sign-in process again. The attacker loses access to the messages and no Whatsapp messages can be read.

How to Hack Someone's WhatsApp in 2020

A good way to hack a WhatsApp account is to hack whatsapp online. Here you can read WhatsApp messages via a browser and also write. The target user can continue to use his cell phone (works for iOS, Android phone etc) and does not notice the WhatsApp hack.

STEP 1: Access the Cell Phone

In order to be able to read WhatsApp messages by installing software. Access to the unlocked smartphone is required for a short time. In addition, cell phone, a computer or laptop is necessary. On this the Whatsapp messages will be read later.

STEP 2: Access WhatsApp Web

If you have access to the unlocked smartphone, Whatsapp must be started there. The Whatsapp settings include Whatsapp Web . If this is selected, Whatsapp opens a QR code scanner with the hint to open WhatsApp Web in the browser.

If the QR code is scanned in the browser with the smartphone. There is a permanent connection and Whatsapp messages can be read. If you want to hack Whatsapp in this way. You have full access to all incoming messages and you can even write messages yourself.

STEP 3: Read WhatsApp Messages

The target usually sees this Whatsapp hack only when the settings are invoked to Whatsapp Web in the app. Whatsapp messages can be read via the browser. Regardless of whether the smartphone is on home Wi-Fi or on the move. You can also hack group chats admin by just having any of the contact details.

WhatsApp Hack: How to Hack any WhatsApp account

Which is the most popular messaging app globally? Of course, you can use different apps from Android or iOS to send and receive messages. But Whatsapp remains everyone's favorite globally!

Whatsapp is one of the popular apps in the world. There are more than 2 billion active users on Whatsapp, messaging daily with the app. Why do people love WhatsApp? Whatsapp is very convenient and easy to use.

Other messaging apps like Facebook Messenger, still needs a special account to sign up for this app. If you change a new app, you'll need to add another account. This can be stressful, as you have to remember a lot of new passwords and usernames.

HACKER NT

Read more

• Pentest+ Vs Oscp
• Hacker Typer
• Pentest Active Directory
• What Hacking Is
• Hacking Vpn
• Pentest Companies
• Pentest Red Team
• Rapid7 Pentest
• Pentesting

CTF: FluxFingers4Future - Evil Corp Solution

For this years hack.lu CTF I felt like creating a challenge. Since I work a lot with TLS it was only natural for me to create a TLS challenge. I was informed that TLS challenges are quite uncommon but nevertheless I thought it would be nice to spice the competition up with something "unusual". The challenge mostly requires you to know a lot of details on how the TLS record layer and the key derivation works. The challenge was only solved by one team (0ops from China) during the CTF. Good job!



So let me introduce the challenge first.

The Challenge

You were called by the incident response team of Evil-Corp, the urgently need your help. Somebody broke into the main server of the company, bricked the device and stole all the files! Nothing is left! This should have been impossible. The hacker used some secret backdoor to bypass authentication. Without the knowledge of the secret backdoor other servers are at risk as well! The incident response team has a full packet capture of the incident and performed an emergency cold boot attack on the server to retrieve the contents of the memory (its a really important server, Evil Corp is always ready for such kinds of incidents). However they were unable to retrieve much information from the RAM, what's left is only some parts of the "key_block" of the TLS server. Can you help Evil-Corp to analyze the exploit the attacker used?

(Flag is inside of the attackers' secret message).


TT = Could not recover

key_block:
6B 4F 93 6A TT TT TT TT  TT TT 00 D9 F2 9B 4C B0
2D 88 36 CF B0 CB F1 A6  7B 53 B2 00 B6 D9 DC EF
66 E6 2C 33 5D 89 6A 92  ED D9 7C 07 49 57 AD E1
TT TT TT TT TT TT TT TT  56 C6 D8 3A TT TT TT TT
TT TT TT TT TT TT TT TT  94 TT 0C EB 50 8D 81 C4
E4 40 B6 26 DF E3 40 9A  6C F3 95 84 E6 C5 86 40
49 FD 4E F2 A0 A3 01 06

Download PCAPNG

If you are not interested in the solution and want to try the challenge on your own first, do not read past this point. Spoilers ahead.

The Solution

So lets analyze first what we got. We have something called a "key_block" but we do not have all parts of it. Some of the bytes have been destroyed and are unknown to us. Additionally, we have a PCAP file with some weird messages in them. Lets look at the general structure of the message exchange first.

So looking at the IP address and TCP ports we see that the attacker/client was 127.0.0.1:36674 and was talking with the Server 127.0.0.1:4433. When looking at the individual messages we can see that the message exchange looked something like this:

ENC HS MESSAGE .... ENC HS MESSAGE ->
<- SERVER HELLO, CERTIFICATE, SERVER HELLO DONE
ENC HS MESSAGE .... ENC HS MESSAGE CCS ENC HS MESSAGE, ENC HS MESSAGE ->
<-CCS, ENC HS MESSAGE
ENC HEARTBEAT ->
<- ENC HEARTBEAT
-> ENC APPLICATION DATA
<- INTERNAL ERROR ... INTERNAL ERROR

So this message exchange appears weird. Usually the client is supposed to send a ClientHello in the beginning of the connection, and not encrypted handshake messages. The same is true for the second flight of the client. Usually it transmits its ClientKeyExchange message here, then a ChangeCipherSpec message and finally its Finished message. If we click at the first flight of the client, we can also see some ASCII text fragments in its messages.

Furthermore we can assume that the message sent after the ChangeCipherSpec from the server is actually a TLS Finished message.

Since we cannot read a lot from the messages the client is sending (in Wireshark at least), we can look at the messages the server is sending to get a better hold of what is going on. In the ServerHello message the server selects the parameters for the connection. This reveals that this is indeed a TLS 1.1 connection with TLS_RSA_WITH_AES_256_CBC_SHA , no compression and the Heartbeat Extension negotiated. We can also see that the ServerRandom is: 1023047c60b420bb3321d9d47acb933dbe70399bf6c92da33af01d4fb770e98c (note that it is always 32 bytes long, the UNIX time is part of the ServerRandom).

Looking at the certificate the server sent we can see that the server used a self-signed certificate for Evil.corp.com with an 800-bit RSA modulus:

00ad87f086a4e1acd255d1d77324a05ea7d250f285f3a6de35b9f07c5d083add5166677425b8335328255e7b562f944d55c56ff084f4316fdc9e3f5b009fefd65015a5ca228c94e3fd35c6aba83ea4e20800a34548aa36a5d40e3c7496c65bdbc864e8f161

and the public exponent 65537.


If you pay very close attention to the handshake you can see another weird thing. The size of the exchanged HeartbeatMessages is highly uneven. The client/attacker sent 3500 bytes, the server is supposed to decrypt these messages, and reflect the contents of them. However, the Server sent ~64000 bytes instead. The heartbeat extension became surprisingly well known in 2014, due to the Heartbleed bug in OpenSSL. The bug causes a buffer over-read on the server, causing it to reflect parts of its memory content in return to malicious heartbeat requests. This is a good indicator that this bug might play a role in this challenge.

But what is this key_block thing we got from the incident response team? TLS 1.1 CBC uses 4 symmetric keys in total. Both parties derive these keys from the "master secret" as the key_block. This key_block is then chunked into the individual keys. You can imagine the key_block as some PRF output and both parties knowing which parts of the output to use for which individual key. In TLS 1.1 CBC the key_block is chunked as follows: The first N bytes are the client_write_MAC key, the next N bytes are the server_write_MAC key, the next P bytes are the client_write key and the last P bytes are the server_write key. N is the length of the HMAC key (which is at the time of writing for all cipher suites the length of the HMAC) and P is the length of the key for the block cipher.

In the present handshake AES-256 was negotiated as the block cipher and SHA (SHA-1) was negotiated for the HMAC. This means that N is 20 (SHA-1 is 20 bytes) and P is 32 (AES-256 requires 32 bytes of key material).

Looking at the given key_block we can chunk it into the individual keys:
client_write_MAC = 6B4F936ATTTTTTTTTTTT00D9F29B4CB02D8836CF
server_write_MAC = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write = EDD97C074957ADE1TTTTTTTTTTTTTTTT56C6D83ATTTTTTTTTTTTTTTTTTTTTTTT
server_write = 94TT0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106

Since not all parts of the key_block are present, we can see that we actually have 14/20 bytes of the client_write_MAC key, the whole server_write_MAC key, 12/32 bytes of the client_write key and 31/32 bytes of the server_write key.

The client_write_MAC key is used in the HMAC computations from the client to the server (the server uses the same key to verify the HMAC),
The server_write_MAC key is used in the HMAC computations from the server to the client (the client uses the same key to verify the HMAC),
The client_write key is used to encrypt messages from the client to the server, while the server_write key is used to encrypt messages from the server to the client.

So looking at the keys we could compute HMAC's from the client if we could guess the remaining 6 bytes. We could compute HMAC's from the server directly, we have not enough key material to decrypt the client messages, but we could decrypt server messages if we brute-forced one byte of the server_write key. But how would you brute force this byte? When do we know when we got the correct key? Lets look at how the TLS record layer works to find out :)

The Record Layer

TLS consists out of multiple protocols (Handshake, Alert, CCS, Application (and Heartbeat)). If one of those protocols wants to send any data, it has to pass this data to the record layer. The record layer will chunk this data, compress it if necessary, encrypt it and attach a "record header" to it.

This means, that if we want to decrypt a message we know that if we used the correct key the message should always have a correct padding. If we are unsure we could even check the HMAC with the server_write_MAC key.

In TLS 1.0 - TLS 1.2 the padding looks like this:

1 byte padding  : 00
2 bytes padding: 01 01
3 bytes padding: 02 02 02
4 bytes padding: 03 03 03 03
...

So if we guessed the correct key we know that the plaintext has to have valid padding.
An ideal candidate for our brute force attack is the server Finished message. So lets use that to check our key guesses.
The ciphertext looks like this:
0325f41d3ebaf8986da712c82bcd4d55c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd

The first 16 bytes of the ciphertext are the IV:
IV: 0325f41d3ebaf8986da712c82bcd4d55
Therefore the actual ciphertext is:
Ciphertext: c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd

The 256 key candidates are quick to check, and it is revealed that 0xDC was the missing byte.
(The plaintext of the Finished is 1400000C455379AAA141E1B9410B413320C435DEC948BFA451C64E4F30FE5F6928B816CA0B0B0B0B0B0B0B0B0B0B0B0B)

Now that we have the full server_write key we can use it to decrypt the heartbeat records.

This is done in the same way as with the Finished. Looking at the decrypted heartbeat messages we can see a lot of structured data, which is an indicator that we are actually dealing
with the Heartbleed bug. If we convert the content of the heartbeat messages to ASCII we can actually see that the private key of the server is PEM encoded in the first heartbeat message.

Note: This is different to a real heartbeat exploit. Here you don't usually get the private key nicely encoded but have to extract it using the coppersmith's attack or similar things. I did not want to make this challenge even harder so I was so nice to write it to the memory for you :)


The private key within the Heartbeat messages looks like this:
-----BEGIN RSA PRIVATE KEY-----
MIIB3gIBAAJlAK2H8Iak4azSVdHXcySgXqfSUPKF86beNbnwfF0IOt1RZmd0Jbgz
UyglXntWL5RNVcVv8IT0MW/cnj9bAJ/v1lAVpcoijJTj/TXGq6g+pOIIAKNFSKo2
pdQOPHSWxlvbyGTo8WECAwEAAQJkJj95P2QmLb5qlgbj5SXH1zufBeWKb7Q4qVQd
RTAkMVXYuWK7UZ9Wa9nYulyjvg9RoWOO+SaDNqhiTWKosQ+ZrvG3A1TDMcVZSkPx
bXCuhhRpp4j0T9levQi0s8tR1YuFzVFi8QIzANNLrgK2YOJiDlyu78t/eVbBey4m
uh2xaxvEd8xGX4bIBlTuWlKIqwPNxE8fygmv4uHFAjMA0j7Uk1ThY+UCYdeCm4/P
eVqkPYu7jNTHG2TGr/B6hstxyFpXBlq6MJQ/qPdRXLkLFu0CMwCf/OLCTQPpBiQn
y5HoPRpMNW4m0M4F46vdN5MaCoMUU+pvbpbXfYI3/BrTapeZZCNfnQIzAJ7XzW9K
j8cTPIuDcS/qpQvAiZneOmKaV5vAtcQzYb75cgu3BUzNuyH8v2P/Br+RJmm5AjMA
jp9N+xdEm4dW51lyUp6boVU6fxZimfYRfYANU2bVFmbsSAU9jzjWb0BuXexKKcX7
XGo=
-----END RSA PRIVATE KEY-----

We should store it in a file and decode it with OpenSSL to get the actual key material.

>> openssl rsa -in key.pem -text -noout
RSA Private-Key: (800 bit, 2 primes)
modulus:
    00:ad:87:f0:86:a4:e1:ac:d2:55:d1:d7:73:24:a0:
    5e:a7:d2:50:f2:85:f3:a6:de:35:b9:f0:7c:5d:08:
    3a:dd:51:66:67:74:25:b8:33:53:28:25:5e:7b:56:
    2f:94:4d:55:c5:6f:f0:84:f4:31:6f:dc:9e:3f:5b:
    00:9f:ef:d6:50:15:a5:ca:22:8c:94:e3:fd:35:c6:
    ab:a8:3e:a4:e2:08:00:a3:45:48:aa:36:a5:d4:0e:
    3c:74:96:c6:5b:db:c8:64:e8:f1:61
publicExponent: 65537 (0x10001)
privateExponent:
    26:3f:79:3f:64:26:2d:be:6a:96:06:e3:e5:25:c7:
    d7:3b:9f:05:e5:8a:6f:b4:38:a9:54:1d:45:30:24:
    31:55:d8:b9:62:bb:51:9f:56:6b:d9:d8:ba:5c:a3:
    be:0f:51:a1:63:8e:f9:26:83:36:a8:62:4d:62:a8:
    b1:0f:99:ae:f1:b7:03:54:c3:31:c5:59:4a:43:f1:
    6d:70:ae:86:14:69:a7:88:f4:4f:d9:5e:bd:08:b4:
    b3:cb:51:d5:8b:85:cd:51:62:f1
prime1:
    00:d3:4b:ae:02:b6:60:e2:62:0e:5c:ae:ef:cb:7f:
    79:56:c1:7b:2e:26:ba:1d:b1:6b:1b:c4:77:cc:46:
    5f:86:c8:06:54:ee:5a:52:88:ab:03:cd:c4:4f:1f:
    ca:09:af:e2:e1:c5
prime2:
    00:d2:3e:d4:93:54:e1:63:e5:02:61:d7:82:9b:8f:
    cf:79:5a:a4:3d:8b:bb:8c:d4:c7:1b:64:c6:af:f0:
    7a:86:cb:71:c8:5a:57:06:5a:ba:30:94:3f:a8:f7:
    51:5c:b9:0b:16:ed
exponent1:
    00:9f:fc:e2:c2:4d:03:e9:06:24:27:cb:91:e8:3d:
    1a:4c:35:6e:26:d0:ce:05:e3:ab:dd:37:93:1a:0a:
    83:14:53:ea:6f:6e:96:d7:7d:82:37:fc:1a:d3:6a:
    97:99:64:23:5f:9d
exponent2:
    00:9e:d7:cd:6f:4a:8f:c7:13:3c:8b:83:71:2f:ea:
    a5:0b:c0:89:99:de:3a:62:9a:57:9b:c0:b5:c4:33:
    61:be:f9:72:0b:b7:05:4c:cd:bb:21:fc:bf:63:ff:
    06:bf:91:26:69:b9
coefficient:
    00:8e:9f:4d:fb:17:44:9b:87:56:e7:59:72:52:9e:
    9b:a1:55:3a:7f:16:62:99:f6:11:7d:80:0d:53:66:
    d5:16:66:ec:48:05:3d:8f:38:d6:6f:40:6e:5d:ec:
    4a:29:c5:fb:5c:6a

So now we got the private key. But what do we do with it? Since this is an RSA handshake we should be able to decrypt the whole session (RSA is not perfect forward secure). Loading it into Wireshark does not work, as Wireshark is unable to read the messages sent by the client. What is going on there?

De-fragmentation

So if you do not yet have a good idea of what the record layer is for, you can imagine it like envelops. If someone wants to send some bytes, you have to put them in an envelop and transmit them. Usually implementations use one big envelop for every message, however you can also send a single message in multiple envelops.

The attacker did exactly that. He fragmented its messages into multiple records. This is not very common for handshake messages but fine according to the specification and accepted by almost all implementations. However, Wireshark is unable to decode these kinds of messages and therefore unable to use our private key to decrypt the connection. So we have to do this step manually.

So each record has the following fields:
Type | Version | Length | Data
If we want to reconstruct the ClientHello message we have to get all the data fields of the records of the first flight and decode them.
This is simply done by clicking on each record in Wireshark and concatenating the data fields. This step is at least on my Wireshark version (3.0.5) not very easy as the copying is actually buggy, and Wireshark is not copying the correct bytes.

 As you can see in the image, the record is supposed to have a length of 8 bytes, but Wireshark is only copying 4 bytes. I am not sure if this bug is actually only in my version or affects all Wireshark versions. Instead of copying the records individually I therefore copied the whole TCP payload and chunked it manually into the individual records.

16030200080100009e03020000
160302000800000000004e6f62
16030200086f64796b6e6f7773
1603020008696d616361740000
16030200080000000000002053
1603020008746f70206c6f6f6b
1603020008696e67206e6f7468
1603020008696e6720746f2066
1603020008696e646865726500
16030200080200350100005300
16030200080f00010113370015
16030200084576696c436f7270
1603020008206b696c6c732070
1603020008656f706c65000d00
16030200082c002a0102020203
16030200080204020502060201
16030200080102010301040105
16030200080106010103020303
160302000803040305030603ed
1603020008edeeeeefefff0100
16030200020100

If we structure this data it looks like this:
Type  Version Length  Payload
16    0302    0008    0100009e03020000
16    0302    0008    00000000004e6f62
16    0302    0008    6f64796b6e6f7773
16    0302    0008    696d616361740000
16    0302    0008    0000000000002053
16    0302    0008    746f70206c6f6f6b
16    0302    0008    696e67206e6f7468
16    0302    0008    696e6720746f2066
16    0302    0008    696e646865726500
16    0302    0008    0200350100005300
16    0302    0008    0f00010113370015
16    0302    0008    4576696c436f7270
16    0302    0008    206b696c6c732070
16    0302    0008    656f706c65000d00
16    0302    0008    2c002a0102020203
16    0302    0008    0204020502060201
16    0302    0008    0102010301040105
16    0302    0008    0106010103020303
16    0302    0008    03040305030603ed
16    0302    0008    edeeeeefefff0100
16    0302    0002    0100

The actual message is the concatenation of the record payloads:

0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100

So what is left is to parse this message. There is an easy way on how to do this an a labor intensive manual way. Lets do the manual process first :) .
We know from the record header that his message is in fact a handshake message (0x16).
According to the specification handshake messages look like this:
    
      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (HandshakeType) {
              case hello_request:       HelloRequest;
              case client_hello:        ClientHello;
              case server_hello:        ServerHello;
              case certificate:         Certificate;
              case server_key_exchange: ServerKeyExchange;
              case certificate_request: CertificateRequest;
              case server_hello_done:   ServerHelloDone;
              case certificate_verify:  CertificateVerify;
              case client_key_exchange: ClientKeyExchange;
              case finished:            Finished;
          } body;
      } Handshake;
    
This is RFC speak for: Each handshake message starts with a type field which says which handshake message this is, followed by a 3 byte length field which determines the length of rest of the handshake message.
So in our case the msg_type is 0x01 , followed by a 3 Byte length field (0x00009e, 158[base10]). 0x01 means ClientHello (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-7). This means we have to parse the bytes after the length field as a ClientHello.
    
      {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suites<2..2^16-2>;
          CompressionMethod compression_methods<1..2^8-1>;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ClientHello;

This means: The next 2 bytes are the ProtocolVersion, the next 32 bytes are the ClientRandom, the next byte is the SessionID Length, the next SessionID Length many bytes are the SessionID, the next 2 bytes are the CipherSuite Length bytes, followed by CipherSuite Length many CipherSuites, followed by a 1 byte Compression Length field, followed by Compression Length many CompressionBytes followed by a 2 byte Extension Length field followed by extension length many ExtensionBytes. So lets try to parse this:

Handshakye Type   : 01
Handshake Length  : 00009e
ProtocolVersion   : 0302
ClientRandom      : 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000
SessionID Length  : 20
SessionID         : 53746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e6468657265
CipherSuite Length: 0002
CipherSuites      : 0035
Compression Length: 01
CompressionBytes  : 00
Extension Length  : 0053
ExtensionBytes:   : 000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100

This is manual parsing is the slow method of dealing with this. Instead of looking at the specification to parse this message we could also compare the message structure to another ClientHello. This eases this process a lot. What we could also do is record the transmission of this message as a de-fragmented message to something and let Wireshark decode it for us. To send the de-fragmented message we need to create a new record header ourselves. The record should look like this:

Type   : 16
Version: 0302
Length : 00A2
Payload: 0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100

To send this record we can simply use netcat:


echo '16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100' | xxd -r -p | nc localhost 4433


Now we can use Wireshark to parse this message. As we can see now, the weired ASCII fragments we could see in the previous version are actually the ClientRandom, the SessionID, and a custom extension from the attacker. Now that we have de-fragmented the message, we know the ClientRandom: 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000

De-fragmenting the ClientKeyExchange message

Now that we have de-fragmented the first flight from the attacker, we can de-fragment the second flight from the client. We can do this in the same fashion as we de-fragmented the ClientHello.

16    0302    0008    1000006600645de1
16    0302    0008    66a6d3669bf21936
16    0302    0008    5ef3d35410c50283
16    0302    0008    c4dd038a1b6fedf5
16    0302    0008    26d5b193453d796f
16    0302    0008    6e63c144bbda6276
16    0302    0008    3740468e21891641
16    0302    0008    0671318e83da3c2a
16    0302    0008    de5f6da6482b09fc
16    0302    0008    a5c823eb4d9933fe
16    0302    0008    ae17d165a6db0e94
16    0302    0008    bb09574fc1f7b8ed
16    0302    0008    cfbcf9e9696b6173
16    0302    0002    f4b6

14    0302    0001    01

16    0302    0030    cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a4157
16    0302    0030    9bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9

Note that his time we have 3 record groups. First there is chain of handshake records, followed by a ChangeCipherSpec record, followed by 2 more handshake records. The TLS specification forbids that records of different types are interleaved. This means that the first few records a probably forming a group of messages. The ChangeCipherSpec record is telling the server that subsequent messages are encrypted. This seems to be true, since the following records do not appear to be plaintext handshake messages.

So lets de-fragment the first group of records by concatenating their payloads:

1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6

Since this is a handshake message, we know that the first byte should tell us which handshake message this is. 0x10 means this is a ClientKeyExchange message. Since we already know that TLS_RSA_WITH_AES_256_CBC_SHA was negotiated for this connection, we know that this is an RSA ClientKeyExchange message.

These messages are supposed to look like this (I will spare you the lengthy RFC definition):

Type (0x10)
Length (Length of the content) (3 bytes)
EncryptedPMS Length(Length of the encrypted PMS) (2 bytes)
EncrpytedPMS  (EncryptedPMS Length many bytes)
    
For our message this should look like this:

Type: 10
Length: 000066
Encrypted PMS Length: 0064
Encrypted PMS: 5de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6

Now that we got the Encrypted PMS we can decrypt it with the private key. Since the connection negotiated RSA as the key exchange algorithm this is done with:

encPMS^privKey mod modulus = plainPMS

We can solve this equation with the private key from the leaked PEM file.

2445298227328938658090475430796587247849533931395726514458166123599560640691186073871766111778498132903314547451268864032761115999716779282639547079095457185023600638251088359459150271827705392301109265654638212139757207501494756926838535350 ^ 996241568615939319506903357646514527421543094912647981212056826138382708603915022492738949955085789668243947380114192578398909946764789724993340852568712934975428447805093957315585432465710754275221903967417599121549904545874609387437384433 mod 4519950410687629988405948449295924027942240900746985859791939647949545695657651701565014369207785212702506305257912346076285925743737740481250261638791708483082426162177210620191963762755634733255455674225810981506935192783436252402225312097

Solving this equation gives us:

204742908894949049937193473353729060739551644014729690547520028508481967333831905155391804994508783506773012994170720979080285416764402813364718099379387561201299457228993584122400808905739026823578773289385773545222916543755807247900961

in hexadecimal this is:

00020325f41d3ebaf8986da712c82bcd4d554bf0b54023c29b624de9ef9c2f931efc580f9afb081b12e107b1e805f2b4f5f0f1000302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121

The PMS is PKCS#1.5 encoded. This means that it is supposed to start with 0x0002 followed by a padding which contains no 0x00 bytes, followed by a separator 0x00 byte followed by a payload. In TLS, the payload has to be exactly 48 bytes long and has to start with the highest proposed protocol version of the client. We can see that this is indeed the case for our decrypted payload. The whole decrypted payload is the PMS for the connection.

This results in the PMS: 0302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121 (which besides the protocol version is also ASCII :) )

Now that we have the PMS its time to revisit the key scheduling in TLS. We already briefly touched it but here is a overview:

As you can see, we first have to compute the master secret. With the master secret we can reconstruct the key_block. If we have computed the key_block, we can finally get the client_write key and decrypt the message from the attacker.


master secret = PRF ( PMS, "master secret", ClientRandom | ServerRandom)

key_block = PRF (master_secret, "key expansion", ServerRandom |  ClientRandom )

Where "master secret" and "key expansion" are literally ASCII Strings.

Note that in the key_block computation ClientRandom and ServerRandom are exchanged.



To do this computation we can either implement the PRF ourselfs, or easier, steal it from somewhere. The PRF in TLS 1.1 is the same as in TLS 1.0. Good places to steal from are for example openssl (C/C++), the scapy project (python), the TLS-Attacker project (java) or your favourite TLS library. The master secret is exactly 48 bytes long. The length of the key_block varies depending on the selected cipher suite and protocol version. In our case we need 2 * 20 bytes (for the 2 HMAC keys) + 2 * 32 bytes (for the 2 AES keys) = 104 bytes.

I will use the TLS-Attacker framework for this computation. The code will look like this:


This results in the following master secret: 292EABADCF7EFFC495825AED17EE7EA575E02DF0BAB7213EC1B246BE23B2E0912DA2B99C752A1F8BD3D833E8331D649F  And the following key_block:
6B4F936ADE9B4010393B00D9F29B4CB02D8836CFB0CBF1A67B53B200B6D9DCEF66E62C335D896A92EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A1994DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106

Now we can chunk our resulting key_block into its individual parts. This is done analogously to the beginning of the challenge.

client_write_mac key = 6B4F936ADE9B4010393B00D9F29B4CB02D8836CF
server_write_mac key = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write key = EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A19
server_write key = 94DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106

Now that we have the full client_write key we can use that key to decrypt the application data messages. But these messages are also fragmented. But since the messages are now encrypted, we cannot simply concatenate the payloads of the records, but we have to decrypt them individually and only concatenate the resulting plaintext.

Analogue to the decryption of the heartbeat message, the first 16 bytes of each encrypted record payload are used as an IV

IV, Ciphertext Plaintext
6297cb6d9afba63ec4c0dd7ac0184570    a9c605307eb5f8ccbe8bbc210ff1ff14943873906fad3eca017f49af8feaec87      557365723A20726FB181CF546350A88ACBE8D0248D6FF07675D1514E03030303
063c60d43e08c4315f261f8a4f06169a    cdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb886    6F743B0A50617373D6F734D45FB99850CCAF32DF113914FC412C523603030303
cd839b95954fcadf1e60ee983cbe5c21    ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc7    3A20726F6F743B0A937048A265327642BD5626E00E4BC79618F9A95C03030303
8092d75f72b16cb23a856b00c4c39898    8df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf    6563686F20224F7769EACFBEEB5EE5D1F0B72306F8C78AD86CB4835003030303
8e9f83b015fce7f9c925b8b64abee426    224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e65    6E6564206279204061736E93BFDC5103C8C2FE8C543A72B924212E8403030303
0e24ba11e41bfcf66452dc80221288ce    a66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c9    6963306E7A31223B84A3CAFA7980B461DE0A6410D6251551AE401DD903030303
0465fdb05b121cdc08fa01cdacb2c8f4    eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c9     0A7375646F20726DB97422D8B30C54CC672FFEC3E9D771D4743D96B903030303
e2ddbbb83fe8318c41c26d57a5813fab    89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a      202F202D72663B0A996F3F1789CB9B671223E73C66A0BA578D0C0F3203030303
524f5210190f73c984bd6a59b9cf424c    b7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315    0A666C61677B436868BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE03030303
32765985e2e594cddca3d0f45bd21f49    a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc    696D696368616E67FBF32127FA3AF2F97770DE5B9C6D376A254EF51E03030303
e0ae69b1fa54785dc971221fd92215fb    14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e    61467233346B7D8BE8B903A167C44945E7676BF99D888A4B86FA8E0404040404

The plaintext then has to be de-padded and de-MACed.

Data HMAC Pad:
557365723A20726F    B181CF546350A88ACBE8D0248D6FF07675D1514E    03030303
6F743B0A50617373    D6F734D45FB99850CCAF32DF113914FC412C5236    03030303
3A20726F6F743B0A    937048A265327642BD5626E00E4BC79618F9A95C    03030303
6563686F20224F77    69EACFBEEB5EE5D1F0B72306F8C78AD86CB48350    03030303
6E65642062792040    61736E93BFDC5103C8C2FE8C543A72B924212E84    03030303
6963306E7A31223B    84A3CAFA7980B461DE0A6410D6251551AE401DD9    03030303
0A7375646F20726D    B97422D8B30C54CC672FFEC3E9D771D4743D96B9    03030303
202F202D72663B0A    996F3F1789CB9B671223E73C66A0BA578D0C0F32    03030303
0A666C61677B4368    68BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE    03030303
696D696368616E67    FBF32127FA3AF2F97770DE5B9C6D376A254EF51E    03030303
61467233346B7D      8BE8B903A167C44945E7676BF99D888A4B86FA8E    0404040404

This then results in the following data:

Data:
557365723A20726F6F743B0A506173733A20726F6F743B0A6563686F20224F776E656420627920406963306E7A31223B0A7375646F20726D202F202D72663B0A0A666C61677B4368696D696368616E6761467233346B7D8B

Which is ASCII for:

User: root;
Pass: root;
echo "Owned by @ic0nz1";
sudo rm / -rf;

flag{ChimichangaFr34k}


Honestly this was quite a journey. But this presented solution is the tedious manual way. There is also a shortcut with which you can skip most of the manual cryptographic operations.

The Shortcut

After you de-fragmented the messages you can patch the PCAP file and then use Wireshark to decrypt the whole session. This way you can get the flag without performing any cryptographic operation after you got the private key. Alternatively you can replay the communication and record it with Wireshark. I will show you the replay of the messages. To recap the de-fragmented messages looks like this:

ClientHello
0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100

ClientKeyExchange:
1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6

We should now add new (not fragmented) record header to the previously fragmented message. The messages sent from the server can stay as they are. The ApplicationData from the client can also stay the same. The messages should now look like this

ClientHello
16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100

ServerHello / Certificate / ServerHelloDone
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9

ClientKeyExchange / ChangeCipherSpec / Finished
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9')

ApplicationData
1703020030063c60d43e08c4315f261f8a4f06169acdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb8861703020030cd839b95954fcadf1e60ee983cbe5c21ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc717030200308092d75f72b16cb23a856b00c4c398988df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf17030200308e9f83b015fce7f9c925b8b64abee426224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e6517030200300e24ba11e41bfcf66452dc80221288cea66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c917030200300465fdb05b121cdc08fa01cdacb2c8f4eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c91703020030e2ddbbb83fe8318c41c26d57a5813fab89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a1703020030524f5210190f73c984bd6a59b9cf424cb7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315170302003032765985e2e594cddca3d0f45bd21f49a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc1703020030e0ae69b1fa54785dc971221fd92215fb14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e

What we want to do now is create the following conversation:
CH->
<-SH, CERT, SHD
-> CKE, CCS, FIN
-> APP, APP ,APP

This will be enough for Wireshark to decrypt the traffic. However, since we removed some messages (the whole HeartbeatMessages) our HMAC's will be invalid.

We need to record an interleaved transmission of these message with Wireshark. I will use these simple python programs to create the traffic:




If we record these transmissions and tick the flag in Wireshark to ignore invalid HMAC's we can see the plaintext (if we added the private key in Wireshark).

Challenge Creation

I used our TLS-Attacker project to create this challenge. With TLS-Attacker you can send arbitrary TLS messages with arbitrary content in an arbitrary order, save them in XML and replay them. The communication between the peers are therefore only two XML files which are loaded into TLS-Attacker talking to each other. I then copied parts of the key_block from the debug output and the challenge was completed :)

If you have question in regards to the challenge you can DM me at @ic0nz1
Happy HackingRelated links

• Pentest Xss
• Pentest Os
• Hacking
• Pentest Basics
• Hacking Wifi
• Pentest Aws
• Hacking Software
• Pentestbox
• Pentest As A Service
• Hackerone
• Hacking Games
• Pentest Basics
• Pentest News