Saturday, February 13, 2016

SQL injection - Attacks and defense second edition by Justin Clarke

As my journey to becoming a very solid web application penetration tester continue's just taking the time out to  blog about the SQL Injection Attacks and Defense (Second Edition book). If you don't have this book in your library i would recommend you pick up a copy. This book is an excellent resource if you want to learn the in's and outs of SQL injection and how it works.  I've summarized each chapter of the book so without further ado lets get into it.

This book has 10 chapters 

Chapter 1 - What is SQL injection?

This is just basic introduction to the topic of the book. Its kinda of a weird chapter, But I would recommend that you read it and re-read it at the end. 

Chapter 2 - Testing for SQL injection

This chapter looks at SQL injection from a hackers perspective and shows how to find SQL injection samples in a web application thats connected to a database. This is a nice intro to the rest of the book. It provides useful tips about displayed SQL errors in MS SQL server, MySQL and Oracle. 

Chapter 3 - Reviewing code for SQL injection

This chapter looks at SQL injection from a "developer's point of view and shows how to follow user data through lines of PHP, Java and C# code. The end of the chapter mentions some source code analysis tools like YASCA or the MS Source Code Analyzer for SQL Injection.

Chapter 4 - Exploiting SQL injection

This chapter talks about exploiting SQL injection using steps such as identifying the database, extracting data through UNION statements, using conditional statements, enumerating the database schema, escalating privileges, stealing password hashes, out-of-band communication 

Chapter 5 - Blind SQL injection exploitation

This chapter talking about Using time-based, binary search, bit-by-bit inference and response=based techniques, they present ways to infer knowledge out of the interaction with a database. 

Chapter 6 - Exploiting the operating system
This chapter discusses ways to read and write files and execute OS commands.

Chapter 7 - Advanced topics

This chapter describes ways to evade input filters, to exploit second-order SQL injection and to use hybrid attacks.

Chapter 8 - Code-level defenses
This is the chapter that "developers" should read without any doubt. The key to avoid SQL injection attacks is to completely code the access to a database based on customised parameters that are out of the users' reach. The authors propose a series of recommendations to validate input and to encode output.

Chapter 9 - Platform-level defenses
Together with excellent coding practices, there are some measures, related to the operating platform, that we can take to avoid SQL injection. These are, for example, using web application firewalls, web server filters, IDSs and securing the database itself.

Chapter 10 - This chapter is the chapter every "white hat hacker" should have at hand when assessing a web app connected to a database. It is a great reference of SQL commands and SQL injection tweaks for SQL Server, MySQL, Oracle, PostgreSQL and even DB2.

Again i would recommend this book to anyone who is serious about really learning about sql injection.

Friday, January 1, 2016

Rooting the LG V10 Android Phone

Well it has been quite a long time since i've posted alot of things were happening in life that kept me away from blogging but i've finally made it back. Well enough of the jabber lets get to the fun part rooting your LG V10 Android Phone.

Just a little background information the LG V10 was released back in October 2015. This smartphone has some very cool specs. Beginning with an 5,7 Inch wide LCD with IPS LCD capacitive touchscreen, that works on Android OS, v5.1.1 (Lollipop) and supported with Qualcomm MSM8992 Snapdragon 808 chipset, Quad-core 1.44 GHz Cortex-A53 & dual-core 1.82 GHz Cortex-A57 of CPU, GPU adreno 418 and combined with 4 GB of RAM, 16 MP of Primary Camera, and 5 MP on Secondary camera.

Note: Before you root your phone make sure your phone has at least 80% battery life and please make sure you take a backup of all of your data. Once you've done this proceed to step 1.

Step 1. Setup ADB and Fastboot on your Computer, if your not sure how to do this check out the following link

Step 2.  You have to enable the Developer Option on your phone, (this setting is disabled by default b/c the phone gods lol dont want you to be able to unlock your phone. )

  • Go to Settings
  • Select about Phone
  • Scroll down until you see Software Info, Once you tap on Software Info you will see the build   number
  • Tap the Build number 7 times
  • Go back to the Settings and you will now see Developer Options

Step 3. Tap on Developer options and Enable both OEM unlock and USB debugging

Step 4.  Connect your LG V10 phone to your computer using the USB Cable that came with the phone.

Step 5. Boot your  LG V10 into boot loader mode: In order to boot into loader mode type the following:
adb reboot bootloader

Step 6. Now that you’re in bootloader mode, You can unlock the bootloader by typing the following command:
fastboot oem unlock

Step 7. Once bootloader on the phone is unlocked, reboot the bootloader using the following command:
fastboot reboot-bootloader

Step 8. Download and install the TWRP Recovery software from the following link

Step 9.  In order to get root on the device, you must Flash SuperSU via TWRP using the following steps.

  • Download the SuperSU software using the following link.
  • Copy the SuperSU zip file from the download link above to your device memory or SD card.
  • Boot the LG V10 device into TWRP recovery.
  • Tap on “Install” and select the SuperSU zip file that you transferred to your device.
  • After selecting the .zip file, do “Swipe to Confirm Flash” on the bottom of screen to begin the flashing process.
  • Once SuperSU is flashed, you’ll get the  “Reboot System” option, select it.

Step 10. Done (Enjoy your rooted device )

Monday, June 2, 2014

network sweeping with python

Well as of late i have decided to ditch bash and go directly with using python for all scripting tasks and so far so good :). I think python is such an awesome language and should be used instead of bash all together. I'm currently preparing for my OSCP certification exam os this is one of many tools that i will write and post for your enjoyment.  Well enough babbling from me  he goes. This tool that ive written in python is a network ping sweeper.


import subprocess
import os
with open(os.devnull, "wb") as limbo:
    for n in xrange(1, 10):
        result=subprocess.Popen(["ping", "-c", "1", "-n", "-W", "2", ip],
            stdout=limbo, stderr=limbo).wait()
        if result:
            print ip, "inactive"


           log = open("active_hosts", "a")
                print >>log,  ip

When running my script you will receive  the following output 

root@kali:/home/cyclonis/scripts/python# ./ active inactive inactive inactive inactive inactive inactive inactive active

Well i hope whoever reads this blog post gets something from it. I really enjoy sharing information with others so if you like it please feel free to use it. 

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 ( 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.
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 :-)

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 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
- 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\ 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.