Thursday, April 3, 2014

OSWP Certified

Hello everyone, it has been a while since i've been blogging shame on me ive been working on becoming a penetration tester.  I started off with taking the OSWP certification from Offensive Security. This certification focuses on wireless penetration testing,  I had to hack into various wireless routers with different configurations and settings in a matter of 3 hours once the exam was over , I had to submit a Pentest report to the Offensive Security Staff to verify that i was able to penetrate and crack the wireless encryption keys. In order to prepare for this exam I would suggest purchasing some alfa and tp link wireless network cards from the internet along with some old wireless routers and start attacking wep wpa2 and other wireless encryption settings. I'm currently on a journey to keep learning all that i can and become the best hacker i can be i love hacking and coding and finding new exploits this is a wonderful feeling and going through this challenge was a wonderful experience and i would encourage anyone  that is looking  for a challenge in security/hacking to sign up for Offensive Security Certifications they are really worth it My next challenge will be OSCP certification im looking forward to getting into the labs. Well thats enough rambling from me time for bed sunrise will be here before i know it. 

Friday, January 3, 2014

Bluetooth Sniffing For Less

 Bluetooth Sniffing For Less

HBluetooth Security seems to be very good compared to 802.11 problems. But most of the Bluetooth Security is based the PIN you have to enter during pairing two devices or on the link key, which is a result of it. In addition Bluetooth uses much more channels and hops frequently within the spectrum, which makes Analyzing a real pain. Sniffing raw communication without being paired is until now only available to rich companies or individuals which could buy one of the over-priced Bluetooth Sniffers.
When i say High-Priced i talk about 10'000 US$. Frontline (http://www.fte.com) is one of the few Bluetooth Sniffer manufacturers and they sell their application together with a "special" Bluetooth sniffer ComProbe / dongle. Here are some marketing highlights from their FTS4BT product website:

Supports EDR (Enhanced Data Rate): FTS4BT is the only analyzer currently on the market to support Bluetooth v2.0 + EDR. - Finger-sized Bluetooth ComProbe: Air sniffing hardware is incredibly portable and requires no power. - Synchronized air and HCI sniffing: FTS4BT provides multiple points of observation, speeding up debug time. - Real-time debugging: FTS4BT captures, decodes, filters and displays data, and detects protocol errors simultaneously, all live and in real-time.

Decodes all Bluetooth protocols and most profiles. Quick release of new profiles to keep pace with changing Bluetooth specifications. - Extract Audio into WAV files for playback and analysis. - Includes Framedecoder for rapid development and seamless integration of HCI Vendor Extensions and other custom protocol implementations. - This Frontline technology is how we meet Bluetooth challenges.
 
Current:
--------
It is in fact very easy to modify a very cheap standard USB dongle to be usable
as comprobe and together with the nifty keygenerator, everyone can analyze
Bluetooth. Follow the instructions below to get your Bluetooth raw sniffer for
a few bugs. So for the marketing: This piece of reversing is how we meet the
Frontline challenges :-)

Warning:
--------
Using a keygenerator to run illegal software copies is prohibited in many
countries and you do it at your own risk. And we still think that you should buy
this expensive tools if you do business with it.

Prepare yourself:
-----------------
To conduct all the steps you need the following:
- Linux installation with Bluez and the important BCCMD, BDADDR and DFUTOOL
  from the CVS tree. Get it at http://www.bluez.org. A few security testing 
  focused Linux distributions have them already pre-installed.
- A supported CSR chip based Bluetooth dongle
- A copy of the FTS4BT software (Should be available in combination with this
  howto)
- A copy of the license and authentication code generator (Should be available
  in combination with this howto) 
 
Step 1 - Backup original firmware:
----------------------------------
First you want to backup your USB sticks current firmware and configuration for
later use. Follow the points below to do this:

- Insert your stick into your linux machine and do a hciconfig  up
  (Most often  is hci0). Check using hciconfig -a if the device is
  there and UP. Looks somewhat similar to that list below i suggest that you
  copy your information to a safe place, in case you want to switch back to it:

linux ~ # hciconfig -a
hci0:   Type: USB
        BD Address: 00:DE:EA:DB:EE:EF ACL MTU: 192:8 SCO MTU: 64:8
        UP RUNNING
        RX bytes:85 acl:0 sco:0 events:9 errors:0
        TX bytes:30 acl:0 sco:0 commands:8 errors:0
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
        Name: 'COMPUTER'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Ver: 1.1 (0x1) HCI Rev: 0x33c LMP Ver: 1.1 (0x1) LMP Subver: 0x33c
        Manufacturer: Cambridge Silicon Radio (10)
 
- Write down your btaddr (similar to mac addr),in our case its 00:DE:EA:DB:EE:EF
  You will need it later on, so write it down. Tip: You can also set a specific
  address using the tool btaddr which als also from bluez.
- Now just backup the current firmware using the dfutool. Please notice that
  ID 0a12:0001 thats the vendor and product id (You can also get it using lsub).
  We need the product to be 0002  but we do this a bit later. Now do your
  backup, it should look like the  example below. Please not that doing this in
  virtual machines may fail.In addition you need to use again hciconfig
   up after the dfutool because it resets the state of the device.:

linux ~ # dfutool -d hci0 archive my_bluetooth_dongle_firmware_backup.dfu
Available devices with DFU support: 
 
2) Bus 1 Device 2: ID 0a12:0001 Interface 2

Select device (abort with 0): 2

Firmware upload ... 358832 bytes

linux ~ # hciconfig hci0 up 
 
Step 1 - View original configuration:
-------------------------------------
Acording to the CSR specifications there are multiple places to read stuff on
the stick. Depending on your product these can be different. In generel these 
are "Default" (0x0000), "param" (0x0008), "psi" (0x0001), "psf" (0x0002) and 
"psrom" (0x0004). You can use those values usind bccmd pslist -s . Its 
even more easy if you like to get a complete list of parameters, just use:

linux ~ # bccmd -d hci0 pslist -s 0x000F >> backup-configuration 

look in there for the lines that contains something similar to these:
"0x02bf - USB product identifier (2 bytes)"  
"0x02be - USB vendor identifier  (2 bytes)"   

Now get the values of those two bytes:

Use the following command to get the location of the product id:
linux ~ # bccmd -d hci0 psget -s 0x000f 0x02bf 
USB product identifier: 0x0001 (1): 
This is what we want to change later

linux ~ # bccmd -d hci0 psget -s 0x000f 0x02be 
USB vendor identifier: 0x0a12 (2578): 
If you have something different we have to change it as well
 
Step 2 - Change product ID:
----------------------------------------
Acording to the CSR specifications there are multiple places to store stuff. On
most dongles we know about it the product id is stored in "psf" (0x0002). Never 
mind if its not there just check your configuration and search for it. If you 
the right location then use the following or similar line to modify the product
id from 0x0001 to 0x0002. Otherwise Frontline drivers wont install properly.

linux ~ # bccmd -d hci0 psset -s 0x0002 0x02bf 0x0002 new id

If you got no feedback then it was successful, check it by reading that value 
again using:

linux ~ # bccmd -d hci0 psget -s 0x000f 0x02bf 
USB product identifier: 0x0002 (2)
yeah data-blogger-escaped-baby="" data-blogger-escaped-pre="">
 
Step 2 1/2 - Change vendor ID:
----------------------------------------
Most dongles i did see where Cambridged Silicon Radio,so its likely that
you will get 0x0a12 as the usb vendor id. If you got that one, your finished 
with modifications on your dongle. Go to Step 3 of this guide. When you are 
using the Toshiba Version 2.0 + ERD dongle (which is amazing) you need to change
also the vendor id from 0x0903 to 0x0a12 uing psget/psset.

Step 3 - Install the sniffer software
-------------------------------------
I guess i dont have to explain that. Use your license or generate one if you 
got a keygen :-). Please note, its important on the keygen that you enter the
mac / btaddr of your dongle in lowercase and without any ":".

The keygen is available as a linux binary as well as windows .exe file

Use the serial number during installation. You will get a Desktop Folder with a
lot of links. Don't delete it you will need it. 

Step 4 - Install the USB stick driver from frontline
----------------------------------------------------
When you insert your stick, windows will try to install a driver. You will find
it in your Frontline installation dirctory, quite simple uh?

Step 6 - Install the firmware package from frontline
----------------------------------------------------
Pretty straigth forward, but you will need it.

Step 7 - Configure the sticks firmware etc.
------------------------------------------- 
Open the Bluetooth ComProbe Maintenance Utility. You find a shortcut on 
"Desktop\5.6.9.0 FTS4BT\Setup" or at similar places. Use the "Select Device" 
button and if you did previous steps correct, it will be detected. Yeah!
Now use "Update Firmware" to update your desired firmware version (You will 
find it in the subfolder "Bluetooth ComProbe Firmware" in the frontline 
installation directory. I normaly use the latest one. After that you should 
use "Check Configuration" to configure the stick with the serial and the 
authentication code. Finally i suggest to use "Calibrate" which takes time.

Step 8 - Use it
--------------- 
Thats it.

Future / Todo:
-------
We did the first step and show you how to do it for less, now its the
communities opurtunity to take that know-how and generate a custom, free
firmware and sniffer module to generate a real opensource sniffer.

 

Thursday, January 2, 2014

New Year Ramblings :)

Well its a New Year 2014 i still cannot believe it, Well like the old saying goes time flies when you having :).  2014 is going to be a big year i've decided to focus more on security mainly wireless and web app pentesting those are my main areas of focus. This will keep me busy for the next lifetime.  Well thats enough jabbering from me,  whoever is reading this post i just want to wish you a very happy and prosperous year in what  ever you do.  :)

Saturday, December 7, 2013

Wifi Sniffing Ilegal ?

A couple years ago, we were disappointed to see a judge take the technologically wrong stance that data transmitted over WiFi is not a "radio communication," thereby making sniffing of unencrypted WiFi signals potentially a form of wiretapping. Indeed, based on that, the court eventually ruled that Google's infamous WiFi sniffing could be a violation of wiretap laws. This is wrong on so many levels... and tragically, an appeals court has now upheld the lower court's ruling.

There are serious problems with this. Under no reasonable view is WiFi not a radio communication first of all. That's exactly what it is. Second, sniffing unencrypted packets on an open network is a perfectly normal thing to do. The data is unencrypted and it's done on a network that is decidedly open. It's like saying it's "wiretapping" for turning on your radio and having it catch the signals your neighbor is broadcasting. That's not wiretapping. Third, even the court here admits that based on this ruling, parts of the law don't make any sense, because it renders those parts superfluous. Generally speaking, when a court ruling would render a part of a law completely superfluous, it means that the court misinterpreted the law.

Bizarrely, the court seems to rely on the claim that most radio communications are "auditory" (i.e., involving sound) and thus data transmissions are somehow not radio. Seriously. This statement is so uninformed and flat out wrong that it's kind of shocking the court made it. Specifically the ruling says that the "telltale signs" of "radio communications" are that they're (1) "auditory" and (2) "broadcast" and then says it doesn't even need to consider whether or not WiFi signals are broadcast, since the fact that they're not auditory means they don't even have to consider that fact. Seriously. Read this and try not to bang your head on the nearest desk or wall:
We need not reach the question of what exactly constitutes a "broadcast" because the Wi-Fi transmissions in question were not predominantly auditory.
The court also stumbles badly on the other key question in the lawsuit -- over whether or not these things are "readily accessible to the general public." Again, here, if you know anything about the technology you know without question that broadcasting unencrypted data over an open WiFi network are by definition "readily accessible to the general public." That's how it works and how it was designed to work. But the court says it's not because someone might send something "sensitive" from a secured network to an open WiFi network, and the sender didn't intend for that info to be available via open WiFi. But that gets the calculus totally wrong. First, if I'm sending something "sensitive," it should be encrypted, full stop. Second, the security of the endpoint recipient is the responsibility of that recipient, not the sender, so the whole analogy makes no sense.

Later, the court argues that WiFi isn't readily accessible because the signal is "geographically limited." But, um, again, that's true of just about any radio signal. If I have a low-power transmitter, that's still a radio transmitter. It also claims that it's "difficult" to access unencrypted data on an open network, but that's not true at all. They claim it requires "sophisticated" hardware and software, but that's not actually true, and if you believe it's true, you could basically make the same argument about all kinds of radio transmissions.

Either way, there's a fundamental fact here that the courts don't seem to recognize: when you broadcast unencrypted data on an open network it's there for anyone to access. It seems ridiculous to then claim that it's illegal to access it when it's presented in a manner that more or less cries out "come take a look!" This really feels like a situation where the court looked at what Google did, decided it didn't like it, and then tried to tap dance around reality to make it a violation of the law even though it's almost certainly not a violation.

Saturday, August 3, 2013

Recompiling the linux Kernel in Centos

The Linux Kernel is a very interesting piece of Software. Recompiling a linux Kernel is every Linux Geeks right of passage. This is a tutorial on how to Recompile the Linux Kernel.The reasons to compile kernels are far and few in between. You may want to consider doing this if you have exotic architecture or hardware that the mainline kernel does not support, which is a rarity today. Another reason may be performance benefits. If you have a very old machine, creating a custom kernel with a minimal disk and memory footprint could be your thing. Similarly, if you need a kernel for an odd target device that has constrained resources, like a router or such, the only way to get past the limitations would be by compiling your own kernel, Well enough babbling from me lets begin with the process.

Step 1 Install the kernel-devel kernel-headers packages

    [root@blizzard ~]# yum install kernel-devel kernel-headers ncurses  ncurses-devel


Step 2  Install the Development and Debugging Tools these will be needed in order to recompile the linux kernel.

     [root@blizzard ~]# yum groupinstall "Development-Tools" "Debugging Tools"


Step 3  Grab a copy of the lastest kernel. The latest version of the kernel at the time of this writing is 3.6

     [root@blizzard ~]#  wget  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.87.tar.gz


Step 4 Copy the linux-3.0.87.tar.gz kernel package over to the /usr/src directory.This directory holds the linux kernel sources.

[root@blizzard csh11]# cp linux-3.6.tar.gz /usr/src/

Step 5  Unpack the Linux Kernel Package

[root@blizzard src]# tar -xzvf linux-3.0.87.tar.gz


Step 6  Change into the linux-3.6  Directory

[root@blizzard src]# cd linux-3.0.87 


Step 7 Run the make menuconfig (text menu) or make config to configure the kernel
Note: its always best to run the make menuconfig command its alot easier to select or deselect modules.

[root@blizzard src]#  make config


Step 8 Run the make command

[root@blizzard src]#  make 



Step 9 Install the kernel

[root@blizzard src]#  make modules_install install


Step 10 Verify that the new kernel has been install

[root@blizzard src]#  uname -r 


That's it I hope this article will be useful to anyone trying to learn about recompiling the linux kernel in centos.





Tuesday, June 25, 2013

Freebsd on SonyPlayStation 4

This is a wonder time of the year, Freebsd is now 20 years old created by David Greenman, Jordan Hubbard, and Rod Grimes, which started out as freebsd4.3  later to be named freebsd. and I'm finding out that the new SonyPlayStation 4 will be running a modified version of Freebsd 9.0, Sony calls it Orbis OS. This is very good news for hackers and developers looking to do some interesting things with this version of the OS. The PlayStation 4 will offer either console or gui access when booting up the console. Hmmmmm i wonder if i can install python on it lol :). Well this is some cool stuff i will definitely keep everyone posted as time goes on.

Sunday, June 23, 2013

Freebsd on the Rasberry Pi

As of late i've been doing alot of work with freebsd from converting all of my centos servers over to freebsd. Now its time to get freebsd running on the rasberry pi.  Installing FreeBsd on the rasberry pi was pretty simple. I took the following steps in order to get freebsd installed on the pi.


Step 1 ->  get an image i used the following image FreeBSD-HEAD-r249996-ARMv6-RPI-B-WIFI-3GB.img.tgz. Open a web browser and go to the folllowing url http://files.khubla.com/freebsd-raspberry-pi/FreeBSD-HEAD-r249996-ARMv6-RPI-B-WIFI-3GB.img.tgz, or if your a command line buff like my self lol :) you can run the following command











Step2 -> Extract the downloaded image







Step3 -> Umount the SD card






Step4 -> Copy the image to the SD  card using the dd utility (Unix/linux/Mac)  as for windows im not sure what utility to use , but google.com can take care of this issue for you :).






Step5-> Unmount the SD card Again



Once the above steps have been completed, boot up the rasberry pi and bingo you will see the following screen. NOTE: username:pi   password:raspberry  once logged in you can su to root