In the last article Learning Web Pentesting With DVWA Part 1: Installation, you were given a glimpse of SQL injection when we installed the DVWA app. In this article we will explain what we did at the end of that article and much more.
Lets start by defining what SQL injection is, OWASP defines it as: "A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands."
Which basically means that we can use a simple (vulnerable) input field in our web application to get information from the database of the server which hosts the web application. We can command and control (at certain times) the database of the web application or even the server.
In this article we are going to perform SQL injection attack on DVWA, so let's jump in. On the DVWA welcome page click on SQL Injection navigation link. We are presented with a page with an input field for User ID.
Now lets try to input a value like 1 in the input field. We can see a response from server telling us the firstname and surname of the user associated with User ID 1.
If we try to enter a user id which doesn't exist, we get no data back from the server. To determine whether an input field is vulnerable to SQL injection, we first start by sending a single quote (') as input. Which returns an SQL error.
We saw this in the previous article and we also talked about injection point in it. Before diving deeper into how this vulnerability can be exploited lets try to understand how this error might have occurred. Lets try to build the SQL query that the server might be trying to execute. Say the query looks something like this:
The 1 in this query is the value supplied by the user in the User ID input field. When we input a single quote in the User ID input field, the query looks like this:
The quotes around the input provided in the User ID input field are from the server side application code. The error is due to the extra single quote present in the query. Now if we specify a comment after the single quote like this: '-- - or '# we should get no error. Now our crafted query looks like this:
since everything after the # or -- - are commented out, the query will ignore the extra single quote added by the server side app and whatever comes after it and will not generate any error. However the query returns nothing because we specified nothing ('') as the user_id.
After knowing how things might be working on the server side, we will start to attack the application. First of all we will try to determine the number of columns that the query outputs because if we try a query which will output the number of columns greater or smaller than what the original query outputs then our query is going to get an error. So we will first figure out the exact number of columns that the query outputs and we will do that with the help of order by sql statement like this:
'orderby1-- -
This MySQL server might execute the query as:
SELECTfirst_name,sur_nameFROMusersWHEREuser_id='' order by 1-- -';
you get the idea now. if we don't get any error message, we will increase the number to 2 like this:
'orderby2-- -
still no error message, lets add another:
'orderby3-- -
and there we go we have an error message. Which tells us the number of columns that the server query selects is 2 because it erred out at 3.
Now lets use the union select SQL statement to get information about the database itself.
'unionselectnull,version()-- -
You should first understand what a union select statement does and only then can you understand what we are doing here. You can read about it here. We have used null as one column since we need to match the number of columns from the server query which is two. null will act as a dummy column here which will give no output and the second column which in our case here is the version() command will output the database version. Notice the output from the application, nothing is shown for First name since we specified null for it and the maria db version will be displayed in Surname. Now lets check who the database user is using the user() function of mariadb:
'unionselectnull,user()-- -
After clicking the submit button you should be able to see the user of the database in surname. Now lets get some information about the databases in the database. Lets determine the names of databases from INFORMATION_SCHEMA.SCHEMATA by entering following input in the User ID field:
This lists two databases dvwa and information_schema. information_schema is the built in database. Lets look at the dvwa database. Get table names for dvwa database from INFORMATION_SCHEMA.TABLES
It gives a huge number of tables that are present in dvwa database. But what we are really interested in is the users table as it is most likely to contain user passwords. But first we need to determine columns of that table and we will do that by querying INFORMATION_SCHEMA.COLUMNS like this:
' union select null, COLUMN_NAME from INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'users'-- -
We can see the password column in the output now lets get those passwords:
'unionselectuser,passwordfromusers-- -
Of-course those are the hashes and not plain text passwords. You need to crack them. Hope you learned something about SQL injection in this article. See you next time.
Welcome back to Linux Command Line Hackery, yes this is Part 2 and today we are going to learn some new skills. Let's rock
Let us first recap what we did in Part 1, if you are not sure what the following commands do then you should read Part 1. mkdirmyfiles # make a directory (folder) with myfiles as name cdmyfiles # navigate to myfiles folder touchfile1file2file3 # create three empty files file1, file2, file3 ls-l # view contents of current directory echo This is file1 > file1 # write a line of text to file1 catfile1 # display contents of file1 echo This is another line in file1 >> file1 # append another line of text to file1 catfile1 # display the modified content of file1 Command: cp Syntax: cpsource1 [source2 ...] destination Function: cp stands for copy. cp is used to copy a file from source to destination. Some important flags are mentioned below Flags: -r copy directories recursively -f if an existing destination file cannot be opened, remove it and try again Let us make a copy of file1 using the new cp command: cpfile1file1.bak what this command is going to do is simply copy file1 to another file named file1.bak. You can name the destination file anything you want. Say, you have to copy file1 to a different folder maybe to home directory how can we do that? well we can do that like this: cpfile /home/user/ I've used the absolute path here you can use whatever you like.
[Trick:~has a special meaning, it stands for logged in user's directory. You could have written previous command simply as cpfile1~/ and it would have done the same thing.]
Now you want to create a new directory in myfiles directory with the name backup and store all files of myfiles directory in the backup directory. Let's try it: mkdirbackup cpfile1file2file3backup/ this command will copy file1file2file3 to backup directory. We can copy multiple files using cp by specifying the directory to which files must be copied at the end. We can also copy whole directory and all files and sub-directories in a directory using cp. In order to make a backup copy of myfiles directory and all of it's contents we will type: cd.. # navigate to previous directory cp -r myfiles myfiles.bak # recursively copy all contents of myfiles directory to myfiles.bak directory This command will copy myfiles directory to myfiles.bak directory including all files and sub-directories Command: mv Syntax: mvsource1 [source2 ...] destination Function: mv stands for move. It is used for moving files from one place to another (cut/paste in GUI) and also for renaming the files. If we want to rename our file1 to file1.old in our myfiles folder we'll do the follow: cdmyfiles # navigate first to myfiles folder mvfile1file1.old this command will rename the file1 to file1.old (it really has got so old now). Now say we want to create a new file1 file in our myfiles folder and move the file1.old file to our backup folder: mvfile1.old backup/ # move (cut/paste) the file1.old file to backup directory touchfile1 # create a new file called file1 echo New file1 here > file1 # echo some content into file1 Command: rmdir Syntax: rmdir directory_name Function: rmdir stands for remove directory. It is used for removing empty directories. Let's create an empty directory in our myfiles directory called 'garbage' and then remove it using rmdir: mkdir garbage rmdirgarbage Good practice keep it doing. (*_*) But wait a second, I said empty directory! does it mean I cannot delete a directory which has contents in it (files and sub-directories) with rmdir? Yes!, you cannot do that with rmdir. So how am I gonna do that, well keep reading... Command: rm Syntax: rmFILE... Function: rm stands for remove. It is used to remove files and directories. Some of it's important flags are enlisted below. Flags: -r remove directories and their contents recursively -f ignore nonexistent files and arguments, never prompt Now let's say we want to delete the file file1.old in backup folder. Here is how we will do that: rmbackup/file1.old # using relative path here Boom! the file is gone. Keep in mind one thing when using rm "IT IS DESTRUCTIVE!". No I'm not yelling at you, I'm just warning you that when you use rm to delete a file it doesn't go to Trash (or Recycle Bin). Rather it is deleted and you cannot get it back (unless you use some special tools quickly). So don't try this at home. I'm just kidding but yes try it cautiously otherwise you are going to loose something important. Did You said that we can delete directory as well with rm? Yes!, I did. You can delete a directory and all of it's contents with rm by just typing: rm-rdirectory_name Maybe we want to delete backup directory from our myfiles directory, just do this: rm-rbackup And it is gone now. Remember what I said about rm, use it with cautious and use rm-r more cautiously (believe me it costs a lot). -r flag will remove not just the files in directory it will also remove any sub-directories in that directory and there respective contents as well. That is it for this article. I've said that I'll make each article short so that It can be learned quickly and remembered for longer time. I don't wanna bore you.
CloudFrunt is a tool for identifying misconfigured CloudFront domains.
Background
CloudFront is a Content Delivery Network (CDN) provided by Amazon Web Services (AWS). CloudFront users create "distributions" that serve content from specific sources (an S3 bucket, for example).
Each CloudFront distribution has a unique endpoint for users to point their DNS records to (ex. d111111abcdef8.cloudfront.net). All of the domains using a specific distribution need to be listed in the "Alternate Domain Names (CNAMEs)" field in the options for that distribution.
When a CloudFront endpoint receives a request, it does NOT automatically serve content from the corresponding distribution. Instead, CloudFront uses the HOST header of the request to determine which distribution to use. This means two things:
If the HOST header does not match an entry in the "Alternate Domain Names (CNAMEs)" field of the intended distribution, the request will fail.
Any other distribution that contains the specific domain in the HOST header will receive the request and respond to it normally.
This is what allows the domains to be hijacked. There are many cases where a CloudFront user fails to list all the necessary domains that might be received in the HOST header. For example:
The domain "test.disloops.com" is a CNAME record that points to "disloops.com".
The "disloops.com" domain is set up to use a CloudFront distribution.
Because "test.disloops.com" was not added to the "Alternate Domain Names (CNAMEs)" field for the distribution, requests to "test.disloops.com" will fail.
Another user can create a CloudFront distribution and add "test.disloops.com" to the "Alternate Domain Names (CNAMEs)" field to hijack the domain.
This means that the unique endpoint that CloudFront binds to a single distribution is effectively meaningless. A request to one specific CloudFront subdomain is not limited to the distribution it is associated with.
-h, --help Show this message and exit -s, --save Save the results to results.txt -N, --no-dns Do not use dnsrecon to expand scope -l, --target-file TARGET_FILE File containing a list of domains (one per line) -d, --domains DOMAINS Comma-separated list of domains to scan -o, --origin ORIGIN Add vulnerable domains to new distributions with this origin -i, --origin-id ORIGIN_ID The origin ID to use with new distributions
[+] Enumerating DNS entries for google.com [-] No issues found for google.com
[+] Enumerating DNS entries for disloops.com [+] Found CloudFront domain --> cdn.disloops.com [+] Found CloudFront domain --> test.disloops.com [-] Potentially misconfigured CloudFront domains: [#] --> test.disloops.com [+] Created new CloudFront distribution EXBC12DE3F45G [+] Added test.disloops.com to CloudFront distribution EXBC12DE3F45G
Kali Linux has been the most advanced penetration testing machine introduced yet. It has the most valuable tools used for every sort of hacking. To take advantage of Kali Linux hacking tools, you have to switch your OS to Kali Linux. You can either install Kali Linux as your default OS or just install as a virtual machine within the same OS. You can learn more about how to install Kali Linux Virtualbox. Today in this tutorial, I am just going to share a very simple Kali Linux tutorial on how to capture screenshot in Kali Linux. It's very simple and newbie friendly.
SO, HOW TO CAPTURE SCREENSHOT IN KALI LINUX? – KALI LINUX TUTORIAL
There are two ways to capture a screenshot in Kali Linux. One is the ultimate easy one and the second one is a bit complex but it's also not so complicated. So, don't worry about anything.
INSTRUCTIONS TO FOLLOW
In a first way, you can take a screenshot in a similar way as you take in Windows OS by simply clicking the PrntScr button on the keyboard. As you hit that button, a screenshot will be saved in the Pictures folder of your Kali Linux. The major problem with it, it only captures the full screen. We have no control over it to capture a specific window or region.
The second way is to take a screenshot using the command. For that, open up a terminal in the Kali Linux and type apt-get install ImageMagick.
Once the command is completed and ImageMagick is installed. We have two options to take a screenshot with it. One is to capture full screen and second is to capture a specific window.
To capture full screen, type import -window root Pictures/AnyNameOfTheImage.png in the terminal. It will take a full screenshot and will save it to the Pictures directory by the name you specify. Make sure to type .png at the end of the file name.
To take a screenshot of a specific window or region, type import Pictures/AnyNameOfTheImage.png in the terminal and hit Enter, it will turn the cursor to a selection tool. You just click the mouse button and select the area you want to capture. As you will leave the mouse key, screenshot will be saved in the Pictures folder.
That's all how you can capture screenshot in Kali Linux. This is a very simple and beginner-friendly Kali Linux tutorial to help out all the newbies how they can use this features in need. Hope it will be useful for you.
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).
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:
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:
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.
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.
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
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
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.
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:
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
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.
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 file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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
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:
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
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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_blockfrom the debug output and the challenge was completed :) If you have question in regards to the challenge you can DM me at @ic0nz1 Happy Hacking
