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
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:~# 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.
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.
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.
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:
Burn my key-crack application on the Teensy device
Connect the keylog device to a computer
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:
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:
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.
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.
#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.
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
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:
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)
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
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!
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.
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:
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):
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.
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
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):
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]"
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!
