Accepting the Inevitability of Compromise, Spandau Ballet style

Posted in Silly on 14 August, 2012 by Alec Waters

It’s common knowledge that prevention eventually fails. To help spread the Good News to those who haven’t heard it, I present a musical aide memoire on the inevitability of compromise. Get the music playing and sing along!

Thank you for coming in
I’m sorry but the data’s all gone
I left it here I could have sworn
Safe in my database
Slowly being taken away
Just another hack for today
Off to the cloud it blew, to the cloud it blew
Guess I wasn’t quite on the ball
Luck has left me taking the fall

Pwned!
Always believe in your soul
You’ve got the power to know
You are destructible
Always believe in, ’cause you are
Pwned!
Malware is bound to return
There’s something I could have learned
You are destructible, always believe in

After the data’s gone
The ICO delivers his fine
Even though we’re victims of crime
It’s only two years ago
The kid with the spots on his face
The one who set up our database
Now he’s let blackhats through, he’s let blackhats through
Penetrated our firewall
And right under the table I crawl

Pwned!
Always believe in your soul
You’ve got the power to know
You are destructible
Always believe in, ’cause you are
Pwned!
Malware is bound to return
There’s something I could have learned
You are destructible, always believe in…


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Adventures of Packet Tracy, PI

Posted in NSM, Packet Tracy, Sguil on 14 May, 2012 by Alec Waters

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Monday morning began like every other with a fumble through the fog of a hangover looking for new and unexplained bruising. The pounding in my head was aided and abetted by the pounding on my door, and aspirin couldn’t fix both. I dragged myself towards the noise and let in a dame wearing stilletos and a scowl that could shatter concrete at fifty paces. She said her rat of a boyfriend had been flirting with some internet floozy, and all the proof was in the pcap on the USB stick that left another bruise after bouncing off my head. No problem, I said, come back Friday for chapter and verse.

The case was tougher than I thought; the pcap was bigger than my last bar tab and there’s no way I want to go over that line by line either. So I ran it past my Bro and a couple buddies of mine, Suri and Carter, but none of us could come up with the dirt. The dame’s been on my back all week for results, and now it’s Sunday and the pounding is back with a vengeance. She’s at the door, calling me names I’m pretty sure my mother never gave me. I considered leaving by the window until I remembered my office is in a basement and there aren’t any.

Time’s up. Gotta face the music… 

So how come PT couldn’t come up with the goods? The evidence was there, surely it was just a matter of time before he found it?

I’m sure a good many of us have been in needle-in-a-haystack situations where we’ve had to rely on some tool or other to process a gigantic pcap. If the tool doesn’t find what we’re looking for, either it’s not there to find or the analyst or tool itself wasn’t up to the job.

So are all tools created equal? Given the same pcap and the same task, will they return the same results?

I thought I’d run a number of URL extraction tools against a standard 128MB pcap, the kind you might find on a Security Onion box, and I set up a quick deathmatch cage fight between httpry, urlsnarf, Suricata, tshark and Bro. All versions are the ones shipped with SO, and the config files haven’t been tweaked in any way from standard.

I realise that this is hardly a thorough and scholarly test, but I think that the results show a point worth making.

The tools were invoked like this:

user@sensor:~/httpexperiment$ httpry -o httpry.log -r capture.pcap
httpry version 0.1.6 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2011 Jason Bittel <jason.bittel@gmail.com>
Writing output to file: httpry.log
5230 http packets parsed

user@sensor:~/httpexperiment$ urlsnarf -n -p capture.pcap > urlsnarf.log
urlsnarf: using capture.pcap [tcp port 80 or port 8080 or port 3128]

user@sensor:~/httpexperiment$ suricata -c /etc/nsm/sensor-bond0/suricata.yaml -r capture.pcap
<tons of output>
4/4/2012 -- 15:35:58 - <Info> - HTTP logger logged 2206 requests

user@sensor:~/httpexperiment$ tshark -r capture.pcap -R http.request -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e http.request.method -e http.host -e http.request.uri -e http.request.version > tshark.log

user@sensor:~/httpexperiment$ bro -r capture.pcap

Now, we need to process httpry’s output a little, since it includes server responses as well as client requests. Once done, we can see how many HTTP requests were seen by each tool. The results were a little surprising to begin with:

httpry: 2567 requests seen
tshark: 2557 requests seen
Bro: 2240 requests seen
Suricata: 2206 requests seen
urlsnarf: 2198 requests seen

httpry and urlsnarf are often (probably quite rightly) viewed as less sophisticated than Suricata and Bro, and tshark might not be the tool of choice for this kind of work, especially when you’re constantly monitoring traffic on an interface rather than processing a pcap. Bro and Suricata certainly picked up things that httpry didn’t (HTTP on non-standard ports, for example), but there’s quite a gulf between the apparently less-sophisticated and the cutting-edge.

So why? Each tool does the job in a different way, and with its own set of pros and cons. httpry, for example, only listens on ports 80 and 8080 by default, has no support for VLAN-tagged frames, and performs no TCP session reassembly so it is vulnerable to evasion. On the other hand, the more sophisticated Bro and Suricata have, to my knowledge, no such shortcomings.

However, it’s httpry’s brute simplicity that I suspect put it on top of the pile for this particular test. All it looks for is one of a nominated set of HTTP method verbs at the beginning of a TCP segment. It doesn’t care about proper TCP session establishment or teardown, all it’s looking for are a few bytes in the proper place. In contrast, other tools may not log any URLs at all if the TCP session isn’t complete and well-formed.

Each tool’s results were a subset of the others’ collective results – no one tool captured the superset, and one could probably achieve “better” (or at very least, “different”) results by tweaking each tool. Even then I reckon there would still be a pretty good chance that there are undiscovered URLs lying there that a different tool could pick up.

I don’t mean for this to be seen as some kind of ranking of tools, or a statement that httpry and tshark are “better” URL extractors than Bro and Suricata; all I’m trying to say is that you’re almost certain to miss something by only using a single tool for a job like this. On the flip side of course, running two or more URL extractors might seem like a galactic waste of resources…

Your mileage will almost certainly vary, but it’s worth keeping this in mind when the dame is at the door demanding answers!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Hacker Countermeasures, 1984 style

Posted in General Security, Retro on 30 April, 2012 by Alec Waters

Some number of years ago, I was lucky enough to get a Sinclair ZX-81 for Christmas. There was much wonderment and joy to be had amid the frustration of RAM-pack wobble, the agonising waits for software to load from tape, and the never-ending search for a replacement keyboard that wasn’t as bad (or worse) than the original.

The best thing about the computers of olde was the built-in interpreter, usually for BASIC – here was an item of consumer electronics that wouldn’t do a single thing unless you told it to, an unthinkable concept to the marketeers of today. Putting in a tape and typing LOAD “” was the easy way out of this predicament; however, the real solution to the inert nature of your newly purchased box of future was to open the manual and learn how to code.

So learn we did. One day, my father proudly showed me a program he’d written – a version of the card game “snap”, with graphics and everything. After whiling away a good part of the afternoon playing, I looked over the source code. Showing an early leaning towards white-box pentesting, it didn’t take long to find a simple flaw. By simply keeping your finger pressed on your “snap” key (regardless of the two cards on the top of the deck) you could beat even the quickest opponent when a true “snap” finally came around. If both players were aware of this exploit (or “expliot” as I’d almost certainly have spelled it at the time) you had to make sure that you were player 2 since the subroutine that checked which key was pressed during a “snap” condition checked for player 2’s “snap” key before player 1’s.

Easily exploitable vulnerabilities? Some things never change, huh? In terms of Incident Detection, prime Indicators of Compromise included my little sister complaining to our parents that Daddy’s game was no fun because Alec always won.

To restore the game back to a test of speedy reactions my father rolled out some countermeasures in the form of a patch. The next time we played, my tactic resulted in the computer labelling me a cheat and docking me five cards every time I pressed my snap key when it wasn’t snap. To further add injury to insult, the losing player was crushed by a one-ton weight falling from the ceiling. I’m sure you can imagine what a terrifying visual experience this must have been, especially if you remember the graphics capabilities of the ZX-81…

To sample the full glory of this dance of measure and countermeasure, here’s the actual source code as submitted to ZX Computing magazine nearly thirty years ago. Lines 570 and 580 show the horrifying corpses of the losing players, squashed flat by Newtonian Justice From Above. Enjoy 🙂

Newtonian Justice from Above

Lines 570 and 580, Newtonian Justice from Above


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Quick Book Review – The Alexandria Project, by Andrew Updegrove

Posted in General Security on 19 April, 2012 by Alec Waters

THANK YOU FOR YOUR CONTRIBUTION TO THE ALEXANDRIA PROJECT

In a slight departure from my usual reading material of John le Carré and non-fiction technical tomes, I recently read The Alexandria Project by Andrew Updegrove; it turned out to be a nice mix of the two.

Without wishing to spill too many beans, it’s a fun read featuring mystery attackers with mystery motives, three-letter-agencies butting heads whilst manipulating people down their chosen path, military coups and crazy politicians with their finger on the Big Red Button.

The plot is spookily close to reality, especially in the Big Red Button department – I was reading the story on the actual dates featured in the book, at which time events were playing out on the world stage much as they were in my Kindle (plot spoiler, courtesy of BBC News, here). Coincidence? Or does Mr Updegrove have a crystal ball?

For the grand total of £1.95, you can’t really go wrong. Swing by Amazon and pick up a copy!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

whois smarter than I thought?

Posted in Information Leaks, IPv6 on 5 March, 2012 by Alec Waters

Whilst picking through the responses to the latest Spy Hunter challenge I stumbled over some interesting behaviour when using whois to query various kinds of IPv6 addresses, especially those related to v6-over-v4 tunnelling mechanisms. It turns out it’s rather insightful.

As a baseline, let’s start by performing a whois of a non-tunnelled IPv6 address – it’s pretty straightforward, as you would expect:

user@box:~$ whois 2001:200:dff:fff1:216:3eff:feb1:44d7
% [whois.apnic.net node-5]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inet6num: 2001:200::/32
netname: WIDE-JP-19990813
descr: WIDE project
country: JP
remarks: upgraded from /35
admin-c: JM46-AP
tech-c: AK27-AP
tech-c: SU19-AP
status: ALLOCATED PORTABLE
notify: kato@wide.ad.jp
notify: zin@wide.ad.jp
mnt-by: APNIC-HM
mnt-lower: MAINT-JP-WIDE
changed: hm-changed@apnic.net 20030423
changed: hm-changed@apnic.net 20071109
source: APNIC

person: Jun Murai
address: Keio University
address: 5322 Endo Fujisawa 252-8520
country: JP
phone: +81 466 49 1100
fax-no: +81 466 49 1101
e-mail: junsec@wide.ad.jp
nic-hdl: JM46-AP
mnt-by: MAINT-AU-APNIC-GM85-AP
changed: kato@wide.ad.jp 19990729
source: APNIC

person: Akira Kato
address: Keio University, Graduate School of Media Design
address: 4-1-1 Hiyoshi, Kohoku, Yokoahama 223-8526
country: JP
phone: +81 45 564 2490
fax-no: +81 45 564 2503
e-mail: kato@wide.ad.jp
nic-hdl: AK27-AP
mnt-by: MAINT-JP-WIDE
changed: kato@wide.ad.jp 20090225
source: APNIC

person: Satoshi UDA
nic-hdl: SU19-AP
e-mail: zin@jaist.ac.jp
address: Japan Advanced Institute of Science and Technology
address: Center for Information Science
address: 1-1 Asahidai, Tatsunokuchi, Nomi, Ishikawa 923-1292
phone: +81 761 51 1111
fax-no: +81 761 51 1305
country: JP
notify: zin@jaist.ac.jp
changed: zin@jaist.ac.jp 20040803
changed: zin@jaist.ac.jp 20041028
mnt-by: MAINT-JP-WIDE
mnt-by: MAINT-JP-JAIST
source: APNIC

In this case, there is a direct link between the IPv6 address and it’s “owner”, provided you trust what the whois server is telling you.

With tunnelled IPv6 addresses, there isn’t such a strong correlation between an observed IPv6 address and the actual IPv4 computer sourcing that traffic. Depending on the type, the IPv6 address may be “owned” by the tunnel provider, and one might be tempted to think that a whois query of such an address would merely tell you about the provider.

It turns out that whois is a bit smarter than that. Various flavours of IPv6-over-IPv4 tunnelling embed the original IPv4 address into the IPv6 address, and whois can parse it out for you. Taking a Teredo IPv6 address as an example, look at line 03 below:

user@box:~$ whois 2001:0:5ef5:79fb:3447:18d4:b0b5:1c05

Querying for the IPv4 endpoint 79.74.227.250 of a Teredo IPv6 address.

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '79.72.0.0 - 79.79.255.255'

inetnum: 79.72.0.0 - 79.79.255.255
netname: DSL-AS9105-UK
descr: Tiscali UK Ltd
descr: Milton Keynes
descr: Dynamic DSL
descr: ==========================================================
descr: Concerning abuse and spam ... Email abuse@talktalkplc.com
descr: e-mail to other addresses will not be dealt with.
descr: ==========================================================
country: GB
admin-c: TU935-RIPE
tech-c: TU935-RIPE
status: ASSIGNED PA
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered

role: Tiscali UK
address: Tiscali UK Limited
address: 11 Evesham Street
address: London W11 4AJ
phone: +44 207 087 2000
remarks: Information: http://www.talktalk.co.uk
org: ORG-TUL3-RIPE
admin-c: MJ3048-RIPE
admin-c: RH2381-RIPE
tech-c: MJ3048-RIPE
nic-hdl: TU935-RIPE
remarks: Hostmaster Role Account
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered
abuse-mailbox: abuse@talktalkplc.com

% Information related to '79.64.0.0/12AS9105'

route: 79.64.0.0/12
descr: Tiscali UK Limited
origin: AS9105
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered

Line 3 shows that whois has recognised a Teredo IPv6 address, and has parsed out the client’s obfuscated IPv4 address from bits 96-127 and run the whois on that instead. If we want to know the tunnel provider, we have to extract it ourselves – it’s unobfuscated in bits 32-63. In this example, this is 5ef579fb which translates as 94.245.121.251. A standard whois query tells us that the person connecting with Teredo from 79.74.227.250 on Tiscali’s network is doing so via Microsoft – they are therefore likely using Vista or Win7:

user@box:~$ whois 94.245.121.251
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '94.245.64.0 - 94.245.127.255'

inetnum: 94.245.64.0 - 94.245.127.255
descr: Microsoft Limited
org: ORG-MA42-RIPE
netname: UK-MICROSOFT-20081107
country: GB
admin-c: AS9763-RIPE
tech-c: EN603-RIPE
tech-c: BR329-ARIN
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: MICROSOFT-MAINT
mnt-domains: MICROSOFT-MAINT
mnt-routes: MICROSOFT-MAINT
source: RIPE # Filtered

organisation: ORG-MA42-RIPE
org-name: Microsoft Limited
org-type: LIR
address: Microsoft
 Darren Norman
 One Microsoft Way
 WA 98052 Redmond
 UNITED STATES
phone: +1 (425) 703 6647
fax-no: +1 425 936 7329
e-mail: danorm@microsoft.com
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
mnt-ref: MICROSOFT-MAINT
mnt-ref: RIPE-NCC-HM-MNT
mnt-by: RIPE-NCC-HM-MNT
source: RIPE # Filtered

person: Allie Settlemyre
address: Microsoft Limited
address: One Microsoft Way,
address: Redmond, WA 98052
address: USA
phone: +1 (425) 705 0516
phone: +1 (425) 936 7329
e-mail: iprrms@microsoft.com
nic-hdl: AS9763-RIPE
source: RIPE # Filtered

person: Bharat Ranjan
address: Microsoft Corporation
address: Redmond, WA, 98102
address: One Microsoft Way
address: USA
phone: +1 (425) 706 3230
fax-no: +1 (425) 936 7329
nic-hdl: BR329-ARIN
source: RIPE # Filtered
e-mail: bharatr@microsoft.com

person: Edet Nkposong
address: Microsoft, One Microsoft Way,Redmond, WA 98052
address: USA
e-mail: edetn@microsoft.com
phone: +14257071045
nic-hdl: EN603-RIPE
mnt-by: MICROSOFT-MAINT
source: RIPE # Filtered

Pretty neat. You can pull off a similar trick for 6to4 addresses as well:

user@box:~$ whois 2002:4b95:26ad:0:d067:8ff6:b954:b37f

Querying for the IPv4 endpoint 75.149.38.173 of a 6to4 IPv6 address.

#
# Query terms are ambiguous. The query is assumed to be:
# "n 75.149.38.173"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=75.149.38.173?showDetails=true&showARIN=false&ext=netref2
#

Comcast Business Communications, LLC CBC-CM-5 (NET-75-144-0-0-1) 75.144.0.0 - 75.151.255.255
Comcast Business Communications, LLC CBC-SFBA-11 (NET-75-149-32-0-1) 75.149.32.0 - 75.149.63.255
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

There’s one last use case I’d like to illustrate – that of a static IPv6 tunnel via a tunnel broker. This is where you manually connect a 6in4 tunnel (using IP Protocol 41) to a tunnel broker service, such as that run by Hurricane Electric. The tunnel broker is your point of access to the IPv6 internet, and the next-hop for your ::/0 default route is the broker’s end of the tunnel.

When signing up for a tunnel like this, you might have to supply some information about yourself to the tunnel broker as required by the Terms of Service. Take care – this information may end up in the output of a whois query.

In the query below, I’ve obfuscated the actual IPv6 address and other items to protect the privacy of the individual concerned. Some interesting points:

  • Line 17 tells us that the IPv6 address is owned by Hurricane Electric
  • Line 74 is where we start to find the interesting stuff. This is talking about 2001:470:XXXX:XXXX::/64, the static IPv6 address block assigned to the user of the tunnel broker.
  • Lines 91 and 92 tell us that we’re looking at the address of the user’s private residence
  • Line 95 is the postcode you’d put into Google Streetview to start your cyberstalking.
user@box:~$ whois 2001:470:XXXX:XXXX::2
#
# Query terms are ambiguous. The query is assumed to be:
# "n 2001:470:XXXX:XXXX::2"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=2001:470:XXXX:XXXX::2?showDetails=true&showARIN=false&ext=netref2
#

NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2001:470::/32
OriginAS:
NetName: HURRICANE-IPV6
NetHandle: NET6-2001-470-1
Parent: NET6-2001-400-0
NetType: Direct Allocation
RegDate: 2001-03-22
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET6-2001-470-1
OrgName: Hurricane Electric, Inc.
OrgId: HURC
Address: 760 Mission Court
City: Fremont
StateProv: CA
PostalCode: 94539
Country: US
RegDate:
Updated: 2011-04-13
Ref: http://whois.arin.net/rest/org/HURC

ReferralServer: rwhois://rwhois.he.net:4321

OrgTechHandle: ZH17-ARIN
OrgTechName: Hurricane Electric
OrgTechPhone: +1-510-580-4100
OrgTechEmail: hostmaster@he.net
OrgTechRef: http://whois.arin.net/rest/poc/ZH17-ARIN

OrgAbuseHandle: ABUSE1036-ARIN
OrgAbuseName: Abuse Department
OrgAbusePhone: +1-510-580-4100
OrgAbuseEmail: abuse@he.net
OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN

RNOCHandle: ZH17-ARIN
RNOCName: Hurricane Electric
RNOCPhone: +1-510-580-4100
RNOCEmail: hostmaster@he.net
RNOCRef: http://whois.arin.net/rest/poc/ZH17-ARIN

RAbuseHandle: ABUSE1036-ARIN
RAbuseName: Abuse Department
RAbusePhone: +1-510-580-4100
RAbuseEmail: abuse@he.net
RAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN

RTechHandle: ZH17-ARIN
RTechName: Hurricane Electric
RTechPhone: +1-510-580-4100
RTechEmail: hostmaster@he.net
RTechRef: http://whois.arin.net/rest/poc/ZH17-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Found a referral to rwhois.he.net:4321.

%rwhois V-1.5:0012b7:01 ops.he.net (HE-RWHOISd v:r255,m1:r290)
network:ID;I:NET-2001:470:XXXX:XXXX::/64
network:Auth-Area:nets
network:Class-Name:network
network:Network-Name;I:NET-2001:470:XXXX:XXXX::/64
network:Parent;I:NET-2001:470::/32
network:IP-Network:2001:470:XXXX:XXXX::/64
network:Org-Contact;I:POC-TB-6NGV
network:Tech-Contact;I:POC-HE-NOC
network:Abuse-Contact;I:POC-HE-ABUSE
network:NOC-Contact;I:POC-HE-NOC
network:Created:20120217063259000
network:Updated:20120217063259000

contact:ID;I:POC-TB-6NGV
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Private Customer - Hurricane Electric
contact:Street-Address:Private Residence
contact:City:SOMECITY
contact:Province:SOMECOUNTY
contact:Postal-Code:POSTCODE-PLUG-INTO-GOOGLE-STREETVIEW
contact:Country-Code:UK
contact:Phone:+1-510-580-4100
contact:E-mail:hostmaster@he.net
contact:Created:20120217063225000
contact:Updated:20120217063225000

contact:ID;I:POC-HE-NOC
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Network Operations Center
contact:Company:Hurricane Electric
contact:Street-Address:760 Mission Ct
contact:City:Fremont
contact:Province:CA
contact:Postal-Code:94539
contact:Country-Code:US
contact:Phone:+1-510-580-4100
contact:E-Mail:noc@he.net
contact:Created:20100901200738000
contact:Updated:20100901200738000

contact:ID;I:POC-HE-ABUSE
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Abuse Department
contact:Company:Hurricane Electric
contact:Street-Address:760 Mission Ct
contact:City:Fremont
contact:Province:CA
contact:Postal-Code:94539
contact:Country-Code:US
contact:Phone:+1-510-580-4100
contact:E-Mail:abuse@he.net
contact:Created:20100901200738000
contact:Updated:20100901200738000
contact:Comment:For email abuse (spam) only

%ok

The moral of the story is that you can’t hide behind a tunnelled IPv6 address, and it may well tell the world much more about yourself than you might think!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Spy Hunter, Part III – Solution

Posted in Packet Challenge, Spy Hunter on 14 February, 2012 by Alec Waters

Part III was a different kind of challenge. For the first time, players were on the offensive, acting as Agents rather than reacting as Investigators. Out of over 220 downloads of the mission brief, only a single Yellow Sun agent managed to complete the challenge – hats off to Marcelo Mandolesi, Agent Of The Month! Marcelo’s excellent writeup is below, but first, a quick word from me:


Sponsor Alec! I hope you have fun with these challenges; I certainly have fun creating them! I’m running the 2012 Brighton Half Marathon on Sunday 19th of February in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

Now, over to Marcelo:

Discover how to access the GMTA website

Open up the OperationCHASTISE.pcap file with Wireshark and follow the TCP stream of the IRC packets. There we find the following URL.


This leads to: https://gmta.nybblecomms.42 which means we need to add the .42 top-level domain DNS servers to be able to browse to it. The DNS servers can easily be found here: http://wiki.42registry.org/page/Resolve. Run a nslookup gmta.nybblecomms.42 and we see that the IP address is 2001:6f8:608:7:221:5aff:feab:5144.


My ISP is not IPv6 friendly so that left me with making a Teredo tunnel. After some configuration I verified that I was able to browse IPv6 websites and could access the NybbleComms website. This shows the Teredo tunnel successfully working.


The trick was to change the type from “client” to “enterpriseclient” and adding a static route for all ipv6 traffic to use the Teredo interface with the following respective commands:

netsh interface Teredo set state enterpriseclient
netsh interface ipv6 add rouate ::/0 interface=10

(the interface number is listed at the beginning of the route print command’s output)

Take a look at the bottom of the website and we find that the GMTA’s public key is available for download here: https://gmta.nybblecomms.42/GMTA-CA.pem.

Discover the date and time of NybbleComms’ next test missile firing

Going back to the IRC conversation, we find that the time and dates of the missile firings are publicly known. Their support is kind enough to give us the notice.
The notice is written in the “Notices to Airmen” format. After some patient Googling, you can translate the message to say:

  • QWMLW = missile, gun or rocket firing will take place
  • Within a 40 nautical mile radius of the coordinates 52.132237 North 0.973028 East
  • EGUW = Wattisham Airfield (a military airport in Wattisham UK)
  • On February 18th 2012 from 10:00 AM to 10:30 AM UTC/GMT. This means that the launch time is at 10:00AM but the notice announcement lasts until 10:30.

Recover enough cryptographic material to allow the signing of a fake, but valid, MTP

Time to take a look at another TCP stream in the pcap file. Starting at packet number 220, we see some encrypted SSH traffic. I wonder what’s happening in IRC right when this starts. Go to packet number 217 and we find the dev support guy saying “Let me transfer that private key for you”.


It seems that this is our chance to get a copy of the GMTA’s private key which will allow us to sign the public key retrieved from the website. The dialog in IRC tells us that the dev support guy keeps a copy of the private key on his Ubuntu Gutsy and gives us a clue that this is very vulnerable. Doing some searches for SSH vulnerabilities around 2007-2008 leads us to this: http://www.debian.org/security/2008/dsa-1571 which states:

Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

Doing some more searches leads us to these set of tools: https://www.cr0.org/progs/sshfun/ designed to take advantage of this vulnerability. First you have to export only the SSH packets from Wireshark and use the tool tcpick to split the traffic into server and client streams. Running the ssh_decoder.rb file on these two files lets us see the normally encrypted SSH traffic.

The data that is relevant for us is stored in the sshdecrypt.1.client.dat file because the client transferred the key to the server. Note that the Ruby script required the –c switch which means that the client is vulnerable, not the server. By running strings on the .dat file we have the private key as well as his username and password.

Discover the location of the BATCAVE

The briefing document gives a clue that the re-examining the social media profiles of SIBHOD operatives may be useful. It appears that Ultra Venona has tweeted this link: http://j.mp/xzxmfW which leads to a SQL 2008 Express database. Take a look inside and we find a database called placesDB with the following information.


The location of the BATCAVE is stored in this database in SQL’s geography data type. We can use the STAsText method to convert the binary data to readable form.

The coordinates of the BATCAVE are 52.106428 North 1.58205 East. It appears to be an underground bunker on the East coast of England. Notice that this bears resemblance to the SIBHOD logo.


Assembling the MTP certificate

First we have to setup our openssl environment. Note I will skip a lot of the detail in configuring the openssl configuration file. Copy an existing openssl.cnf from the web and edit it to use the GMTA’s public and private keys.

Certificate = GMTA-CA.pem
private_key = GMTA-CA.key.pem

Configure the NotBefore and NotAfter times of the certificate by adding the following two lines to the [ CA_default ] section of openssl.cnf. Since the launch is at 10:00 AM I chose 09:56AM and 10:04AM as my start and end dates.

default_startdate = 120218095600Z
default_enddate = 120218100400Z

Add the following information to the [ req_distinguished_name ] section of openssl.cnf. The OU field should equal “WARHEAD-FAE” because thermobaric explosives are effective against underground bunkers. The CN field should equal “52.106428×1.58205” for the coordinates of the BATCAVE. The rest of the fields do not matter but I made them match the GMTA’s public key.

[ req_distinguished_name ]
0.organizationName = NybbleComms
organizationalUnitName = WARHEAD-FAE
localityName = Guildford
stateOrProvinceName = Surrey
countryName = GB
commonName = 52.106428×1.58205

The following section will configure the X509v3 extensions which will make the Authority Key Identifier equal the GMTA’s cert.

[ usr_cert ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer

Run this command to create a certificate request:

openssl req -new -nodes -out req.pem -config openssl.cnf

Run this command to create the certificate and sign it:

openssl ca -out MTP.pem -config openssl.cnf -infiles req.pem

Convert the pem file to der format:

openssl x509 -in MTP.pem -outform der -out MTP.der

View the contents of the certificate:

openssl x509 –in MTP.der –inform –text -noout

The Authority Key Identifier matches and all the other required fields look good too.

Upload the MTP to the Guided Missile Targeting Authority

The GMTA website requires a Userid and Password field as well as the MTP certificate.

Packet number 395 in the pcap file contains MySQL traffic with a username and password of “launchmaster” and “one2ThreeBOOM”.


Supply the certificate and these credentials and we verify that it has accepted our forged certificate.



Nice shot, Marcelo! The question now is, will NybbleComms notice the unauthorised MTP in time to revoke it? Or will Yellow Sun finally be rid of their two greatest threats? Stay tuned for Part IV!

Bootnotes

The abbreviation-laden NOTAM retrieved from the IRC chat reveals the location of NybbleComm’s launch site, correctly identified by Marcelo as RAF Wattisham. Taking a closer look at the site reveals the missile sitting on its pad:

The layout of the pads is that of a Bloodhound surface-to-air missile installation; you can read all about this specific one here.

As for the location of the BATCAVE, it’s actually the site of an experimental over the horizon radar system codenamed Cobra Mist; the BATCAVE itself is at the focal point of the antenna array. The radar itself was a failure, despite a nine-figure price tag.

Finally, the real Operation CHASTISE was this one, which I imagine a lot of people are familiar with.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The Spy Hunter, Part III

Posted in Packet Challenge, Spy Hunter on 24 January, 2012 by Alec Waters

From the mission brief:

Operation CHASTISE – Strategic Aims
Subvert NybbleComms’ next missile test, replacing the inert test warhead with a live one and targeting the BATCAVE. The net effect will be the physical destruction of SIBHOD, and the discrediting of arch-rival NybbleComms as a business competitor for allowing a test firing to go so badly wrong… 

Yellow Sun Heavy Industries have been playing catchup ever since Donald Burgess was recruited by the Sinister Icy Black Hand Of Death. Now, at last, a chance has arisen to strike decisively and put an end to Yellow Sun’s two biggest threats. Do you have the skills to carry out the mission successfully? Click here to find out!

PS…

Sponsor Alec! I hope you have fun with these challenges; I certainly have fun creating them. If you were wondering how you could possibly say “thankyou”, I’m running the 2012 Brighton Half Marathon in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Man-In-The-Middle-ing You

Posted in Silly on 22 December, 2011 by Alec Waters

Down at the local wi-fi equipped coffee shop, I couldn’t help but notice the chap in the corner singing merrily to himself as he tapped away at his laptop. Not sure what he was up to, but this was what he sang…

Well I know just why I came here tonight,
Drinking coffee while I’m stealing your bytes,
Sniffing passwords as they fly through the air,
And your privacy, it don’t have a prayer,
Bob to the left of me,
Alice to the right, here I am,
Man in the middle-ing you.

Yes I’m thinking ’bout which tool I should use,
Maybe Mallory or Karma for you,
It’s so hard to keep this smile from my face,
Taking control, yeah, I’m all over the place,
Banks to the left of me,
Email to the right, here I am,
Man in the middle-ing you.

Well I started out with nothing,
And ID theft is my secret plan,
Your credentials all come crawlin,
Wanting to be used they say,
Please… Please…

Trying to make some use of it all,
Finding pics for “you” to post on your Wall,
Maybe sending some embarrassing Tweets,
Social media was never so sweet!
Twitter to the left of me,
Facebook to the right, here I am,
Man in the middle-ing you.

Well I started out with nothing,
And ID theft is my secret plan,
Your credentials all come crawlin,
Wanting to be used they say,
Please… Please…

Well I know just why I came here tonight,
Drinking coffee while I’m stealing your bytes,
Sniffing passwords as they fly through the air,
And your privacy, it don’t have a prayer,
Bob to the left of me,
Alice to the right, here I am,
Man in the middle-ing you,
Yes I’m man in the middle-ing  you,
Man in the middle-ing you.


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Using Maltego CaseFile to map The Spy Hunter

Posted in Spy Hunter on 2 December, 2011 by Alec Waters

In any investigation, keeping track of evidence is crucial to success. When it comes to crime scene photos, bios of suspects, pictures of exhibits, etc, you might like to follow the lead of TV cops and pin it all to a board in the squad room:

Doctor Reid and his gigantic sliding tile puzzle

Or you might like to use one of those new-fangled computer thingies instead. Paterva (of Maltego fame) have recently released a beta of their latest effort, CaseFile:

CaseFile is aimed at analysts that do not necessarily use open sources of intelligence (or even the Internet for that matter). Think of it as Maltego without transforms but with tons of new features. Adding/attaching photos, documents and annotations to nodes, graph merging, better integration with browsers, passwords on graphs, and tons of new useful entities – and this is just a few of the goodies we’ve added into CaseFile.

I thought I’d test it out by creating a graph of the players in my Spy Hunter packet challenges (Part One, Part Two). Here’s what I came up with:

The graph above shows SIBHOD on the right, and the target organisations on the left. SIBHOD’s infiltrations are either via its own agents (e.g. Kerry Nitpick using the alias Arnold Davies placed directly within NybbleComms) or via subverting employees (e.g. Donald Burgess). SIBHOD’s organisational structure is shown via the “Reports to” links; also shown are aliases and social network identities. The people are of different types – Dave Nice is a Gang Leader, Kerry Nitpick is a Gang Member, Donald Burgess is an Employee, etc.

Each element on the graph can have lots of information attached. For example, double clicking on the Silky Suzy “Alias” icon shows you this:

You can attach as many arbitrary files and notes as you like. I did try putting notes on the links (to document what an agent’s mission is, for example), but these don’t seem to get saved properly (bug in the beta?). Links to external sites are possible, too – double click Homer Hicks’ Twitter affiliation, and click “Open all URLs” in the top right to be taken directly to his Twitter feed:

It’s extremely cool. Download CaseFile from here (watch the video too), and the Spy Hunter graph from here, then have a play around!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

glTail parsers for Snort, net-entropy and viewssld

Posted in net-entropy, NSM on 28 October, 2011 by Alec Waters

glTail is a tool for realtime log visualisation, which according to the website allows you to “view real-time data and statistics from any logfile on any server with SSH, in an intuitive and entertaining way.”

glTail can read from any text logfile you like, and via a set of parsers can extract information such as IP addresses for graphical display. Each row from the logfile may trigger several blobs, e.g. source IP, dest IP, etc, as you can see in the video below:

I’ve written some parsers for Snort, net-entropy and viewssld. A screenshot of them all in action is shown below (click for full size view):

The red blobs are related to Snort, cyan ones to net-entropy, and the yellow shades are from viewssld. The numeric columns show the rate at which each item is appearing, and the length of the coloured highlight bars show the proportion of occurences of a given item relative to the others.

The parser files and a sample config.yaml file that uses them can be found here (snort.rb, net-entropy.rb, viewssld.rb and config.yaml).

Useful?

So, it’s a pretty visualisation of interesting stuff, but is it useful and actionable? It’s certainly hopeless for correlation – when a signature fires, it’s more or less impossible to tell the associated IP addresses and ports even if you have a very quiet sensor. At the other end of the scale, if you’re inundated with blobs you can alter the regexes in snort.rb to match on a specific IP/protocol/signature etc to be a little more selective.

Where I think this may prove most useful is when you’re learning from an incident. If you’ve investigated an incident where someone compromised your webserver, you could pull all the relevant log entries that show:

  • Snort alerts (when the attacker was probing for vulnerabilities)
  • Apache/IIS log entries (showing everything else they did to your server)
  • net-entropy logs (showing the attacker’s outbound backdoor SSH tunnel).

If you were to pump all of these logs through gltail you’d have an effective visualisation of the attack. For inspiration, check this out:


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk