terça-feira, 12 de maio de 2020
RFCrack Release - A Software Defined Radio Attack Tool
RFCrack uses the following hardware with RFCat libraries:
YardStick One:
https://goo.gl/wd88sr
I decided to cleanup my RF testing harness and release it as a tool named RFCrack
I decided to cleanup my RF testing harness and release it as a tool named RFCrack
Mostly because it has been pain to set up use-case scenarios from scratch for every device I am testing. Rather then release a tool no one knows how to use. The below video will be a quick but comprehensive tutorial to get you started If you've been following the blogs, this will greatly simplify your testing, in the following ways:
- RFCrack handles all of your data conversions.
- It allows you to capture, replay and save payloads for use anytime
- It will handle rolling code bypass attacks on your devices.
- You can jam frequencies and fuzz specific values
- It will also allow you to scan specific frequencies in discovery mode or incrementally probe them
- RFCrack will hopefully have keyless entry & engine bypass support in the near future
This is the first release, everything works as intended but there will be plenty of updates as I continue to do research and find reasons to add features needed for testing. I am still making changes and making it more flexible with modifiable values and restructuring code. If you have any legitimate use case scenarios or need a specific value to be modifiable, hit me up and I will do my best to update between research, if its a legitimate use case.
You can reach me at:
Twitter: @Ficti0n
http://cclabs.io , http://consolecowboys.com
You can reach me at:
Twitter: @Ficti0n
http://cclabs.io , http://consolecowboys.com
GitHub Code for RFCrack:
https://github.com/cclabsInc/RFCrackFull RF Hacking Course in Development:
Not all of the attacks in the tool have been covered in the RF hacking blog series and a few more are in research mode, as such, not yet added to the tool but will probably be covered in a full length online class on Hacking with RF which includes all targets and equipment. Send an email to info(at)cclabs.io if your interested.Walkthrough Training Video:
Until Next time:
Cheers, and enjoy the tool for your personal use testing devices, feedback and bug reports are appreciated. I have another RF blog coming out shortly based on my friends research into hacking garages/gates and creating keyfobs. I will post when its ready.Related articles
Save Your Cloud: DoS On VMs In OpenNebula 4.6.1
This is a post about an old vulnerability that I finally found the time to blog about. It dates back to 2014, but from a technical point of view it is nevertheless interesting: An XML parser that tries to fix structural errors in a document caused a DoS problem.
All previous posts of this series focused on XSS. This time, we present a vulnerability which is connected another Cloud Management Platform: OpenNebula. This Infrastructure-as-a-Service platform started as a research project in 2005. It is used by information technology companies like IBM, Dell and Akamai as well as academic institutions and the European Space Administrations (ESA). By relying on standard Linux tools as far as possible, OpenNebula reaches a high level of customizability and flexibility in hypervisors, storage systems, and network infrastructures. OpenNebula is distributed using the Apache-2 license.
OpenNebula offers a broad variety of interfaces to control a cloud. This post focuses on Sunstone, OpenNebula's web interface (see Figure 1).
Before OpenNebula 4.6.2, Sunstone had no Cross-Site Request Forgery (CSRF) protection. This is a severe problem. Consider an attacker who lures a victim into clicking on a malicious link while being logged in at a private cloud. This enables the attacker to send arbitrary requests to the private cloud through the victims browser. However, we could find other bugs in OpenNebula that allowed us to perform much more sophisticated attacks.
OpenNebula saves the incorrectly generated XML document in a database. The next time the OpenNebula core retrieves information about that particular VM from the database the XML parser is mixed up and runs into an error because it only expects a string as name, not an XML tree. As a result, Sunstone cannot be used to control the VM anymore. The Denial-of-Service attack can only be reverted from the command line interface of OpenNebula.
This bug can be triggered by a CSRF-attack, which means that it is a valid attack against a private cloud: By luring a victim onto a maliciously crafted website while logged in into Sunstone, an attacker can make all the victim's VMs uncontrollable via Sunstone. A video of the attack can be seen here:
All previous posts of this series focused on XSS. This time, we present a vulnerability which is connected another Cloud Management Platform: OpenNebula. This Infrastructure-as-a-Service platform started as a research project in 2005. It is used by information technology companies like IBM, Dell and Akamai as well as academic institutions and the European Space Administrations (ESA). By relying on standard Linux tools as far as possible, OpenNebula reaches a high level of customizability and flexibility in hypervisors, storage systems, and network infrastructures. OpenNebula is distributed using the Apache-2 license.
OpenNebula offers a broad variety of interfaces to control a cloud. This post focuses on Sunstone, OpenNebula's web interface (see Figure 1).
 |
| Figure 1: OpenNebula's Sunstone Interface displaying a VM's control interface |
Before OpenNebula 4.6.2, Sunstone had no Cross-Site Request Forgery (CSRF) protection. This is a severe problem. Consider an attacker who lures a victim into clicking on a malicious link while being logged in at a private cloud. This enables the attacker to send arbitrary requests to the private cloud through the victims browser. However, we could find other bugs in OpenNebula that allowed us to perform much more sophisticated attacks.
Denial-of-Service on OpenNebula-VM
At its backend, OpenNebula manages VMs with XML documents. A sample for such an XML document looks like this:<VM>OpenNebula 4.6.1 contains a bug in the sanitization of input for these XML documents: Whenever a VM's name contains an opening XML tag (but no corresponding closing one), an XML generator at the backend automatically inserts the corresponding closing tag to ensure well-formedness of the resulting document. However, the generator outputs an XML document that does not comply with the XML schema OpenNebula expects. The listing below shows the structure that is created after renaming the VM to 'My <x> VM':
<ID>0</ID>
<NAME>My VM</NAME>
<PERMISSIONS>...</PERMISSIONS>
<MEMORY>512</MEMORY>
<CPU>1</CPU>
...
</VM>
<VM>The generator closes the <x> tag, but not the <NAME> tag. At the end of the document, the generator closes all opened tags including <NAME>.
<ID>0</ID>
<NAME>My <x> VM</x>
<PERMISSIONS>...</PERMISSIONS>
<MEMORY>512</MEMORY>
<CPU>1</CPU>
...
</NAME>
</VM>
OpenNebula saves the incorrectly generated XML document in a database. The next time the OpenNebula core retrieves information about that particular VM from the database the XML parser is mixed up and runs into an error because it only expects a string as name, not an XML tree. As a result, Sunstone cannot be used to control the VM anymore. The Denial-of-Service attack can only be reverted from the command line interface of OpenNebula.
This bug can be triggered by a CSRF-attack, which means that it is a valid attack against a private cloud: By luring a victim onto a maliciously crafted website while logged in into Sunstone, an attacker can make all the victim's VMs uncontrollable via Sunstone. A video of the attack can be seen here: