Bypassing CAPTCHAs by Impersonating CAPTCHA Providers

By Gursev Kalra.

CAPTCHA service providers validate millions of CAPTCHAs each day and protect thousands of websites against the bots. A secure CAPTCHA generation and validation ecosystem forms the basis of the mutual trust model between the CAPTCHA provider and the consumer. A variety of damage can occur if any component of this ecosystem is compromised.

During Analysis of the CAPTCHA integration libraries provided by several CAPTCHA providers (including reCAPTCHA) revealed that almost all of the CAPTCHA verification API’s relied on plain text HTTP protocol to perform CAPTCHA validation. Because of this, the CAPTCHA provider’s identity was not validated, message authentication checks were not performed and the entire CAPTCHA validation was performed on an unencrypted channel. This vulnerability was also reported to reCAPTCHA team several months back.

If you decompile the .NET Plugin, you'll be able to pull out reCAPTCHA's verification URL, which demonstrates the absense of HTTPS:

In the current scenario, two types of attacks can be launched against vulnerable CAPTCHA implementations. These attacks are based on the assumption that an attacker is able to intercept the CAPTCHA validation traffic between target website and the CAPTCHA provider.

Private Key Compromise

Most of CAPTCHA providers issue private and public keys to identify a particular consumer and to enforce an upper limit on the number of CAPTCHAs used by them. Private keys are often sent over to the CAPTCHA provider during the CAPTCHA validation process. If the public and private keys are sent using plain text HTTP, an attacker could sniff the private keys and:

1. Use the CAPTCHA service for without registering for the service by using the captured keys.
2. Exhaust the target web site’s CAPTCHA quota for the service, which depending on the CAPTCHA provider may cause a wide variety of unexpected issues.

The CAPTCHA Clipping Attack

The following image describes what I call the "CAPTCHA Clipping Attack". Notice that steps 5 and 6 in blue would be the normal operation of events. We'll go into the attack in a little more detail below.

Since the website’s application server acts as a client to CAPTCHA provider during steps 5 and 6 (in blue) and the application server often neglects to validate the CAPTCHA provider’s identity and the session integrity checks, an attacker may be able to impersonate the CAPTCHA provider and undermine the anti-automation protection (steps 5 and 6 in red). CAPTCHA validation responses are mostly Boolean (true or false, success or failure, pass or fail, 0 or 1). The response format and its contents are also publicly available as part of CAPTCHA provider’s API documentation. This allows an attacker to easily construct the finite set of possible responses, impersonate the CAPTCHA provider, and perform malicious CAPTCHA validation for the application servers.

To exploit this vulnerability an attacker performs the following:

1. The attacker acts as a legitimate application user and submits a large number of requests to the web application.
2. At the same time, he/she intercepts CAPTCHA validation requests, masquerades as the CAPTCHA provider and approves all submitted requests.

Masquerading as the CAPTCHA provider and not forwarding the CAPTCHA validation requests to the actual CAPTCHA provider is the CAPTCHA Clipping Attack.

clipcaptcha

clipcaptcha is a proof of concept exploitation tool that specifically targets the vulnerabilities discussed above and allows complete bypass of CAPTCHA provider protection. clipcaptcha is built on the sslstrip codebase and has the following features:

1. Performs signature based CAPTCHA provider detection and clipping.
2. Can be easily extended to masquerade as any CAPTCHA provider by adding corresponding signatures to the configuration XML file.
3. Has built in signatures of several CAPTCHA providers including reCAPTCHA, OpenCAPTCHA, Captchator etc…
4. Logs POST requests that match any supported CAPTCHA provider to capture private and public keys. Unmatched requests are forwarded as is.
5. clipcaptcha supports five operational modes. These are “monitor”, “stealth”, “avalanche”, “denial of service” and “random”.

Download

clipcaptcha can be downloaded here:

• https://github.com/OpenSecurityResearch/clipcaptcha

Fuente:http://blog.opensecurityresearch.com

Sniffing on the 4.9GHz Public Safety Spectrum

By Brad Antoniewicz.

Probably the most important thing to mention about the 4.9GHz spectrum is that you need a license to operate in it! If you don't have a license (I'm pretty sure you don't) - IT MAY BE ILLEGAL TO INTERACT WITH THIS BAND.

You've been warned - That all being said, let's talk about public safety.

What is the Public Safety Spectrum?

The Public Safety Spectrum is the name for a number of reserved ranges in radio spectrum allocated by the FCC and dedicated for the "sole or principal purpose of protecting the safety of life, health, or property". Basically it's used for police, ambulance, fire, and in some cases, utilities to communicate.

The 4.9GHz Public Safety Spectrum (4.940GHz to 4.990GHz) is one of these reserved public safety ranges. It's mainly for short distance, almost line of sight, communications. It's used from everything to create "on the scene" networks so that the police and other responders can share and transfer data, to video camera systems around a fixed location.

The neat thing about the 4.9Ghz spectrum is that the pretty much de-facto standard used in it is IEEE802.11! It takes some deviations from the standard, such as allowing for 1MHz, 5MHz, 10MHz or 20MHz channels, but other then that, it is plain old 802.11 on a different spectrum.

Interacting with the Spectrum

To interact with the spectrum, you'll need an FCC LICENSE (!! if you skipped to this part, please see the first paragraph), and an adapter that is capable of transmitting/receiving on the 4.9GHz spectrum. There are some adapters already out there, such as the Ubiquiti SuperRange 4 Cardbus (SR4C), but no one likes spending more money if they don't have to!

An 4.9GHz adapter you might have already in your possession and not even know it is the Ubiquiti SuperRange Cardbus (SRC or SRC300)! The internal Atheros chipset actually supports from 4.910GHz to 6.1GHz! That's much more then originally advertised :)

The problem is though, if you want to use the cards with any of the standard Linux tools, you're more or less screwed! The current ath5k drivers don't officially support 4.9GHz. There are a couple of patches for older versions of the driver, but some don't work or can't be applied to the current stable driver release. Another issue is that some drivers don't support the 5MHz, 10MHz or 20MHz channel widths.

About the 4.9GHz Driver Patch

I took some time out and wrote up a quick patch for the current version of compat-wireless. I used some of the patches mentioned above as starting point, and then followed the code comments in the existing drivers to implement the channel widths correctly.

Enabling 4.9GHz

To enable the extended frequency ranges, I just modified the driver to accept frequencies as low as 4.910GHz. There was a "ath_is_49ghz_allowed()" function that defined if the regulatory domain was allowed to access that range. I modified this function to always return true. The regulatory domain is often stored within your cards EEPROM and defines what region the card will be operating in. The mac80211 drivers query this value to determine what frequencies you're allowed to use. Based on that value, the driver will either consult its internal (statically defined) regulatory database, or if present, the Central Regulatory Domain Agent (CRDA). The CRDA is a user land agent that defines what frequencies are used within a region. The idea is that if you're in a different regulatory domain then the one your card is registered for, you can dynamically change the allowed frequencies without making any driver changes. You would do this with the "iw" command:

 root@bt:~# iw reg set 

One problem I came across is that the driver won't consistently respect a regulatory domain that is defined this way. For example, if my card's EEPROM is set for US, but I set the World regulatory domain ("00"), sometimes it won't actually apply it or won't allow me to use the channels enabled by the extended regulatory domain. Because of this, I took the somewhat brutish approach of just returning true for "ath_is_49ghz_allowed()".

I really wanted to make this patch work with the smallest number of module changes, because the more complicated the module change, the more likely it will break in future releases. Plus, most of the code to support 4.9GHz was already there!

Rather than setting the 4.9GHz channels, etc.. statically within the driver, I also decided to leverage the CRDA, since it can be changed without needing the driver to be rebuilt.

Channel Widths

By default the compat-wireless drivers support 20MHz channel widths. Because 4.9GHz can have 1MHz, 5MHz, 10MHz, or 20MHz channels, the driver needed to be modified to support this. Luckily the driver code comments spell out what needs to be done, and much of the support already existed - it just wasn't used. I modified the drivers as per the code comments, and took a tip from the RADAR patch by adding the "default_bwmode" module parameter so that people can specify the channel width when they load the module.

Installation

Installing the patch is easy. Since I use non-persistent BackTrack for everything, I'll provide instructions using that as a base. You can either perform the installation manually or the "easy way" which is using a script I created.

Download

You should really read on, but if you're impatient and just want stuff to download, here is the download link:

• https://github.com/OpenSecurityResearch/public-safety/tree/master/4.9ghz

The Easy Way

If you'd like to use this method, you'll just need internet access. Also, once you complete the "easy" way, you can use that directory for an offline installation later on. To install make sure you have internet access and:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/public-safety
 root@bt:~# cd public-safety/4.9ghz/
 root@bt:~/public-safety/4.9ghz# chmod +x 49ghz_install.sh
 root@bt:~/public-safety/4.9ghz# ./49ghz_install.sh

That should be it (told you it was easy)! It'll auto create a monitor mode VAP using 10mhz wide channels.

Manual Installation

Manual installation is pretty simple too, but some people hate typing :) To install everything from scratch, first install all the prerequisites:

 root@bt:~# apt-get install libnl-dev libssl-dev python-m2crypto build-essential 

Next, we'll need to set up CRDA. The CRDA consults a database for its regulatory information. This database is called the wireless-regdb. You'll also need to sign the database. So lets create some keys to do that:

 root@bt:~# openssl genrsa -out key_for_regdb.priv.pem 2048 
 root@bt:~# openssl rsa -in key_for_regdb.priv.pem -out key_for_regdb.pub.pem -pubout -outform PEM

Now, we'll download wireless-regdb, extract it, and build:

 root@bt:~# wget http://linuxwireless.org/download/wireless-regdb/wireless-regdb-2011.04.28.tar.bz2
 root@bt:~# tar -jxf wireless-regdb-2011.04.28.tar.bz2
 root@bt:~# cd wireless-regdb-2011.04.28
 root@bt:~/wireless-regdb-2011.04.28# make

The regulatory database is just a plain-text file that is then converted to the format CRDA expects. You can modify your database any way you'd like, or you can just use the one I created (db-ReturnTrue.txt):

 root@bt:~/wireless-regdb-2011.04.28# wget https://raw.github.com/OpenSecurityResearch/public-safety/master/4.9ghz/db-ReturnTrue.txt
 root@bt:~/wireless-regdb-2011.04.28# cp db-ReturnTrue.txt db.txt
 root@bt:~/wireless-regdb-2011.04.28# ./db2bin.py regulatory.bin db.txt ../key_for_regdb.priv.pem
 root@bt:~/wireless-regdb-2011.04.28# make install

Now that our regulatory database is all set up, lets install CRDA to leverage it. Notice that after we download and extract, we also copy over our public keys to the locations CRDA is expecting them to be. This is so it can validate the authenticity of the regulatory database we created.

 root@bt:~# wget http://linuxwireless.org/download/crda/crda-1.1.2.tar.bz2
 root@bt:~# tar -jxf crda-1.1.2.tar.bz2
 root@bt:~# cd crda-1.1.2
 root@bt:~/crda-1.1.2# cp ../key_for_regdb.pub.pem pubkeys/
 root@bt:~/crda-1.1.2# cp ../key_for_regdb.pub.pem /usr/lib/crda/pubkeys
 root@bt:~/crda-1.1.2# make
 root@bt:~/crda-1.1.2# make install

So now we can get to the compat-wireless installation. First download it, then extract:

 root@bt:~#  wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-1.tar.bz2
 root@bt:~# tar -jxf compat-wireless-3.3-1.tar.bz2
 root@bt:~# ln -s /usr/src/linux /lib/modules/`uname -r`/build
 root@bt:~# cd compat-wireless-3.3-1

Next we'll unload any conflicting drivers (I'm being a little redundant with these two commands, I know):

 root@bt:~/compat-wireless-3.3-1# sudo scripts/wlunload.sh
 root@bt:~/compat-wireless-3.3-1# sudo modprobe -r b43 ath5k ath iwlwifi iwlagn mac80211 cfg80211

And then tell compat-wireless to just compile ath5k:

 root@bt:~/compat-wireless-3.3-1# scripts/driver-select ath5k

Now we'll download the default set of patches for BT5R2 and apply them (you may get some errors when applying, you should be able to ignore them):

 root@bt:~/compat-wireless-3.3-1# wget http://www.backtrack-linux.org/2.6.39.patches.tar
 root@bt:~/compat-wireless-3.3-1# tar -xf 2.6.39.patches.tar
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/mac80211-2.6.29-fix-tx-ctl-no-ack-retry-count.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/mac80211.compat08082009.wl_frag+ack_v1.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/zd1211rw-2.6.28.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/ipw2200-inject.2.6.36.patch

Then lets apply the 4.9ghz patch:

 root@bt:~/compat-wireless-3.3-1# wget https://raw.github.com/OpenSecurityResearch/public-safety/master/4.9ghz/compat-wireless-3.3-1_ath5k-49GHZ+BWMODE.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < compat-wireless-3.3-1_ath5k-49GHZ+BWMODE.patch

Ok! now we're ready to build:

 root@bt:~/compat-wireless-3.3-1# make
 root@bt:~/compat-wireless-3.3-1# make install
 root@bt:~/compat-wireless-3.3-1# cd ..

After this, we're more or less finished. The thing is that you'll probably want to also upgrade your kismet to find these networks. It's highly recommended that you use the latest version of kismet from the git repo.

Updating Kismet

If you followed the easy way above, then you should be already updated. If you're following the manual way, uninstall the installed version of kismet:

 root@bt:~# dpkg -r kismet

Then grab the latest development version of kismet and compile it:

 root@bt:~# git clone https://www.kismetwireless.net/kismet.git
 root@bt:~# cd kismet
 root@bt:~/kismet# ./configure
 root@bt:~/kismet# make dep
 root@bt:~/kismet# make
 root@bt:~/kismet# make install

You'll also need to define a new channel list in your kismet.conf to support this. I've added the following. I chose to use .5MHz channel spacing since many 4.9GHz deployments have varying channel layouts.

 channellist=ps5mhz:4920-4990-5-.5
 channellist=ps10mhz:4920-4990-10-.5
 channellist=ps20mhz:4920-4990-20-.5

Finally, to change to a different channel width (other than 20MHz) you'll need to define the "default_bwmode" module parameter. For 5MHz channels, define "default_bwmode=1", for 10MHz, "default_bwmode=2", and for 40MHz, "default_bwmode=3". Also, for whatever reason, if you're using a channel width other than 20MHz, you'll also need to manually create a monitor mode VAP (e.g. "mon0") and use that as your source for kismet. Here's how to set it up:

 root@bt:~# modprobe ath5k default_bwmode=2
 root@bt:~# iw dev wlan1 interface add mon0 type monitor
 root@bt:~# ifconfig mon0 up
 root@bt:~# iwconfig mon0 freq 4.920G

Is it Working?

Once everything is running, kismet should look normal, just with the previously undiscovered AP available! Note that this band is highly regulated in the US, so you won't see these networks everywhere. And since the transmit distance is so small, you'll likely need to be in near line of sight of the 4.9GHz network you're looking at. Here's a screen shot of kismet discovering our test AP (located in a faraday cage, in a country where it is legal to transmit on 4.9GHz, of course):

Want to learn more?

This article is a precursor to the talk Robert Portvliet and I will be giving this year at Defcon 20. So if this sparks your interest, stop by - we'll be talking about 4.9GHz and the other Public Safety Bands!

Fente:http://blog.opensecurityresearch.com

Hacking KeyLoggers

By Mike Spohn and Brad Antoniewicz.

Our forensics investigations often result in us having to identify odd devices left over by attackers. So when we recently had to investigate a suspicious USB device connected between the keyboard and USB port on the rear chassis of a senior executive’s desktop computer, my job (I chose to accept it) was to discover what the device was and if it was evil.

Identifying the Device

The device was a very non-descript in appearance. It measured exactly 1” in length from the rear edge to the beginning of the male connector. The edges were beveled and the universal USB symbol was imprinted on the top and bottom. There were evenly spaced vertical striations on the sides. Here's an image of a keylogger from a competitor's site that resembled the device we were investigating.

Being the suspicious sort I am, this device and I did not become instant friends. A colleague scoured the Internet and notified me he found a very similar device manufactured by a company who specializes in hardware keystroke loggers. Since the device was relatively cheap (< $80), I ordered one for experimentation in the forensic lab. I'm intentionally not disclosing the actual manufacturer of the device so that they won't figure out a way to protect themselves against our attacks described below.

When the keylog device arrived, I visually compared it with the suspicious device provided by the client. They appeared identical. I next used an ohmmeter to measure the electrical properties of each device. Measuring the resistance between the front and rear USB pins determined both devices had the exact same electrical properties. The ohmmeter also indicated the devices had resistive/capacitive (RC) characteristics due the obvious RC time constant resistance behavior. At this point, I knew the device was not passive – it has an electronic brain.

The Unlock Code

Reading the documentation for the keylog device I learned it had a simple, elegant design. When the device is plugged into a computer and the O/S interrogates the device via Plug-N-Play (PNP), the device does not respond. Instead, the device goes into keyboard capture mode and logs every keystroke to a simple text file. All keystrokes are then passed on to the computer.

To retrieve a keystroke log from the keylog device, the owner must enter a three-key combination of keystrokes. The three keys must be alpha-numeric and must be pressed at the same time. For example, if the unlock key combination is ‘ABC,’ the owner must press the ‘A’ ‘B’ abd ‘C’ keys at the same time. Case does not matter. The unlock code can be changed from the default by placing a config.ini file on the device with a “Password=” entry.

Once the correct unlock key combination is entered, the device will send a PNP signal to the O/S. The device will advertise itself as a removable disk device, and the O/S will mount it. Once mounted, the owner can retrieve the keystroke log.

I attempted to unlock the clients’ device using the ‘default’ unlock code and it did not mount. If this was, in fact, a keylog device, the owner changed the unlock code. My challenge now was - how do I unlock the device?

The solution seemed obvious. Figure out a way to emulate a USB keyboard and send all combinations of three-key codes to the device until the right combination is sent. Simple – right? Not so fast Sherlock. Remember, you have to send the unlock code to the rear (keyboard) side of the device, not from the host computer.

USB Keyboard Emulation

The first thing that came to mind was a Teensy. This device, about the size of a postage stamp, provides a complete development environment for emulating a USB device and USB keyboard emulation. Even better, the device costs $16 US.

Once I had a Teensy 2.0 in the lab, I wrote a quick test program in C and transferred it to the device. After some experimentation, I had a complete program that would send all three-key alpha-numeric key combinations out the mini-usb port of the Teensy device. To crack the keylog unlock code I had to perform three steps:

1. Burn my key-crack application on the Teensy device
2. Connect the keylog device to a computer
3. Connect the Teensy device to the rear connector of the keylog device

Using The Teensy 2.0 To Brute Force The Unlock Key

You'll have to configure your system if you've never used the Teensy before. Our test system will be using Backtrack 5 R3. Windows was used originally, but once Windows 7 couldn't find the driver for my USB keyboard I jumped over to Linux. In the end the OS doesn't make much of a difference because once you identify the unlock code, it automatically mounts itself as a storage device accessible by all modern operating systems.

First up, we'll need to install our prerequisites:

 root@bt:~# apt-get install gcc-avr binutils-avr avr-libc

You can flash the Teensy a variety of ways, here we'll do it using the Teensy Loader CLI utility:

 root@bt:~# wget http://www.pjrc.com/teensy/teensy_loader_cli.2.0.tar.gz
 root@bt:~# tar -zxvf teensy_loader_cli.2.0.tar.gz
 root@bt:~# wget http://www.pjrc.com/teensy/hid_listen_1.01.zip
 root@bt:~# unzip hid_listen_1.01.zip

The Makefile included in the repository will perform the flash, which we'll go over in a couple of steps. For now, it's just important that the loader is on your system and decompressed. Next will grab a copy of the repository:

 root@bt:~# git clone https://github.com/OpenSecurityResearch/usb-keylog-crack.git
 root@bt:~# cd usb-keylog-crack

Edit the Makefile and set TEENSY_LOADER_CLI with the path to the teensy_loader_cli binary. By default it's set to ../teensy_loader_cli/teensy_loader_cli:

 root@bt:~/usb-keylog-crack# grep "TEENSY_LOADER_CLI " Makefile
# Be sure to set TEENSY_LOADER_CLI variable below
TEENSY_LOADER_CLI = ../teensy_loader_cli/teensy_loader_cli

With the appropriate values set, you can build the cracker:

 root@bt:~/usb-keylog-crack# make all

To flash, insert the Teensy and press the "Reset" button, this will put it into it's HalfKay bootloader. Now we can flash the usb-keylog-crack code:

  root@bt:~/usb-keylog-crack# make program
../teensy_loader_cli/teensy_loader_cli -mmcu=atmega32u4         -v usb_keylog_crack.hex
Teensy Loader, Command Line, Version 2.0
Read "usb_keylog_crack.hex": 5008 bytes, 15.5% usage
Found HalfKay Bootloader
Programming........................................
Booting
root@bt:~/usb-keylog-crack#

usb-keylog-crack uses the Teensy's USB debugging functionality to provide information during the cracking. We'll use the hid_listen utility to grab this debugging info:

 root@bt:~/usb-keylog-crack# cd ~/ 
 root@bt:~# wget http://www.pjrc.com/teensy/hid_listen_1.01.zip
 root@bt:~# unzip hid_listen_1.01.zip
 root@bt:~# cd hid_listen
 root@bt:~/hid_listen# make
 root@bt:~/hid_listen# ./hid_listen
Waiting for device:...

Now we're ready - Insert the Teensy 2.0 into the Keylogger, then insert the Keylogger into the computer. Sit back and relax, after a few minutes you should see the banner and brute force attempts:

 root@bt:~/hid_listen# ./hid_listen
Waiting for device:...
Listening:
Keylog crack application
Written by Michael G. Spohn
June 3, 2012
0001) Trying: QWQ (0014 001A 0014)
0002) Trying: QWE (0014 001A 0008)
0003) Trying: QWR (0014 001A 0015)
0004) Trying: QWT (0014 001A 0017)
0005) Trying: QWY (0014 001A 001C)
0006) Trying: QWU (0014 001A 0018)
0007) Trying: QWI (0014 001A 000C)
0008) Trying: QWO (0014 001A 0012)
0009) Trying: QWP (0014 001A 0013)
000A) Trying: QWA (0014 001A 0004)
000B) Trying: QWS (0014 001A 0016)
000C) Trying: QWD (0014 001A 0007)
000D) Trying: QWF (0014 001A 0009)
000E) Trying: QWG (0014 001A 000A)
000F) Trying: QWH (0014 001A 000B)
0010) Trying: QWJ (0014 001A 000D)
0011) Trying: QWK (0014 001A 000E)
0012) Trying: QWL (0014 001A 000F)
0013) Trying: QWZ (0014 001A 001D)
0014) Trying: QWX (0014 001A 001B)

I threw everything together in a quick video:

Attacking the Attacker

I tested my key-crack rig against the R&D device. It worked - but it was inconsistent. Occasionally, the test keylog device would mount after successfully guessing the unlock keycode, but the keystroke log file was gone. In fact, it appeared the device had been wiped.

More experimentation determined there was an ‘undocumented’ feature of the device. A specific three-key unlock code had been assigned by the manufacturer as a ‘reset’ code. This is used in the event someone forgets their unlock keycode. Whenever my Teensy sent this combination down the wire – the keylog device was wiped. I modified my key-crack app to bypass the unlock code. After some more thorough testing, I was confident my Teensy would unlock the clients’ keylog device.

It took less than 30 seconds. The clients’ keylog device mounted and I was able to retrieve the keystroke log file and the config.ini file. Since the keystroke log has no concept of time, the client had to review the file content and correlate how much sensitive data might be somewhere it does not belong. Needless to say, providing this keystroke log file to the client was a truly valuable service.

Final Thoughts

These types of engagements always remind me of the importance of the physical security component of any security program. The keystroke log bandit who placed the device on the clients’ computer had to have physical access to it.

You read a lot these days about businesses and governments trying to re-invent themselves by focusing on innovation and ingenuity. This also applies to the digital security incident response universe. Innovation and adaptation to the constantly changing environment during a hot incident is essential. To all my fellow white-hats out there – never ever give up the good fight. If we do, we all lose.

Hack the planet.

Fuente:http://blog.opensecurityresearch.com