The Adventures of Packet Tracy, PI – The Case of the Disappearing Delicacy

Welcome to my latest challenge, part of the run-up to BSides London 2013. It’s a bit different this time, both in terms of what you have to do and what you get if you do it. The prizes on offer are tickets to the event, with a special prize of a ticket to Hack In Paris for the best entry! Full rules and T’s&C’s are at the end of this post.

Are you sitting comfortably? Then let’s begin…

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Tuesday my door was locked because I was out for lunch. Some people only take an hour for lunch, but I do my best work at lunchtime so I take the whole day. As usual I headed for Fat Dex’s Diner on the West Side. Gotta be careful not to confuse it with the oil refinery; the place is covered in a film of grease, and Fat Dex ain’t called Fat Dex for nothing.

I slid in through the front door, tripping over tumbleweeds left and right. I had my choice of tables – the last time this joint was full Kennedy was on the throne and Fat Dex was just called Dex. Even so, lately there are so many tumbleweeds I worry they’re planning some kind of global uprising. Better stock up on weedkiller.

Wendy comes over with something she claims is coffee, but I suspect it’s actually come from the refinery. I ask her for my usual zeppelins in a fog, but when she brings them over it looks like they’ve come from Lakehurst field instead of the kitchen. Oh the humanity.

I can hear Dex crashing about out back. Clearly something is rotten in the state of Dexmark, which is usually my cue to leave before Dex and the Knuckleduster Twins politely ask me to pay my tab. In between tripping over tumbleweeds and slipping on grease he manages to get the jump on me and we sit down for a gentlemanly discussion. He looks stressed and he’s sweating. More than usual. Which is a lot.

Dex says takings are down and the Fatelli brothers are on his back and unless he turns things around soon they’ll be breaking it. He says it’s not his fault, but it never is. According to Dex only San Andreas has faults.

This time he might be right. Some new joint called Iggy’s Eats has opened up on the East Side, and Dex can’t compete. He says they’ve got more money than he has grease, and they’ve got a brand new three-storey R&D facility that’s kicking out some kind of seafood dish that people come from miles around to hook. If that wasn’t bad enough he says they’ve stolen his secret recipe for cheese on toast. 

Before I can tell him that particular recipe ain’t so secret, he says he’s got proof that’ll send Iggy and her Eats down the river to Sing Sing quicker than you can play a song song. Wendy’s culinary talents are below par because she’s tired – she’s been on a nocturnal special op on behalf of Dex. She got close to Iggy’s top guy Jamie and was able to go through his drawers once she was done going through his drawers. She came back with a USB stick with Dex’s stolen cheese on toast recipe on it, enough proof to get Iggy a private room in the State’s finest long-term accommodation facility. But there’s a problem that’s stickier than Dex’s tables – the recipe’s encrypted. According to Wendy the password is in a safe in Iggy’s private office, and not even a team of invisible ninjas is getting in there.

So that’s what Dex is after – he needs me to decrypt the stick and get the proof that Iggy has stolen his recipe. It was a tough case, but you don’t call a PI for the easy ones…

For all you budding PIs out there, the question we need answered is very simple. The crime of corporate espionage has been committed, but who stole the recipe and who will end up in the dock? Iggy? Jamie? Someone else? You’ll need to conduct a thorough investigation and write up your evidence so PT can take it all to the Judge. When you’re done, you can submit it via email here.

Before we give you the USB stick, please take a moment to read the rules:

1. You cannot enter if you are a volunteer for this event or a member of the BSidesLondon crew
   
2. You must submit your answer by April 1st 2013 18:00 (6pm) GMT
3. The first three people to submit the correct answer showing all the steps taken to determine the guilty party will get a ticket to BSidesLondon13
4. After the closing deadline the best answer will get a ticket for Hack In Paris 2013, a ticket to BSidesLondon13 (if required) plus a further winner of BSidesLondon13 tickets will be selected from all those who have submitted a correct and complete answer. These winners will be decided on criteria including the thoroughness and completeness of the presented investigation, and/or the use of an appropriate narrative style
5. Judge’s decision is final and prizes can’t be exchanged for cash or favours
6. This challenge will involve you interacting with live systems via the Internet. If the system’s name doesn’t end in wirewatcher.net, you’re in the wrong place and you should stop.
7. The only tool you need to dish up the dirt is your brain – step away from the BackTrack laptop and use GreyMatter 1.0 instead. Any forceful attempts to “hack” the challenge systems may result in it being taken offline prematurely, which would be a shame. All necessary information is provided for you – all you need to do is find it!
8. For data protection purposes, names and email addresses of participants will only be used for the challenge, and will be shared with the challenge creator only for the purpose of selecting the best answers. You have Packet Tracy’s cast-iron no-spam guarantee!
9. All characters, organisations and other such entities featured in the challenge are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
10. Play nice and have fun, and please don’t share any answers with anyone!

Ready? You can download the USB stick image here.

If you need any hints, you can try asking PT himself, but he’s pretty tight-lipped, especially in public!

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

Virtual Private Onions

If you’ve not checked out Security Onion (SO) yet, you really should. It’s a powerhouse Linux distro, running everything an analyst could need to carry out effective Network Security Monitoring (NSM). The latest beta is looking fantastic; watch the video and try it out, you won’t be sorry!

I’m not going to talk about SO itself (Mother Google has plenty of good things to say); instead I’m going to look at the underlying network infrastructure.

A major component of SO is Sguil, a distributed monitoring system that has sensor and server components that are used for monitoring the network and aggregating output from multiple sensors (you can see a Sguil schematic here to understand how it all fits together). The comms between the sensors and the server are protected by SSL, and SO builds on this with autossh tunnels to protect other traffic streams from interception. Ubuntu’s Uncomplicated Firewall (UFW) opens only the necessary ports to allow SO sensors to talk to their server, so all the installations are protected to a high degree.

If all of the connections between the sensors and the server are on your own infrastructure, this is fine (perhaps you have a management VLAN specifically for this purpose, for example). There is however another use case I can think of, where we like to use a slightly different method of sensor-to-server communications.

NSM As A Service?

Let’s say you’re in the business of selling NSM to clients, either short-term (“help me understand what’s on my network”) or long-term (“please be our NSM operators in return for huge bushels of cash”). This will probably involve dropping off SO sensor boxes on customer networks and having them all report in to an SO server back at base. The SO sensors will probably be behind the customer’s NAT and firewalls, but this doesn’t matter, the comms will still work. The network of sensors will look a bit like this:

This particular use case isn’t without issue, though – here is where I think that a slightly different approach to the underlying SO infrastructure has value. Consider the following:

• The Sguil interface shows you that one of the agents on one of the sensors is down. How do you ssh in to fix it if the sensor is behind someone else’s NAT and firewalls? How do you even know which Internet IP address you should use to try?
• You suspect one of the sensors is under excessive load. It’d be great to install an snmp agent on the sensor and point Munin at it to try and find the stressed metric. Again, how do we contact the sensor from back at base?
• You want to implement a custom information flow from the sensor back to the server. You need to think about the security of the new flow – can you implement another autossh tunnel? What if the flow is UDP (e.g., snmp-trap)?
• One of the sensors is reported lost or stolen. How can you easily stop it from connecting back to base when it’s possibly now in the hands of threat actor du jour?

One possible answer is to build a custom “underlay” network to carry all of the traffic between SO sensors and the server, catering for existing flows and anything else you think of in the future. As a side benefit, the sensors will all have static and known IP addresses, and contacting them from the server will be no problem at all.

Virtual Private Onions

We’ll accomplish this by using OpenVPN to create a secure, privately- and statically-addressed cloud that the sensors and server will use to talk to each other (sorry for using the word “cloud”!). Take our starting point above, showing our distributed sensors at client sites behind client firewalls. By “underlaying” the SO comms with an OpenVPN cloud we’ll end up with is something like this:

The client’s firewalls and NAT are still there, but they’re now hidden by the static, bi-directional comms layer provided by OpenVPN. The sensors all talk over the VPN to the server at 10.0.0.1; the server in turn is free to contact any of the sensors via their static addresses in the 10.0.0.0/24 subnet.

Details

I don’t intend for this to be a HOWTO; I want to wait until people tell me that what I’m proposing isn’t a galactic waste of time and completely unnecessary! Conceptually, it works like this:

The SO Server takes on the additional role of an OpenVPN server. Using OpenVPN’s “easy-rsa” feature, the Server also becomes a Certificate Authority capable of issuing certificates to itself and to the sensors.

OpenVPN gives the SO Server a routed tun0 interface with the IP address 10.0.0.1/24 (note routed - if we wanted to, we can give other subnets back at base that are “behind” the Server access to the SO Sensors via the VPN).

The Sensors become OpenVPN clients, using certificates from the Server to mutually authenticate themselves to it. The Sensors know to point their OpenVPN clients at the static Internet-facing IP address of the server back at base, getting a tun0 interface and a static IP address out of 10.0.0.0/24 in return.

When setting up the SO components on the Sensor boxes, the sosetup script is told that the server is at 10.0.0.1 via tun0, ensuring that all SO comms go over the VPN.

The VPN carries all traffic between Sensors and Server, be it Sguil’s SSL connections, autossh tunnels, SNMP traps or queries, raw syslog forwarding, psychic lottery predictions, anything. The Server is also free to ssh onto the Sensors via their static VPN addresses.

Advantages?

We’ve implemented OpenVPN with SO in this manner, and it works well for us. I hope this approach has some advantages:

• It makes for easier firewalling at the Server and Sensor ends. You only need to open up one port, which is by default 1194/UDP. All of the VPN traffic is carried over this port.
• You have deterministic sensor IP addressing, something you wouldn’t otherwise have had when your sensors were deployed on foreign networks behind NAT, firewalls, and dynamic IP addresses on customer DSL routers.
• You don’t need to worry about setting up additional autossh tunnels when you dream up a new flow of information  between Sensor and Server.
• You can easily talk to the sensors from the server, for ssh sessions, SNMP polls, or anything else.
• If a sensor is lost or stolen, all you need to do is revoke its certificate at the Server end and it won’t be able to connect to the VPN (more on sensor security in a moment).

There are of course some disadvantages:

• Complexity, which as we all know is the enemy of security.
• Double encryption. OpenVPN is encrypting stuff, including stuff already encrypted by Sguil and autossh.
• <insert other glaring flaws here>

Security considerations

On the Server side, keep in mind that it is now a Certificate Authority capable of signing certificates that grant access to your SO VPN. Guard the CA key material well – maybe even use a separate system for certificate signing and key generation. Also, once you’ve generated and deployed certificates and private keys for your sensors, remove the private keys from the Server – these belong on each specific sensor and nowhere else.

On the Sensor side, we have a duty of care towards the clients purchasing the “NSM As A Service”. OpenVPN should be configured to prohibit comms between Sensor nodes, so that a compromise of one Sensor machine doesn’t automatically give the attacker a path onto other customer networks.

If a Sensor machine is lost or stolen whilst deployed at a customer site, we can of course revoke its certificate to prevent it from connecting to the VPN. That’s great, but the /nsm directory on it is still going to contain a whole bunch of data that the client wouldn’t want turning up on eBay along with the stolen sensor.

I have a plan for this, but I’ve not implemented it yet (comments welcome!). The plan is to have the /nsm directory encrypted (a TrueCrypt volume? something else?), but to have the decryption key stored on the SO Server rather than on the Sensor. When the Sensor starts up, it builds its OpenVPN connection to the Server before the SO services start. Using the VPN, the Sensor retrieves the decryption key (one unique key per Sensor) from the Server (wget? curl? something else?), taking care never to store it on the Sensor’s local disk. Decryption key in hand, the Sensor can decrypt /nsm and allow the SO services to kick off.

In this way, a stolen Sensor box represents minimal risk to the client as the /nsm directory is encrypted, with the keymat necessary for decryption stored on the Server. Provided that the theft is communicated to the NSMAAS provider in an expedient fashion, that keymat will be out of reach of the thief once the OpenVPN certificate is revoked.

(Other, crazier, plans involve giving the Sensors GPS receivers and 3G comms for covert phone-home-in-an-emergency situations…)

So there you have it…

…Virtual Private Onions. Any comments?

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

Accepting the Inevitability of Compromise, Spandau Ballet style

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

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

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

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

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?

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