CVE-2020-2655 JSSE Client Authentication Bypass

During our joint research on DTLS state machines, we discovered a really interesting vulnerability (CVE-2020-2655) in the recent versions of Sun JSSE (Java 11, 13). Interestingly, the vulnerability does not only affect DTLS implementations but does also affects the TLS implementation of JSSE in a similar way. The vulnerability allows an attacker to completely bypass client authentication and to authenticate as any user for which it knows the certificate WITHOUT needing to know the private key. If you just want the PoC's, feel free to skip the intro.

DTLS

I guess most readers are very familiar with the traditional TLS handshake which is used in HTTPS on the web.

DTLS is the crayon eating brother of TLS. It was designed to be very similar to TLS, but to provide the necessary changes to run TLS over UDP. DTLS currently exists in 2 versions (DTLS 1.0 and DTLS 1.2), where DTLS 1.0 roughly equals TLS 1.1 and DTLS 1.2 roughly equals TLS 1.2. DTLS 1.3 is currently in the process of being standardized. But what exactly are the differences? If a protocol uses UDP instead of TCP, it can never be sure that all messages it sent were actually received by the other party or that they arrived in the correct order. If we would just run vanilla TLS over UDP, an out of order or dropped message would break the connection (not only during the handshake). DTLS, therefore, includes additional sequence numbers that allow for the detection of out of order handshake messages or dropped packets. The sequence number is transmitted within the record header and is increased by one for each record transmitted. This is different from TLS, where the record sequence number was implicit and not transmitted with each record. The record sequence numbers are especially relevant once records are transmitted encrypted, as they are included in the additional authenticated data or HMAC computation. This allows a receiving party to verify AEAD tags and HMACs even if a packet was dropped on the transport and the counters are "out of sync".
Besides the record sequence numbers, DTLS has additional header fields in each handshake message to ensure that all the handshake messages have been received. The first handshake message a party sends has the message_seq=0 while the next handshake message a party transmits gets the message_seq=1 and so on. This allows a party to check if it has received all previous handshake messages. If, for example, a server received message_seq=2 and message_seq=4 but did not receive message_seq=3, it knows that it does not have all the required messages and is not allowed to proceed with the handshake. After a reasonable amount of time, it should instead periodically retransmit its previous flight of handshake message, to indicate to the opposing party they are still waiting for further handshake messages. This process gets even more complicated by additional fragmentation fields DTLS includes. The MTU (Maximum Transmission Unit) plays a crucial role in UDP as when you send a UDP packet which is bigger than the MTU the IP layer might have to fragment the packet into multiple packets, which will result in failed transmissions if parts of the fragment get lost in the transport. It is therefore desired to have smaller packets in a UDP based protocol. Since TLS records can get quite big (especially the certificate message as it may contain a whole certificate chain), the messages have to support fragmentation. One would assume that the record layer would be ideal for this scenario, as one could detect missing fragments by their record sequence number. The problem is that the protocol wants to support completely optional records, which do not need to be retransmitted if they are lost. This may, for example, be warning alerts or application data records. Also if one party decides to retransmit a message, it is always retransmitted with an increased record sequence number. For example, the first ClientKeyExchange message might have record sequence 2, the message gets dropped, the client decides that it is time to try again and might send it with record sequence 5. This was done as retransmissions are only part of DTLS within the handshake. After the handshake, it is up to the application to deal with dropped or reordered packets. It is therefore not possible to see just from the record sequence number if handshake fragments have been lost. DTLS, therefore, adds additional handshake message fragment information in each handshake message record which contains information about where the following bytes are supposed to be within a handshake message.


If a party has to replay messages, it might also refragment the messages into bits of different (usually smaller) sizes, as dropped packets might indicate that the packets were too big for the MTU). It might, therefore, happen that you already have received parts of the message, get a retransmission which contains some of the parts you already have, while others are completely new to you and you still do not have the complete message. The only option you then have is to retransmit your whole previous flight to indicate that you still have missing fragments. One notable special case in this retransmission fragmentation madness is the ChangecipherSpec message. In TLS, the ChangecipherSpec message is not a handshake message, but a message of the ChangeCipherSpec protocol. It, therefore, does not have a message_sequence. Only the record it is transmitted in has a record sequence number. This is important for applications that have to determine where to insert a ChangeCipherSpec message in the transcript.

As you might see, this whole record sequence, message sequence, 2nd layer of fragmentation, retransmission stuff (I didn't even mention epoch numbers) which is within DTLS, complicates the whole protocol a lot. Imagine being a developer having to implement this correctly and secure...  This also might be a reason why the scientific research community often does not treat DTLS with the same scrutiny as it does with TLS. It gets really annoying really fast...

Client Authentication

In most deployments of TLS only the server authenticates itself. It usually does this by sending an X.509 certificate to the client and then proving that it is in fact in possession of the private key for the certificate. In the case of RSA, this is done implicitly the ability to compute the shared secret (Premaster secret), in case of (EC)DHE this is done by signing the ephemeral public key of the server. The X.509 certificate is transmitted in plaintext and is not confidential. The client usually does not authenticate itself within the TLS handshake, but rather authenticates in the application layer (for example by transmitting a username and password in HTTP). However, TLS also offers the possibility for client authentication during the TLS handshake. In this case, the server sends a CertificateRequest message during its first flight. The client is then supposed to present its X.509 Certificate, followed by its ClientKeyExchange message (containing either the encrypted premaster secret or its ephemeral public key). After that, the client also has to prove to the server that it is in possession of the private key of the transmitted certificate, as the certificate is not confidential and could be copied by a malicious actor. The client does this by sending a CertificateVerify message, which contains a signature over the handshake transcript up to this point, signed with the private key which belongs to the certificate of the client. The handshake then proceeds as usual with a ChangeCipherSpec message (which tells the other party that upcoming messages will be encrypted under the negotiated keys), followed by a Finished message, which assures that the handshake has not been tampered with. The server also sends a CCS and Finished message, and after that handshake is completed and both parties can exchange application data. The same mechanism is also present in DTLS.

But what should a Client do if it does not possess a certificate? According to the RFC, the client is then supposed to send an empty certificate and skip the CertificateVerify message (as it has no key to sign anything with). It is then up to the TLS server to decide what to do with the client. Some TLS servers provide different options in regards to client authentication and differentiate between REQUIRED and WANTED (and NONE). If the server is set to REQUIRED, it will not finish the TLS handshake without client authentication. In the case of WANTED, the handshake is completed and the authentication status is then passed to the application. The application then has to decide how to proceed with this. This can be useful to present an error to a client asking him to present a certificate or insert a smart card into a reader (or the like). In the presented bugs we set the mode to REQUIRED.

State machines

As you might have noticed it is not trivial to decide when a client or server is allowed to receive or send each message. Some messages are optional, some are required, some messages are retransmitted, others are not. How an implementation reacts to which message when is encompassed by its state machine. Some implementations explicitly implement this state machine, while others only do this implicitly by raising errors internally if things happen which should not happen (like setting a master_secret when a master_secret was already set for the epoch). In our research, we looked exactly at the state machines of DTLS implementations using a grey box approach. The details to our approach will be in our upcoming paper (which will probably have another blog post), but what we basically did is carefully craft message flows and observed the behavior of the implementation to construct a mealy machine which models the behavior of the implementation to in- and out of order messages. We then analyzed these mealy machines for unexpected/unwanted/missing edges. The whole process is very similar to the work of Joeri de Ruiter and Erik Poll.

JSSE Bugs

The bugs we are presenting today were present in Java 11 and Java 13 (Oracle and OpenJDK). Older versions were as far as we know not affected. Cryptography in Java is implemented with so-called SecurityProvider. Per default SUN JCE is used to implement cryptography, however, every developer is free to write or add their own security provider and to use them for their cryptographic operations. One common alternative to SUN JCE is BouncyCastle. The whole concept is very similar to OpenSSL's engine concept (if you are familiar with that). Within the JCE exists JSSE - the Java Secure Socket Extension, which is the SSL/TLS part of JCE. The presented attacks were evaluated using SUN JSSE, so the default TLS implementation in Java. JSSE implements TLS and DTLS (added in Java 9). However, DTLS is not trivial to use, as the interface is quite complex and there are not a lot of good examples on how to use it. In the case of DTLS, only the heart of the protocol is implemented, how the data is moved from A to B is left to the developer. We developed a test harness around the SSLEngine.java to be able to speak DTLS with Java. The way JSSE implemented a state machine is quite interesting, as it was completely different from all other analyzed implementations. JSSE uses a producer/consumer architecture to decided on which messages to process. The code is quite complex but worth a look if you are interested in state machines.

So what is the bug we found? The first bug we discovered is that a JSSE DTLS/TLS Server accepts the following message sequence, with client authentication set to required:


JSSE is totally fine with the messages and finishes the handshake although the client does NOT provide a certificate at all (nor a CertificateVerify message). It is even willing to exchange application data with the client. But are we really authenticated with this message flow? Who are we? We did not provide a certificate! The answer is: it depends. Some applications trust that needClientAuth option of the TLS socket works and that the user is *some* authenticated user, which user exactly does not matter or is decided upon other authentication methods. If an application does this - then yes, you are authenticated. We tested this bug with Apache Tomcat and were able to bypass ClientAuthentication if it was activated and configured to use JSSE. However, if the application decides to check the identity of the user after the TLS socket was opened, an exception is thrown:

The reason for this is the following code snippet from within JSSE:


As we did not send a client certificate the value of peerCerts is null, therefore an exception is thrown. Although this bug is already pretty bad, we found an even worse (and weirder) message sequence which completely authenticates a user to a DTLS server (not TLS server though). Consider the following message sequence:

If we send this message sequence the server magically finishes the handshake with us and we are authenticated.

First off: WTF
Second off: WTF!!!111

This message sequence does not make any sense from a TLS/DTLS perspective. It starts off as a "no-authentication" handshake but then weird things happen. Instead of the Finished message, we send a Certificate message, followed by a Finished message, followed by a second(!) CCS message, followed by another Finished message. Somehow this sequence confuses JSSE such that we are authenticated although we didn't even provide proof that we own the private key for the Certificate we transmitted (as we did not send a CertificateVerify message).
So what is happening here? This bug is basically a combination of multiple bugs within JSSE. By starting the flight with a ClientKeyExchange message instead of a Certificate message, we make JSSE believe that the next messages we are supposed to send are ChangeCipherSpec and Finished (basically the first exploit). Since we did not send a Certificate message we are not required to send a CertificateVerify message. After the ClientKeyExchange message, JSSE is looking for a ChangeCipherSpec message followed by an "encrypted handshake message". JSSE assumes that the first encrypted message it receives will be the Finished message. It, therefore, waits for this condition. By sending ChangeCipherSpec and Certificate we are fulfilling this condition. The Certificate message really is an "encrypted handshake message" :). This triggers JSSE to proceed with the processing of received messages, ChangeCipherSpec message is consumed, and then the Certifi... Nope, JSSE notices that this is not a Finished message, so what JSSE does is buffer this message and revert to the previous state as this step has apparently not worked correctly. It then sees the Finished message - this is ok to receive now as we were *somehow* expecting a Finished message, but JSSE thinks that this Finished is out of place, as it reverted the state already to the previous one. So this message gets also buffered. JSSE is still waiting for a ChangeCipherSpec, "encrypted handshake message" - this is what the second ChangeCipherSpec & Finished is for. These messages trigger JSSE to proceed in the processing. It is actually not important that the last message is a Finished message, any handshake message will do the job. Since JSSE thinks that it got all required messages again it continues to process the received messages, but the Certificate and Finished message we sent previously are still in the buffer. The Certificate message is processed (e.g., the client certificate is written to the SSLContext.java). Then the next message in the buffer is processed, which is a Finished message. JSSE processes the Finished message (as it already had checked that it is fine to receive), it checks that the verify data is correct, and then... it stops processing any further messages. The Finished message basically contains a shortcut. Once it is processed we can stop interpreting other messages in the buffer (like the remaining ChangeCipherSpec & "encrypted handshake message"). JSSE thinks that the handshake has finished and sends ChangeCipherSpec Finished itself and with that the handshake is completed and the connection can be used as normal. If the application using JSSE now decides to check the Certificate in the SSLContext, it will see the certificate we presented (with no possibility to check that we did not present a CertificateVerify). The session is completely valid from JSSE's perspective.

Wow.

The bug was quite complex to analyze and is totally unintuitive. If you are still confused - don't worry. You are in good company, I spent almost a whole day analyzing the details... and I am still confused. The main problem why this bug is present is that JSSE did not validate the received message_sequence numbers of incoming handshake message. It basically called receive, sorted the received messages by their message_sequence, and processed the message in the "intended" order, without checking that this is the order they are supposed to be sent in.
For example, for JSSE the following message sequence (Certificate and CertificateVerify are exchanged) is totally fine:

Not sending a Certificate message was fine for JSSE as the REQUIRED setting was not correctly evaluated during the handshake. The consumer/producer architecture of JSSE then allowed us to cleverly bypass all the sanity checks.
But fortunately (for the community) this bypass does not work for TLS. Only the less-used DTLS is vulnerable. And this also makes kind of sense. DTLS has to be much more relaxed in dealing with out of order messages then TLS as UDP packets can get swapped or lost on transport and we still want to buffer messages even if they are out of order. But unfortunately for the community, there is also a bypass for JSSE TLS - and it is really really trivial:

Yep. You can just not send a CertificateVerify (and therefore no signature at all). If there is no signature there is nothing to be validated. From JSSE's perspective, you are completely authenticated. Nothing fancy, no complex message exchanges. Ouch.

PoC

A vulnerable java server can be found _*here*_. The repository includes a pre-built JSSE server and a Dockerfile to run the server in a vulnerable Java version. (If you want, you can also build the server yourself).
You can build the docker images with the following commands:

docker build . -t poc

You can start the server with docker:

docker run -p 4433:4433 poc tls

The server is configured to enforce client authentication and to only accept the client certificate with the SHA-256 Fingerprint: B3EAFA469E167DDC7358CA9B54006932E4A5A654699707F68040F529637ADBC2.

You can change the fingerprint the server accepts to your own certificates like this:

docker run -p 4433:4433 poc tls f7581c9694dea5cd43d010e1925740c72a422ff0ce92d2433a6b4f667945a746

To exploit the described vulnerabilities, you have to send (D)TLS messages in an unconventional order or have to not send specific messages but still compute correct cryptographic operations. To do this, you could either modify a TLS library of your choice to do the job - or instead use our TLS library TLS-Attacker. TLS-Attacker was built to send arbitrary TLS messages with arbitrary content in an arbitrary order - exactly what we need for this kind of attack. We have already written a few times about TLS-Attacker. You can find a general tutorial __here__, but here is the TLDR (for Ubuntu) to get you going.

Now TLS-Attacker should be built successfully and you should have some built .jar files within the apps/ folder.
We can now create a custom workflow as an XML file where we specify the messages we want to transmit:

This workflow trace basically tells TLS-Attacker to send a default ClientHello, wait for a ServerHelloDone message, then send a ClientKeyExchange message for whichever cipher suite the server chose and then follow it up with a ChangeCipherSpec & Finished message. After that TLS-Attacker will just wait for whatever the server sent. The last action prints the (eventually) transmitted application data into the console. You can execute this WorkflowTrace with the TLS-Client.jar:

java -jar TLS-Client.jar -connect localhost:4433 -workflow_input exploit1.xml

With a vulnerable server the result should look something like this:

and from TLS-Attackers perspective:

As mentioned earlier, if the server is trying to access the certificate, it throws an SSLPeerUnverifiedException. However, if the server does not - it is completely fine exchanging application data.
We can now also run the second exploit against the TLS server (not the one against DTLS). For this case I just simply also send the certificate of a valid client to the server (without knowing the private key). The modified WorkflowTrace looks like this:

Your output should now look like this:

As you can see, when accessing the certificate, no exception is thrown and everything works as if we would have the private key. Yep, it is that simple.
To test the DTLS specific vulnerability we need a vulnerable DTLS-Server:

docker run -p 4434:4433/udp poc:latest dtls

A WorkflowTrace which exploits the DTLS specific vulnerability would look like this:

To execute the handshake we now need to tell TLS-Attacker additionally to use UDP instead of TCP and DTLS instead of TLS:

java -jar TLS-Client.jar -connect localhost:4434 -workflow_input exploit2.xml -transport_handler_type UDP -version DTLS12

Resulting in the following handshake:

As you can see, we can exchange ApplicationData as an authenticated user. The server actually sends the ChangeCipherSpec,Finished messages twice - to avoid retransmissions from the client in case his ChangeCipherSpec,Finished is lost in transit (this is done on purpose).

Conclusion

These bugs are quite fatal for client authentication. The vulnerability got CVSS:4.8 as it is "hard to exploit" apparently. It's hard to estimate the impact of the vulnerability as client authentication is often done in internal networks, on unusual ports or in smart-card setups. If you want to know more about how we found these vulnerabilities you sadly have to wait for our research paper. Until then ~:)

Credits

Paul Fiterau Brostean (@PaulTheGreatest) (Uppsala University)
Robert Merget (@ic0nz1) (Ruhr University Bochum)
Juraj Somorovsky (@jurajsomorovsky) (Ruhr University Bochum)
Kostis Sagonas (Uppsala University)
Bengt Jonsson (Uppsala University)
Joeri de Ruiter (@cypherpunknl)  (SIDN Labs)

 

 Responsible Disclosure

We reported our vulnerabilities to Oracle in September 2019. The patch for these issues was released on 14.01.2020.

Read more

• Pentest Distro
• Hacker News
• Pentest Tools
• Pentest Questions
• Pentest With Kali
• Pentest Tools Framework
• Hacking The Art Of Exploitation

Secret Hack Codes For Android Mobile Phones

Secrete Hack codes for Android Mobile phones

Secret hack codes are usually hidden from users to prevent misuse and exploit. Android is a very new platform so there aren't many hack codes for Androids available. Today I will share all of the hack codes of Android cellphones that I know. I have tested these codes on my Samsung Galaxy with the Android OS version 2.2. I am sure these will work on all previous versions. 

Secret Hack Codes for Android Mobile Phones:

1. Complete Information About Your Phone 

 *#*#4636#*#*

 This code can be used to get some interesting information about your phone and battery. It shows the following 4 menus on the screen:

• Phone information
• Battery information (How to maximize or boost battery life in android phones)
• Battery history
• Usage statistics

2. Factory data reset

*#*#7780#*#*

This code can be used for a factory data reset. It'll remove the following things:

• Google account settings stored in your phone
• System and application data and settings
• Downloaded applications

It will NOT remove:

• Current system software and bundled application
• SD card files e.g. photos, music files, etc.

Note: Once you give this code, you will get a prompt screen asking you to click on the "Reset phone" button, giving you the chance to cancel your operation.

3. Format Android Phone

  *2767*3855#

Think before you input this code. This code is used for factory formatting. It will remove all files and settings, including the internal memory storage. It will also reinstall the phone firmware.

Note: Once you give this code, there is no way to cancel the operation unless you remove the battery from the phone.

4. Phone Camera Update

*#*#34971539#*#*

This code is used to get information about phone camera. It shows following 4 menus:

• Update camera firmware in image (Don't try this option)
• Update camera firmware in SD card
• Get camera firmware version
• Get firmware update count

WARNING: NEVER use the first option. Your phone camera will stop working and you will need to take your phone to a service center to reinstall camera firmware.

5. End Call/Power

 

*#*#7594#*#*

This one is my favorite. This code can be used to change the action of the "End Call/Power" button. Be default, if you hold the button down for a long time, it shows a screen asking you to select between silent mode, airplane mode, and power off.

Using this code, you can enable this button to power off without having to select an option, saving you some time.

6. File Copy for Creating Backup

*#*#273283*255*663282*#*#*

This code opens a file copy screen where you can backup your media files e.g. images, sound, video and voice memo.

7.  Service Mode

*#*#197328640#*#*

This code can be used to enter into service mode. In service mode, you can run various tests and change settings.

8. WLAN, GPS and Bluetooth Secret Hack Codes for Android:

*#*#232339#*#* OR *#*#526#*#* OR *#*#528#*#*           – WLAN test (Use "Menu" button to start various tests)

*#*#232338#*#*                  – Shows WiFi MAC address

*#*#1472365#*#*                – GPS test

*#*#1575#*#*                      – Another GPS test

*#*#232331#*#*                  – Bluetooth test

*#*#232337#*#                    – Shows Bluetooth device address

9. Codes to get Firmware version information:

*#*#4986*2650468#*#* – PDA, Phone, H/W, RFCallDate

*#*#1234#*#* – PDA and Phone

*#*#1111#*#* – FTA SW Version

*#*#2222#*#* – FTA HW Version

*#*#44336#*#* – PDA, Phone, CSC, Build Time, Changelist number

10. Codes to launch various Factory Tests:

*#*#0283#*#* – Packet Loopback

*#*#0*#*#* – LCD test

*#*#0673#*#* OR *#*#0289#*#* – Melody test

*#*#0842#*#* – Device test (Vibration test and BackLight test)

*#*#2663#*#* – Touch screen version

*#*#2664#*#* – Touch screen test

*#*#0588#*#* – Proximity sensor test

*#*#3264#*#* – RAM version

@EVERYTHING NT

Related posts

1. Hacking Browser
2. Pentest Process
3. Hacker News
4. Hacker Website
5. Hacking Browser
6. Rapid7 Pentest
7. Pentesting
8. Pentest Process
9. Hacker

Scanning For Padding Oracles

As you might have heard, we recently got our paper on padding oracle attacks accepted to the USENIX Security Conference. In this paper, we describe and evaluate a scanning methodology with which we found several padding oracle vulnerabilities in devices from various vendors. In total, we found that 1.83% of the Alexa Top 1 Million have padding oracle vulnerabilities.

To test whether a server is vulnerable, we specified different padding oracle vectors which we send to the system under test, using different cipher suites and protocol versions. If the server does not behave identically (on both the TLS and TCP layers), we consider it to be vulnerable to a padding oracle attack, since it is leaking information about the plaintext via behavior differences. Depending on the responses to such padding oracle vectors, one can estimate which implementation is responsible for the vulnerability. We contacted quite a few website owners and tried to cooperate with them, to find out which vendors and TLS stacks are responsible for the identified vulnerabilities. You can find our current disclosure status on this issue on https://github.com/RUB-NDS/TLS-Padding-Oracles.
We are currently in contact with other vendors to fix the remaining vulnerabilities, but the some of the rare (in terms of the number of affected hosts) vulnerabilities are currently not attributed. To fix the remaining vulnerabilities, we ask for your assistance to help get rid of this issue. For this purpose, we integrated a standalone version of our padding oracle evaluation tool into our TLS-Scanner (v.2.7) project. This tool allows you (among other things) to evaluate if a specific server is vulnerable.

When the tool detects a vulnerability, it tries to attribute the vulnerability to a specific vendor or CVE. If we already know of the vulnerability of the server you scanned, the tool will print its details. If the tool does not have a description of the vulnerability in its database, it will ask you to notify us about the vulnerable server, such that we can notify the vendor and get the device fixed. To be clear: the tool never sends any data to us - you have the choice of whether to notify us (and what details to include). There is a chance that the tool's attribution is also mistaken, that is, the tool lists a vendor for your host, but you know for sure that you do not use an implementation by this vendor. Please contact us in such cases as well.

How to use the Tool

First, you need to grab hold of the tool. There are 3 ways to get your hands dirty: pre-compiled, self-compiled or Docker. We provide a pre-compiled version of the tool since the compilation process can get quite messy if you are not familiar with java and maven. You can directly download the resulting project here. However, if you also want to play around with the code, you have to compile everything yourself.

Building the TLS-Scanner

For this, you will need (Git), maven (sudo apt-get install maven), OpenJDK-8  (I can guarantee that this version works, other versions might work as well, have not tested it).

You will need to get TLS-Attacker 2.9 (if you do not already have it):
Now we can clone and install the TLS-Scanner

Docker

We also provide a Dockerfile, which lets you run the scanner directly

Getting Started

If you start the TLS-Scanner you should be greeted by a usage info, similar to the one below:

 or


This should give you an overview of the supported command line flags. The only really required one is the -connect flag (similar to OpenSSL and TLS-Attacker), with which you specify which host to scan. The most basic command is therefore:

Your output may look something like this:

By default, TLS-Scanner will run single-threaded. In such cases the scanning will take a while; just how long it will take depends on your server configuration. The scanner also supports multi-threading, which drastically improves the performance. There are two parameters to play around with, -threads, which controls how many different "probes" are executed in parallel, and -aggressive , which controls how many handshakes can be executed simultaneously. If you want the fastest results the following parameters are usually a good choice:

But lets get back to the results of the Scanner. Currently the Scanner supports a bunch of well known tests, like supported ciphersuites or protocol versions. These are very similar to what you may be used to from other scanners like ssllabs or testssl.sh.

Padding Oracles

The main advantage of our scanner is the ability to scan for padding oracle vulnerabilities (which is probably why you are reading this post). You will see if you are vulnerable in the "Attack Vulnerabilities" section. For example, when scanning hackmanit.de, the result is false. Good for us! But as you might have seen there is also another section in the scanner report:"PaddingOracle Responsemap"
This section lists the responses of the scanned host for each padding oracle vector, for each cipher suite and protocol version. For hackmanit.de, there is no detected difference in responses, which means hackmanit.de is not vulnerable to the attack:
If we want, we can also look at the concrete responses of the server. For this purpose, we start the scanner with the -reportDetail flag:

With this flag we now get the following details:

So what does this all mean? First of all, we named our malformed records. The interpretation of those names is visualized in the following table:

BasicMac-<position>-<XOR>	A Record with ApplicationData, MAC and padding bytes, where the padding byte at <position> is XOR'd <XOR>
MissingMacByteFirst	A Record without ApplicationData, where the first byte of the MAC is missing
MissingMacByteLast	A Record without ApplicationData, where the last byte of the MAC is missing
Plain FF	A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xFF
Plain 3F	A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xF3
InvPadValMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with invalid padding and valid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The Padding is invalid at <position>.
ValPadInvMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with valid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at <position>.
InvPadInvMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with invalid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at the first position. The Padding is invalid at <position>.

Next to the name you can see what the actual response from the server was. Alert messages which are in [] brackets indicate that the alert was a fatal alert while () brackets indicate a warning alert. ENC means that the messages were encrypted (which is not always the case). The last symbol in each line indicates the state of the socket. An X represents a closed socket with a TCP FIN, a T indicates that the socket was still open at the time of measurement and an @ indicates that the socket was closed with an RST. So how did Hackmanit respond? We see a [BAD_RECORD_MAC]  ENC X, which means we received an ENCrypted FATAL BAD_RECORD_MAC alert, and the TCP connection was closed with a TCP FIN. If a server appears to be vulnerable, the scanner will execute the scan a total of three times to confirm the vulnerability. Since this response is identical to all our vectors, we know that the server was not vulnerable and the scanner is not re-executing the workflows.

Here is an example of a vulnerable host:
As you can see, this time the workflows got executed multiple times, and the scanner reports the cipher suite and version as vulnerable because of "SOCKET_STATE". This means that in some cases the socket state revealed information about the plaintext. If you look closely, you can see that for ValPadInvMac-[0]-0-59, ValPadInvMac-[8]-0-59 and ValPadInvMac-[15]-0-59 the server failed to close the TCP socket, while for all other vectors the TCP connect was closed with a TCP FIN. The server was therefore vulnerable.

Since the server was vulnerable, TLS-Scanner will also print an additional section: "PaddingOracle Details"

In this section we try to identify the vulnerability. In the example above, TLS-Scanner will print the following:

As you can see, we attribute this vulnerability to OpenSSL <1.0.2r. We do so by looking at the exact responses to our malformed records. We additionally print two important facts about the vulnerability: Whether it is observable and its strength. The precise details of these properties are beyond the scope of this blogpost, but the short version is:
If an oracle is observable, a man in the middle attacker can see the differences between the vectors by passively observing the traffic, without relying on browser or application specific tricks. A strong oracle has no limitations in the number of consecutive bytes an attacker can decrypt. If an oracle is STRONG and OBSERVABLE, then an attacker can realistically exploit it. This is the case in the example above.
For more details on this, you will have to wait for the paper.

Attribution

As you can see, we try to fingerprint the responsible device/implementation. However, we were not able to identify all vulnerable implementations yet. If we cannot attribute a vulnerability you will receive the following message:

Could not identify the vulnerability. Please contact us if you know which software/hardware is generating this behavior.

If you encounter this message, we do not know yet who is responsible for this padding oracle and would be happy to know which device/vendor is responsible. If you know who is, please contact us so that we can get in contact with the vendor to fix the issue. To reiterate, the tool never sends any data back to us, and it is your choice whether to contact us manually or not.

There are also some cases in which we can identify the vendor, but the vendor has not patched the vulnerability yet. If you encounter such a host, the scanner will tell you that we know the responsible vendor. To prevent abuse, we do not include further details.

Non-Determinism and Errors

In some cases, the scanner is unable to scan for padding oracles and reports ERROR or non-deterministic responses. The ERROR cases appear if the scanner failed could not handshake with the specified cipher suite and protocol version. This might be due to a bug in the tested TLS-Server or a bug in TLS-Attacker or TLS-Scanner. If you think the handshake fails because of an issue on our side, please open an issue on Github, and we will investigate. The more interesting cases are the non-deterministic ones. In such cases the scanner observed non-identical scan results in three separate scans. This can be due to non-determinism in the software, connection errors, server load or non-homogeneous load balancing. Currently, you will have to analyze these cases manually. In the paper, we excluded such hosts from our study because we did not want to artificially improve our results. But we understand that you as a tester want to know if the server is vulnerable or not. If the server is not truly vulnerable you would see the differences between the answers spread across all the different vectors. If the differences only appear on a subset of malformed records the server is very likely vulnerable. If you are unsure, you can also always scan multiple times (or scan slowly), increase the timeout, or if you are entirely lost get in touch with us. 

How YOU can help

Please use the scanner on all your hosts and check for padding oracle vulnerabilities. If the scanner can identify your vulnerability, a patch should already be available. Please patch your system! If the scanner does not identify the vulnerability (and instructs you to contact us), please contact us with the details (robert.merget@rub.de). If you can provide us with the detailed output of the scanner or even better, the name of the host, with the corresponding vendor, we could match the results with our database and help fix the issue. We can already attribute over 90% of the vulnerabilities, but there is still a lot to be discovered. We mostly scanned the Alexa top 1-million on port 443. Other protocols like IMAPS, POP3S, etc. might have different implementations with different vulnerabilities. If you find vulnerabilities with our tool, please give us credit. It helps us to get more funding for our project.

Issues with the Scanner

A notable feature of our scanner is that we do not actively try to avoid intolerances (like not scanning with a lot of cipher suites in the Hello messages etc.). We believe that doing so would hide important bugs. We are currently experimenting with intolerances checks, but the feature is now still in beta. If we cannot scan a server (most of the time due to intolerances or SNI problems), the scanner will report a lot of intolerances and usually no supported protocol versions. Some intolerances may trick the scanner into reporting false results. At the current stage, we cannot make any guarantees. If you are using this tool during a pentest, it might be smart to rescan with other scanners (like the recently released padcheck tool from our colleague Craig Young) to find the ground truth (this is good advice in general, since other mainstream scanners likely have the same issues). Note however that it is very unlikely that the scanner reports a false positive on a padding oracle scan.

Conclusion

There are still a lot of padding oracle vulnerabilities out there - and a lot of them are still unpatched. We hope you will find some bugs with the tool :) Happy H4cking :D

Acknowlegements

This is joint work from Robert Merget (@ic0nz1), Juraj Somorovsky (@jurajsomorovsky),  Nimrod Aviram (@NimrodAviram), Janis Fliegenschmidt (@JanisFliegens), Craig Young (@craigtweets), Jörg Schwenk (@JoergSchwenk) and (Yuval Shavitt).

Related word

• Hacking Meaning
• Pentest Kit
• Pentest Partners
• Pentestmonkey Cheat Sheet
• Pentest Documentation
• Pentest Certification
• Hacking Youtube
• Pentest Online Course
• Pentest Practice Sites
• Pentestmonkey Cheat Sheet
• Pentest Questions
• Pentest Free
• Pentest Active Directory
• Pentest Firewall
• Pentest Xss
• Pentester Academy

Router-Exploit-Shovel: An Automated Application Generator For Stack Overflow Types On Wireless Routers

About Router-Exploit-Shovel
   Router-Exploit-Shovel is an automated application generation for Stack Overflow types on Wireless Routers.

   Router exploits shovel is an automated application generation tool for stack overflow types on wireless routers. The tool implements the key functions of exploits, it can adapt to the length of the data padding on the stack, generate the ROP chain, generate the encoded shellcode, and finally assemble them into a complete attack code. The user only needs to attach the attack code to the overflow location of the POC to complete the Exploit of the remote code execution.

   The tool supports MIPSel and MIPSeb.Run on Ubuntu 16.04 64bit.

Router-Exploit-Shovel's Installation
   Open your Terminal and enter these commands:
Usage

   Example: python3 Router_Exploit_Shovel.py -b test_binaries/mipseb-httpd -l test_binaries/libuClibc-0.9.30.so -o 0x00478584

Router-Exploit-Shovel's screenshot

Code structure

ROP chain generation
   This tool uses pattern to generate ROP chains. Extract patterns from common ROP exploitation procedure. Use regex matching to find available gadgets to fill up chain strings. Base64 encoding is to avoid duplicate character escapes. For example:

Attackblocks
   You can get attackblocks generated in results/attackBlocks.txt. Such as:

You might like these similar tools:

• eXpliot - Internet Of Things Exploitation Framework
• RouterSploit: Exploitation Framework for Embedded Devices

Download Router-Exploit-Shovel

Related articles

• Pentest Dns
• Pentest Blog
• Hacking Online Games
• Pentest Wiki
• Pentest Practice
• Hacking Forums
• Pentest Devices

Top 10 Most Popular Ethical Hacking Tools (2019 Ranking)

     Top 10 powerful Hacking  Tools in 2019.       

If hacking is performed to identify the potential threats to a computer or network then it will be an ethical hacking.

Ethical hacking is also called penetration testing, intrusion testing, and red teaming.

Hacking is the process of gaining access to a computer system with the intention of fraud, data stealing, and privacy invasion etc., by identifying its weaknesses.

Ethical Hackers:

A person who performs the hacking activities is called a hacker.

There are six types of hackers:

• The Ethical Hacker (White hat)
• Cracker
• Grey hat
• Script kiddies
• Hacktivist
• Phreaker

A security professional who uses his/her hacking skills for defensive purposes is called an ethical hacker. To strengthen the security, ethical hackers use their skills to find vulnerabilities, document them, and suggest the ways to rectify them.

Companies that provide online services or those which are connected to the internet, must perform penetration testing by ethical hackers. Penetration testing is another name of ethical hacking. It can be performed manually or through an automation tool.

Ethical hackers work as an information security expert. They try to break the security of a computer system, network, or applications. They identify the weak points and based on that, they give advice or suggestions to strengthen the security.

Programming languages that are used for hacking include PHP, SQL, Python, Ruby, Bash, Perl, C, C++, Java, VBScript, Visual Basic, C Sharp, JavaScript, and HTML.

Few Hacking Certifications include:

1. CEH
2. GIAC
3. OSCP
4. CREST

Let's Explore!!

#1) Nmap

Price: Free

Description:

Nmap is a security scanner, port scanner, as well as a network exploration tool. It is an open source software and is available for free.

It supports cross-platform. It can be used for network inventory, managing service upgrade schedules, and for monitoring host & service uptime. It can work for a single host as well as large networks. It provides binary packages for Linux, Windows, and Mac OS X.

Features: 

• Nmap suite has:
  • Data transfer, redirection, and debugging tool(Ncat),
  • Scan results comparing utility(Ndiff),
  • Packet generation and response analysis tool (Nping),
  • GUI and Results viewer (Nping)
• Using raw IP packets it can determine:
  • The available hosts on the network.
  • Their services offered by these available hosts.
  • Their OS.
  • Packet filters they are using.
  • And many other characteristics.

Best for: Nmap is best for scanning network. It is easy to use and fast as well.

Website: Nmap

******************

#2) Netsparker

Netsparker is a dead accurate ethical hacking tool, that mimics a hacker's moves to identify vulnerabilities such as SQL Injection and Cross-site Scripting in web applications and web APIs. 

 

Netsparker uniquely verifies the identified vulnerabilities proving they are real and not false positives, so you do not need to waste hours manually verifying the identified vulnerabilities once a scan is finished.

 

It is available as a Windows software and an online service.

=> Visit Netsparker Website Here

******************

#3) Acunetix 

Acunetix is a fully automated ethical hacking tool that detects and reports on over 4500 web application vulnerabilities including all variants of SQL Injection and XSS.

The Acunetix crawler fully supports HTML5 and JavaScript and Single-page applications, allowing auditing of complex, authenticated applications.

It bakes in advanced Vulnerability Management features right-into its core, prioritizing risks based on data through a single, consolidated view, and integrating the scanner's results into other tools and platforms.

=> Visit Acunetix Official Website

******************

#4) Metasploit

Price: Metasploit Framework is an open source tool and it can be downloaded for free. Metasploit Pro is a commercial product. Its free trial is available for 14 days. Contact the company to know more about its pricing details.

Description:

It is the software for penetration testing. Using Metasploit Framework, you can develop and execute exploit code against a remote machine. It supports cross-platform.

Features: 

• It is useful for knowing about security vulnerabilities.
• Helps in penetration testing.
• Helps in IDS signature development.
• You can create security testing tools.

Best For Building anti-forensic and evasion tools.

Website: Metasploit

#5) Aircrack-Ng

Price: Free

Description:

Aircrack-ng provides different tools for evaluating Wi-Fi network security.

All are command line tools. For Wi-Fi security, it focuses on monitoring, attacking, testing, and cracking. It supports Linux, Windows, OS X, Free BSD, NetBSD, OpenBSD, Solaris, and eComStation 2.

Features:

• Aircrack-ng can focus on Replay attacks, de-authentication, fake access points, and others.
• It supports exporting data to text files.
• It can check Wi-Fi cards and driver capabilities.
• It can crack WEP keys and for that, it makes use of FMS attack, PTW attack, and dictionary attacks.
• It can crack WPA2-PSK and for that, it makes use of dictionary attacks.

Best For: Supports any wireless network interface controller.

Website: Aircrack-Ng

#6) Wireshark

Price: Free

Description:

Wireshark is a packet analyzer and can perform deep inspection of many protocols.

It supports cross-platform. It allows you to export the output to different file formats like XML, PostScript, CSV, and Plaintext. It provides the facility to apply coloring rules to packet list so that analysis will be easier and quicker. The above image will show the capturing of packets.

Features:

• It can decompress the gzip files on the fly.
• It can decrypt many protocols like IPsec, ISAKMP, and SSL/TLS etc.
• It can perform live capture and offline analysis.
• It allows you to browse the captured network data using GUI or TTY-mode TShark utility.

Best For: Analyzing data packets.

Website: Wireshark

#7) Ettercap

Price: Free.

Description:

Ettercap supports cross-platform. Using Ettercap's API, you can create custom plugins. Even with the proxy connection, it can do sniffing of HTTP SSL secured data.

Features:

• Sniffing of live connections.
• Content filtering.
• Active and passive dissection of many protocols.
• Network and host analysis.

Best For: It allows you to create custom plugins.

Website: Ettercap

#8) Maltego

Price: The Community version, Maltego CE is available for free. Price for Maltego Classic is $999. Price for Maltego XL is $1999. These two products are for the desktop. Price for the server products like CTAS, ITDS, and Comms starts at $40000, which includes training as well.

Description:

Maltego is a tool for link analysis and data mining. It supports Windows, Linux, and Mac OS.

For the discovery of data from open sources and visualizing the information in graphical format, it provides the library of transforms. It performs real-time data-mining and information gathering.

Features:

• Represents the data on node-based graph patterns.
• Maltego XL can work with large graphs.
• It will provide you the graphical picture, thereby telling you about the weak points and abnormalities of the network.

Best For: It can work with very large graphs.

Website: Maltego

#9) Nikto

Price: Free

Description:

Nikto is an open source tool for scanning the web server.

It scans the web server for dangerous files, outdated versions, and particular version related problems. It saves the report in a text file, XML, HTML, NBE, and CSV file formats. Nikto can be used on the system which supports basic Perl installation. It can be used on Windows, Mac, Linux, and UNIX systems.

Features:

• It can check web servers for over 6700 potentially dangerous files.
• It has full HTTP proxy support.
• Using Headers, favicons, and files, it can identify the installed software.
• It can scan the server for outdated server components.

Best For: As a Penetration Testing tool.

Website: Nikto

#10) Burp Suite

Price: It has three pricing plans. Community edition can be downloaded for free. Pricing for Enterprise edition starts at $3999 per year. Price of the Professional edition starts at $399 per user per year.

Description:

Burp Suite has a web vulnerability scanner and has advanced and essential manual tools.

It provides many features for web application security. It has three editions, community, enterprise, and professional. With community editions, it provides essential manual tools. With the paid versions it provides more features like Web vulnerabilities scanner.

Features:

• It allows you to schedule and repeats the scan.
• It scans for 100 generic vulnerabilities.
• It uses out-of-band techniques (OAST).
• It provides detailed custom advisory for the reported vulnerabilities.
• It provides CI Integration.

Best For: Security testing.

Website: Burp Suite

#11) John The Ripper

Price: Free

Description:

John the Ripper is a tool for password cracking. It can be used on Windows, DOS, and Open VMS. It is an open source tool. It is created for detecting weak UNIX passwords.

Features:

• John the Ripper can be used to test various encrypted passwords.
• It performs dictionary attacks.
• It provides various password crackers in one package.
• It provides a customizable cracker.

Best For: It is fast in password cracking.

Website:  John the Ripper

#12) Angry IP Scanner

Price: Free

Description:

Angry IP Scanner is a tool for scanning the IP addresses and ports. It can scan both on local network and Internet. It supports Windows, Mac, and Linux operating systems.

Features:

• It can export the result in many formats.
• It is a command-line interface tool.
• It is extensible with many data fetchers.

Website:  Angry IP Scanner

Conclusion

As explained here, Nmap is used for computer security and network management. It is good for scanning the network. Metasploit is also for security and is good for building anti-forensic and evasion tools.

Aircrack-Ng is a free packet sniffer & injector and supports cross-platform. Wireshark is a packet analyzer and is good in analyzing data packets. As per the reviews available online, people recommend using Nmap instead of Angry IP scanner as Angry IP Scanner comes with unwanted applications.

John the Ripper is fast in password cracking. Nikto is a good open source tool for penetration testing. Maltego presents the data in a graphical form and will give you information about weak points and abnormalities.

This was all about the ethical hacking and the top ethical hacking tools. Hope you will find this article to be much useful!!

@EVERYTHING NT

Related word

• Hacking Lab
• Pentest Vs Red Team
• Pentest +
• Hacking Simulator
• Hacker Lab
• Pentest Iso
• Hacking With Python
• Pentest As A Service
• Pentest Linux
• Hacking Page
• Hacking Gif
• Pentestgeek
• Hacking Images
• Pentestbox