BSides London 2013: Blinking Hell – Extracting data using Keyboard Lock States

So hopefully if you’re reading this you’ve seen mine and Matt Phillips (@phillips321) talk about Blinking Hell in the Rookie Stream at BSides London 2013.

Photo of @Phillips321 and @Scriptmonkey_ presenting Blinking Hell, courtesy of @Andrew_Barratt

What follows is a more in-depth blog post I hope that contains some of the timeline and reasoning around some of the things we did and why we did them.

For those of you who are fresh to this and don’t know what Blinking Hell is, it’s a sysadmin/security dude’s worst nightmare. It’s someone bypassing all your host based protections and extracting your crown jewels without leaving too visible a trace.

What is Blinking Hell?

Blinking Hell makes use of a small arduino like programmable USB device. The Teensy, created by Paul J Stoffregen as a small programmable USB device it seems to be able to emulate any USB device under the sun and is used in various projects including converting real flight controls into computer flight simulator input, repairing dance pads or maybe you’ve heard or used one with the Social Engineering Toolkit, courtesy of the research and work put in by IronGeek and David Kennedy. It allowed a new way of wrapping payloads onto a device that could type extremely fast.

People soon turned their teensy’s into FTP/HTTP/Etc network clients of awesome, plugging in and exporting data left right and centre. Fantastic! But, what if you don’t have internet access?

What if the system you’re trying to get data off of is not allowed to browse the internet willy nilly? What if you didn’t need the internet?

Okay, but then i’d just use a USB Drive like normal…

Nope, not in this case. In this case they’ve prevented write access to USB drives using host based endpoint protection mechanisms. Heck in some cases you can’t even get the USB device to be recognised as plugged in thanks to things like Lumension Endpoint Security (aka Sanctuary) for example.

Drat… you say, YAY! I say.

Challenge accepted.

How do you do it?

So the basic premise.

1. Write some code that does something that magically transports data off of the disk.

2. Get the teensy to inject code, or supply the code via other means (other employee internally emailing it?, bring it through import/export procedures).

3. Now you’ve injected the code, run it.

4. Knowing where the crown jewels are stored

5. Saving it to disk

6. Exfiltration of data.

So, How do you get data off of a system, you can’t get data from?

This boils down to what ways can the teensy see data?

My colleague way back in 2010, managed to get to go on a nice trip to Defcon and saw a lovely talk by the aforementioned David Kennedy, he was also perfectly placed to grab a free teensy when he threw a few out to the crowd at the end of his speech.

My colleague managed to also have a quick chat during which he asked if the teensy could be used for output in the keyboard configuration and David said something along the lines of “I don’t see how it could, its just a keyboard”.

My colleague is a determined person and left thinking “there must be a way”. A few weeks/months of research and he stumbled upon a bit of documentation regarding PS2 keyboards and their control lines. This documentation noted that the “lock state” LEDs were “broadcast” signals that would be seen by any PS2 devices plugged into the host. Does the same hold true for USB?

Well in his blog post back in August 2011, he revealed it: http://www.phillips321.co.uk/2011/08/25/teensy-keyboardlockkeys/

Back then I was just a lowly software coding monkey on another project, in the same company but not within the penetration testing field, however as of September 1st 2011 I got accepted into the penetration testing team and started getting to know the team. This is when Matt revealed his research project above to me. Having done a bit of hacky development work I thought I could contribute and so volunteered my services. I didn’t get much done until one night in October 2011.

Eureka!

I had spent all evening working on it, until finally at 10 past midnight on the 25th of October 2011 I published a video to my facebook pages confusing my friends except the few that understood what I had achieved.

I had gone from Text file -> Bytes -> Binary Bit Stream -> Signalled using keyboard Lockstates -> Saved internally on the Teensy’s SD Card (or eeprom depending on the implementation I used).

If I knew how to export it elsewhere and host it somewhere I would. It was rough but it was ready and it worked.

Then I left it…. Me and Matt talked about dedicating some time to polishing it but conferences came and went and we were both too nervous to stand in front of an audience and do a long talk about it. Then came September 2012.

B Sides London 2013 Call for papers and introducing a new Rookie Track, 15 minute talks in front of a small audience with an experienced mentor to guide you. It seemed perfect. We wrote up a small abstract in a canteen over lunch and submitted our talk.

Disaster!… (almost)

November 2012 we had notification we had been accepted and then came a bombshell in the form of a “WTF?!?” message over facebook from Matt. He sent me a link to hack-a-day.

http://hackaday.com/2012/10/30/extracting-data-with-keyboard-emulation/

Someone had “published”.

But they had a flaw, they used custom executable code. That just won’t fly on our systems I don’t want to have to run an executable. I want it to work across locked down systems that use whitelists for these things so we used macros. Something I’m pretty familiar with having been working on a local lockdown project for a fair while now. You can find some of the things I’ve done with macros over at: http://blog.scriptmonkey.eu/nftf-local-lockdown-getting-prompts-fun-with/

Long story short, We still had our talk! 🙂 *phew!*

So now without further waffling, we get to the important stuff.

Rough edit of our presentation video with slides: BSides London 2013 Rookie Track Presentation – Blinking Hell

The code to get this working on your own teensy can be found here: https://www.assembla.com/code/blinking-hell/git/nodes

My colleague has uploaded the in-talk video at: https://www.youtube.com/watch?v=N8nyt4ugTnE

I’ve uploaded an earlier video that we made with older code, but it shows more of the debugging output and juicy techie stuff: http://www.youtube.com/watch?v=a_O0eBFShaY

Apologies for the poor attempt at narrating it but figured I’d best explain some aspects of it.

Whenever we get the whole presentation video we plan on sharing that too! See above for the presentation video 😉

I hope you enjoyed our talk and I can hand on heart say it was enjoyable to do and hearing the feedback in the breakout room afterwards some of the suggestions made were interesting, watch this space you may see some of those interesting developments soon(ish).

Notes from a lockdown: Episode 1

So I’ve done a few posts in the past about getting command prompts from GPO’d workstations and running what’s known as “mobile code” in locked down environments (VBA, VBS, BAT, Bash, Python, Perl, etc…).

I figured I’d try and make a series of shorter posts maybe detailing some of the things I’ve discovered while working on my current long term engagement (involves lots of local lockdown playtime).

Lesson 1: Just because you can’t run reg edit doesn’t mean you can’t edit reg

The following methods can all be used to edit registry keys, create full trees down to a value or otherwise modify the registry.

VBS – Difficulty: Easy

function writeReg(regPath,value,regType)

'reg_sz = String, reg_dword = integer, reg_binary = binary or boolean

'reg_expand_sz = expandable string (like a path of %systemroot%), reg_sz = string

Dim objReg, keySet

objReg = CreateObject("WScript.Shell")

key = objReg.regWrite(regPath,Value,RegType)

writeReg = key

End Function

'Now to call the function above.

disposablevar = writeReg("HKCU/scriptmonkey/regwriting/1","Success!","REG_SZ")

VBA – Difficulty: Easy (depending on lockdown of office suite, see: Getting Prompts & Fun with macros for details of circumventing that)

'This all relies upon a small function available within word called privateprofilestring.

Sub regReaderEditor

'To Write

System.PrivateProfileString("", _   "HKEY_CURRENT_USER/scriptmonkey/regwriting","2") = "Success!!"

'To Read

disposableVar = System.PrivateProfileString("","HKEY_CURRENT_USER/scriptmonkey/regwriting","2")

msgbox disposableVar

End Sub

VBS with WMI – Difficulty: Could end up in a moment of WTF?

The reason for the difficulty increase?

The way that WMI handles registry writing by calling different functions for different types of registry key that you wish to write, It also involves scary hexadecimal numbers to refer to the various hives. I can barely count to 10, let alone F.

The script snippet that follows is available in better syntax highlighting glory along with a bunch of other interesting WMI scripts over on the MSDN documentation pages, so go and check them out when you have time, but this is one i’ve used in the past with success.

Const HKEY_LOCAL_MACHINE = &H80000002

strKeyPath = "scriptmonkey/regediting/"

strComputer = "."

Set objReg=GetObject( "winmgmts:{impersonationLevel=impersonate}!" & _ strComputer & "rootdefault:StdRegProv")

strValueName = "3"

strValue = "Success!!!"

objReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

Script.Echo "Example String_Value at " _& "HKEY_LOCAL_MACHINE/scriptmonkey/regediting"

Finally a gem from my colleague over at http://www.pentestdave.com (go and say hi)

Always remember, even though you may be acl’d out of HKLM. HKCU is typically always editable by the current user.

I’ll leave it up to the reader to discover what that means for now, but I am working on a tool that’ll make use of that fact quite a bit.

Have a tip to share? give me a shout in the comments or if you want a more private chat head over to my twitter @scriptmonkey_ and give me a nudge over there.

blog.scriptmonkey.eu

So after a bit of a drinking session with some lads I’m working with and lots of teasing of a fellow tester attempting to get him to buy a (rather cool in my opinion) domain name, i’ve just gone and got this blog its own proper home on the web.

No longer using my personal domain from yonks ago, it now is officially:

http://blog.scriptmonkey.eu

So there you go! Update your bookmarks (all 1 of you :)). I’ll try and get a cname redirect set up on the old address for the time being but yeah this blog finally has a proper home on the web.

For those who didn’t know I maintain a twitter feed @scriptmonkey_ its nothing fantastic and I rarely post anything up there that isn’t here but its another way to get hold of me if you have any questions about my blog content.

Look out for more frequent postings too, have a few research projects in the pipeline that are about to all come to fruition providing I can get enough time to get a move on.

P.S. I use 123-reg for my registrar and they appear to have an awesome deal on for .eu domains right now (hence my purchase). 1 year for 99 pence. Might be worth checking out if you’re interested in having your own “identity” on the web.

NFTF: Bypassing Group Policy Denied Command Prompt

This is an old trick but I ended up doing it the other day just for kicks, it will only work on 32bit systems at the moment (edit.exe is a 16bit editor and won’t run on a 64bit OS).

 

Just to clarify – I had no internet access or access to any toolsets, so had to go with whatever I could find on the box hence the use of edit.exe and not winhex/hxd/hexeditorofyourchoice.

 

I think I vaguely recall a way to use debug.exe to edit binary files but it involved raw assembler and was more complicated than I could remember off of the top of my head with zero internet access at the time so this will do for now.

 

Right, so as before we have access to a basic command prompt using the VBS/VBA “Call FTP and ! prefix your commands” method.

 

But I want a full prompt that works without needing such a workaround.

 

Copy C:windowssystem32cmd.exe somewhere (unless you want to possibly break cmd.exe on your test system).

 

Using the VBS/VBA FTP method, call “Edit” (Don’t try this with notepad it will change all of the nulls to x20 and destroy the file such that you can no longer run it as an executable)

 

File -> Tick the “Open Binary” box (This is important), Navigate to C:windowssystem32cmd.exe and open the file.

Edit_binary

 

Scroll down (I’ve tried searching and as there is no way of typing a null char, it won’t work) and you’re looking for the first references to “SoftwarePolicies…” Its the registry key that it is looking at to determine if it should allow you to run or not.

Edit_policies

Change P O L I C I E S to B O L I C I E S (well whatever you want, keep the length the same though)

 

Save the file – Run the file – Voila! command prompt with no need to have to go through FTP.exe over and over. 

NFTF: Local Lockdown – Getting prompts, Fun with Macros and Scripting Help on Airgapped Systems

Using VBS to fire up FTP as a local command shell

This is probably a duplicate somehwere but I wanted it noted for my own use anyway – here’s a very handy VBS that does the job nicely for accessing useful commands as a user on a locked down desktop.

In this example I choose to fire up FTP.exe as its well known that local commands can be run within the FTP.exe interface.

'run ftp

CreateObject("WScript.Shell").Run "cmd.exe /k ftp"

Using the above and the bang character, this will allow you to run commands on the host. For example: !cd or !c:\windows\system32\calc.exe

Odd Behaviour: On XP64 !cd did not appear to persist the path post it’s single command, however on windows 7 and 32bit XP it did so. Pretty noddy stuff but useful to remember.

No Macros Allowed?

Myself and a colleague were presented with a “Defect Fixed, macros are completely disabled on the host” statement from a long term pentest engagement, I was new to the project so decided to give it a good kicking.

At first glance, no access to the editor was possible and only trusted signed macros were capable of running. We could be forgiven at this point for even mistakenly “passing” the defect if we hadn’t been so determined.

After a bit of poking and managing to pop open the editor across the office suite, I was convinced I could get it to play ball all the way. My colleague thankfully indulged my inane ramblings about digitally signing and feeling like it’s so close to popping.

3 to 4 hours later and a fair few dead ends, we got macro editing and execution as a trusted signed macro across all the office apps available on the host (aside from outlook, that could probably fall too given more poking but we had proved our point).

What follows is a quick run through of what we did:

First problem, Creating the macro – we need an editor

If the macro menu is disabled and the buttons on the developer toolbar are greyed out (or even removed from the interface) try the following.

In Word: Right click the toolbar, select “customise quick access toolbar”, select “all commands” and add the buttons labelled “view code” and “design mode”. The view code button will be greyed out until the design mode button is pressed so press the design mode button, hit view code and voila the VB Editor pops open!

In Excel: Right click the sheet tab and select view code – it is also accessible through the same way it was in Word.

In Powerpoint: There should already be a view code option on the ribbon. Failing that activate it as you would in Word above.

Just sign here, here and here

Our second issue, accessing the security window and then the macro security window using the above toolbar button method (anything with the word macro in was disabled from a UI point of view in the ribbon menus, so you had to load the plain “security” window in order to get the macro security screen to pop). We could see that only signed macros were allowed to run. Nightmare, what can we do now?

Well, coming at this from a lockdown breakout just don’t save the document. Group Policy only applies in terms of macro execution to a saved word document. Writing a macro and executing it instantly is usually not blocked.

However this is a long term pentest engagement and sometimes the ability to save documents and have say your VBA port scanner or VBA based file downloading widget saved for later use on other engagements is a useful thing. We used to just copy paste from text files but that’s frustrating and doesn’t allow you to really go to down with forms and things to prettify your attack “docs” 🙂

So we need to sign our macros. While poking about the office program files folders I noted the following executable: selfcert.exe

Run it, and it’ll produce a lovely new certificate for you to sign your macros with, now granted it’s self signed but word doesn’t really care too much about that.

Tools -> Digital Signatures -> Choose Certificate -> Select your cert. Now it’s signed. You may need to reopen the document to get it to run.

This is all fantastic until…

But wait, mommy told me not to run macros from strangers…

Okay so we’ve got our macro signed, but due to the security settings they’ve hobbled it further and disabled any prompting for self-signed macros, allowing only trusted macros to run. So we need to find a way to explicitly trust our self-signed macro.

Open the VB Editor as before, Then… Tools -> Digital Signatures -> Choose -> View Certificate -> Details -> Copy To File

Navigate to the saved .cer file (just accept the defaults in the export wizard). Right click the file and select “install certificate”, select the location to install the certificate as “Trusted Publishers”

With the certificate installed successfully you just added your certificate to the trusted signatures that microsoft office will blindly accept without needing you to click on an “accept the risk” style dialog box.

Before: In our case this dialog was hidden and not shown to users, meaning we had no option of accepting anyway in this manner, so self-signed macros would never run.

After: No prompt, macro runs and certificate is trusted

So what can I do with these things anyway?

So the little example given at the top of this blog post will fail without the use of cscript/wscript.exe. Which is commonly locked down.

How about doing it in VBA?

Sub run_me    retVal = Shell("c:\windows\system32\cmd.exe /k ftp",1)End Sub

A quick F5 and you’re back running the commands you love.

retVal in the above will contain the PID of the process you just launched so the following will kill the process too.

Sub run_me_kill_me    Dim retVal as String    retVal = Shell("c:\windows\system32\calc.exe",1)    killCmd = "c:\windows\system32\cmd.exe /k taskkill /PID " + retVal    retVal2 = Shell(killCmd,1)End Sub

The ,1 part of the shell call, that’s describing what you want VB to do with the window. If you are doing calls to a script or a command/console based program, you can use vbHide instead and no window will appear on the screen.

Be careful doing this however on systems with cmd.exe disabled by group policy as you’ll find that they never show up and so persist within task manager waiting on an invisible but very real “This command has been disabled by your administrator, press any key to continue” prompt.

Help! No Web, No Hope? No Way!

So a final tidbit on the end of this blog post. Ever wanted to write some VBS or VBA but not sure of the exact syntax or even the functions you may have access to, you’re in a location with zero access to the internet and someone has helpfully disabled the “help and support” service, denying you any F1 action you may be looking for?

This is a little trick I picked up from previous work. Providing the host you’re playing with has Microsoft Office installed you will have access to all the scripting reference material you could want.

First lets make a new shortcut on the desktop or wherever is convenient for you.

Set the path to

"C:\program files (x86)\Microsoft office\office12\clview.exe" "MSE" "Microsoft Scripting Engine"

Double click your newly created shortcut and a blank help screen should appear.

Use the search bar to searfch for something “VBS” related for example and then click the “Microsoft scripting engine” (grey text top left) and then “Microsoft Scripting Engine Help”. You’ll have access to the help for VBScript and JScript language references along with information on all the juicy runtime objects you can access using them.

Need VBA help? Once again CLVIEW to the rescue…

Create a shortcut only this time it’s contents will be:

"C:\program files (x86)\Microsoft office\office12\clview.exe" "WINWORD" "Microsoft Office Word"

This looks like you’re calling for word help but in reality it is the word developer reference manual and in turn will give you the full VBA language reference too.

There are options too for Excel and Powerpoint references in case the word based help is not sufficient for your needs.

Happy local lockdown testing!