Blinking hell - Data Extraction through Keyboard Lockstates
•Als PPT, PDF herunterladen•
0 gefällt mir•3,415 views
Using a small, cheap and freely available programmable usb device it is possible to export data from a computer system without being detected as a typical usb storage device. We have developed a PoC that is demonstrable, and our current research is now focused on defeating endpoint security solutions that track vendor and device ids of usb devices.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Blinking hell - Data Extraction through Keyboard Lockstates
- 1. Blinking Hell Big things in small packages Matthew Phillips @phillips321 Richard Hicks @scriptmonkey_
- 2. Background Bsides Las Vegas 2011 • David Kennedy (Rel1k) – “Using the Teensy for so much more...” 2
- 4. Research • Software can toggle the key lock states • Teensy can emulate a keyboard (CAPS,SCROLL,NUM) • Can we see the status of the lock keys from the teensy? 4
- 5. Solution • Hidden in Mouse • Once again Iron Geek deserves credit 5
- 6. Summary so far... • Keyboard lock states are broadcast signals • Teensy is capable of reading them • Easily hidden in benign objects 6 • Can we signal? • How do we control it? • How do we retrieve the data in a usable form?
- 7. How do we get the host to talk?… 7
- 8. How do we get the two to play nice? 1. Waiting for special “Knock” 3. Teensy now in “record” mode and waiting for first bit 7. Teensy now has control. 8. Read state of Num Lock 9. Unset Scroll Lock 10. Set Caps Lock 2. Turn Scroll on 3times within 5secs 4. Set Num Lock to identify first bit 5. Clear Caps Lock 6. Set Scroll 11. VBA Has Control, Repeat Steps 4 to 11 until EOF. 12. Send “FF” to signal EOF to teensy
- 9. Scenario 9
- 10. Demo Time Will the demo gods help us? Not going to try!
- 11. Wrap up • Works with other file types • Demo speed can be improved upon • Vendor ID can be changed • Others have now done this 11
- 12. Questions? • Matthew Phillips • @phillips321 • www.phillips321.co.uk • Richard Hicks • @scriptmonkey_ • blog.scriptmonkey.eu • Assembla code will be up soon (see twitter) 12
Hinweis der Redaktion
- Introduce Read Title and Subtitle Apologies for the branded slides – work for CGI and they’re paying
- Teensy – Small USB-based Microcontroller - ATMega chip – pjrc.com Dave’s Talk – Teensy type code faster than human Sat in a good position [SPACE] Can Teensy receive data? Dave unsure [SPACE]
- No USB Mass Storage No CD Burning No Internet No Cameras
- After BSides I did some research, this was back in 2011. PLUG IN 2 keyboards , 1 updates the other when press CAPS Software can change these CAPS states Yes the teensy can view the lock status of the keys [SPACE]
- Reconnaissance allows purchase identical mouse Attacker can hide the teensy inside the mouse Easy to Carry Unsuspicious! Attacker plants device on target machine cleaner route xmas pressie (secret santa!) Attacker sends in malicious macro document
- Summary so far So we've identified a set of keystrokes that may work. Proven the concept using the teensy to listen for changes in lock states And thanks to irongeek and his work, know the teensy can successfully be hidden in a "benign" USB device. What's left to solve? Given the teensy can listen, can we signal it programmatically? Can we control the data output correctly and finally can we devise a way of meaningfully reconstructing the data after its been sent in this manner? Updates Lock status to represent binary stream Teensy listens and records the lock status MicroSD stores the bit stream
- So onto solving problem 1 how do we solve the issue of getting the host to signal the data? It obviously requires some code so what language do we use? C++/C# - Compiled languages in general are a no-go for us, we’ve got execution arbiters, software restriction policies and all sorts of annoying things that prevent us from running our lovely code on the host. So what’s left? What about that old favourite, Java? Okay so it’s precompiled but a weakness of many execution arbiters is that java.exe is typically allowed to execute, meaning providing we can get our bytecode on the host we can run what we want. It’s also in wide spread use and is a likely find on our target “office administration” workstation. Fantastic but that’s only 2/3rds of the issue. JAVA as a language does not reliably (or at least within my testing) support modification and monitoring of the keyboard lock key states. It caused many hours of keyboard rage trying to understand why it would believe my caps lock was latched on when I turned it off 5 seconds ago. So that’s JAVA done with. Python? Or rather scripting languages in general, these either are: Not in widespread use amongst our target workstations. I.E. Python Easily blocked using execution arbiters or SRP. I.E. Cscript Easily controlled by group policy. I.E. Powershell. Or don’t even support the functionality we require in the first place (BATCH) So what are we left with? That’s right, good ol’ Microsoft office, or more specifically Visual Basic for Applications. It’s widely supported on pretty much every corporate machine you’ll find out there aside from servers, the use of macros while they can be locked down the protections surrounding them can be circumvented (I go into this in some depth on one of my blogposts, the url will be at the end of the talk) and they have the necessary keyboard access we require.
- So we’ve got hardware that’s listening to changes in lock states. We’ve got software that can change those lock states. How do we modify them to do something useful? Or rather, how do we control the sending of data so it comes out the other side in the right format? We use "flags" 2 control and 1 data. The initial state of the teensy is one that is "waiting". If we're using a cleaner to perform this attack we want to be able to wait before we start capturing data from errant keystrokes. The way we get around this is a special "knock" in this case we've chosen the toggling of scroll lock 3 times within a 5 second period. Once the teensy sees this it enters a listening state recording key strokes as signalled. Then data transfer happens before it hits EOF at which point the macro will send the binary representation of 0xFF to signal end of data. This means we will always know the start and end of our data export which solves the 3rd issue of reconstructing the data once extracted. Now onto a brief scenario description and demonstration.
- Controlled and locked down environment Attacker wants to steal data Sorry for Rich walking into shot on right!
- Place MicroSD in Attack box Show data file is empty Eject MicroSD Put MicroSD in Teensy MicroSD reader Send malicious document containing VBA via email Attach teensy to target - not enough time to embed in mouse - USB HID Keyboard and Mouse Victim turns on machine Victim Reads email and saves document Move document to My Docs (Notice No USB device is under My Computer) Open Document VBA auto runs and starts to export data (see flashing CAPS) - This has been sped up for demo purposes Victim leaves machine Attacker retrieves teensy from Victim machine Remove SD Card and insert to Attack Box Opens text file containing binary stream Looks for the 1’s that signal End Of File Convert binary stream to ascii Profit
- Works with other file types Demo speed can be improved upon, we have Sleep and waits throughout code Vendor ID can be changed to beat on host protection mechanisms Dec 2012 - András Jan 2013 - d3ad0ne FAST using HID protocol http://techblog.vsza.hu/posts/Leaking_data_using_DIY_USB_HID_device.html