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

Advertisements

The Case of the Great Router Robbery

Here’s another post I wrote for the InfoSec Institute. What are the consequences for an enterprise if one of their branch routers is stolen? Read the article here – comments welcome!

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

hMailServer script to anonymise internal IP addresses

We all know that (accidentally) exposing private information to all and sundry is a bad thing; information leaked in SMTP Received: headers is a goldmine for pentesters and blackhats alike. Here’s a little script for hMailServer which will anonymise the names and IP addresses of internal SMTP mail clients that would otherwise be placed into a Received: header.

The script might need some tweaking to suit your environment:

• It will anonymise Received: headers only when the connecting client’s IP address starts with 172.16. Alter this check to suit your own environment
• You’ll need to change mail.example.com to whatever hMailServer’s Local host name is set to (under Settings->Protocols->SMTP->Delivery of e-mail)

hMailServer scripts are by default written in VBScript; I’ve had extensive counselling to get over the experience, and I’m fine now.

Tweak the script below, then add it to EventHandlers.vbs. Take care if you already have a handler defined for OnAcceptMessage:

‘ Strips out private IP addresses from Received header
‘ if the client’s IP address is in 172.16.0.0/16
Sub OnAcceptMessage(oClient, oMessage)

‘ Check client’s IP address – we only want to do this work
‘ for internal clients
If Left( oClient.IPAddress, 7 ) = “172.16.” Then

Dim oHeaders
set oHeaders = oMessage.Headers

‘ Iterate over the headers looking for Received:
Dim i
For i = oHeaders.Count -1 To 0 Step -1

Dim oHeader
Set oHeader = oHeaders.Item(i)

‘ Check if this is a header which we should modify.
If LCase(oHeader.Name) = “received” Then

‘ Log the header value in case we need it later on
EventLog.Write(“Pre-anonymisation: ” + oHeader.Value)

‘ Set up the regex
Dim myRegExp
Set myRegExp = New RegExp
myRegExp.Global = False
myRegExp.Pattern = “\bfrom[\-\sA-Za-z0-9\.\]\[\(\)]*by mail.example.com\b”

‘ Do the replacement
oHeader.Value = myRegExp.Replace( oHeader.Value, “from mailclient by mail.example.com” )

‘ Dump the modified header
EventLog.Write(“Post-anonymisation: ” + oHeader.Value)

End If

Next
‘ Save all the changes…
oMessage.Save

End If

End Sub

The before-and-after Received: headers look like this:

Received: from some-machine ([172.16.28.16]) by mail.example.com ; Tue, 8 Jun 2010 11:49:22 +0100
Received: from mailclient by mail.example.com ; Tue, 8 Jun 2010 11:49:22 +0100

…thereby neatly hiding the fact that there is an internal machine called some-machine at IP address 172.16.28.16. The original header is logged to hMailServer’s EventLog file in case it’s needed later on for debugging, or during Incident Response or other forensic activity.

You can download the script here – I hope someone finds it useful!

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

Information Escapology, part five – Careful with That Proxy, Eugene

Back here, I claimed that when presented with a login box web users would blindly enter whichever set of credentials came to mind whether they were relevant or not. It turns out that I had failed to dig deeply enough into the evidence, and was displaying a little bit of defensive avoidance – had I dug deeper and looked at the timings of the authentication exchange and the authentication scheme in use, I’d have seen that nothing of the sort was going on. I’ll put on the dunce’s cap and spend the rest of the lesson facing the wall in the corner of the classroom.

However, the truth is perhaps more interesting. It’s not the user leaking information, their proxy server does it for them without their knowledge.

Part four of this series was written after we noticed failed type 3 logons appearing in the Security event log of an IIS webserver. These log entries were a byproduct of the webserver serving up “401 Unauthorized” messages to visitors, which ties up nicely with what’s written here:

Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well as most logons to IIS.

The webserver shouldn’t really have been serving up the 401s at all – there was a slight glitch in the site related to a script responsible for producing the CSS for the page being viewed. Its URL looks a bit like this:

http://www.example.com/scripts/mycss.aspx?param1=value1&param2=value2

Under certain circumstances, some clients (later determined to be proxies) would try to access the page like this:

http://www.example.com/scripts/?param1=value1&param2=value2

“mycss.aspx” is missing, so this URL is effectively a request for a directory listing (albeit embellished with parameters) and would normally result in a “403 Forbidden” message. So why the 401s? The scripts virtual directory has the default settings under Directory Security:

…but the “read” permission has been removed; it only allows “Scripts and Executables”:

So when the proxy asks for the URL with mycss.aspx missing, it’s really asking for a directory listing of a directory with no read permissions. This check apparently takes precedence over the check for the “directory browsing” permission, and it causes IIS to want the user to authenticate despite the fact that anonymous access is allowed. Only Integrated Windows authentication (IWA) is configured (since this is specified by default) so this is what IIS will ask the client to do.

What we have here is a situation where Integrated Windows authentication will be invoked, albeit unintentionally. However, this oughtn’t cause any problems for two reasons:

1. Integrated Windows authentication does not work through proxies
2. Integrated Windows authentication will, by default, only be attempted for sites that are in IE’s “Local Intranet” zone

However, certain proxies do Clever Tricks to make IWA work. BlueCoat, for example, uses a redirect to a “Virtual URL” in the Local Intranet zone to trick IE into performing an IWA exchange (see here under “For TRANSPARENT proxies”, and here). A BlueCoat configured like this (when visiting the site described above) will show the user a login box, but not before it has completed an IWA exchange and left the user’s username, machine name, and domain name in the Security event log on the webserver. There is nothing the user can do to prevent this information being leaked.

Surely nobody configures their proxy like this though? The whole reasoning for IWA only working for sites in the Intranet Zone is to prevent exactly this kind of leak from happening. Well, we’ve seen proxies behaving like this from all sorts of places:

• A city council
• A school
• A multinational corporation
• A telecoms giant favoured by Jedi Masters (Yodaphone, or something…)

Not all the proxies concerned are BlueCoats, and not all BlueCoats exhibit the same issue (so it looks like it’s down to the configuration of each individual proxy). If you want to see if your own proxy is leaking, I’ve set up a testbed <nolongeravailable>. If you’re happy to potentially leak your Windows login name, your machine name and your domain name, click the link, dismiss the login box without entering anything, and drop me a line with your proxy’s public IP address. I’ll let you know if you’re leaking.

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

Information Escapology, part four – Ask, and ye shall receive

One of the websites we monitor has a teeny problem, in that there is something somewhere on it that that causes the users to see a spurious “401 Unauthorized” message. Tracking down and removing the problem is straightforward, so I don’t want to write about that. I want to write about what the users do when this happens.

The site in question isn’t anything particularly elaborate – it’s public access, and there are no user accounts or login boxes at all. The users are merrily browsing away, when all of a sudden they hit the part of the site that raises the spurious 401s. The net result in this specific case is that the browser starts the HTTP authentication process, and a login box is presented to the user.

Now, what do users do when they see a login box? Despite the fact that this site has no user logins whatsoever, they do what they are conditioned to do…

…which is to type in their username and password.

There is no reason for them to do this. They just seem to see the login box that is a byproduct of the unintentional HTTP authentication process, and type away. They don’t have any credentials for this particular site (because there aren’t any), so they just go ahead and try whichever set comes to mind (Windows login credentials, mostly).

User psychology aside, from an NSM perspective we can harvest quite a bit of information. If the website is using IIS and is set up to use Integrated Authentication, we’ll be able to see (from a full-content capture) the user’s username, their machine name and their Windows domain name. If it’s set up to use Basic authentication, we’ll be able to see their username and password. If we can somehow make different parts of the site use both of these authentication schemes we’ll have the whole lot, plus of course their IP address from the web server logfiles.

It’s an interesting way to take a phishing trip!

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

Information Escapology, part three – Clippy’s Revenge

In the Good Old Days, the clipboard was a simple thing. Highlight some text, copy, paste it somewhere else. These days it’s a little more comprehensive – if you copy some text, there’s a good chance that the text’s attributes will get copied as well. This may or may not be of consequence, depending on where you paste it.

I came across an email recently where the sender had copied two cells from Excel and pasted them into Outlook along with a question. The stuff pasted from Excel looked like this, all nicely formatted in a table, just as if it were two cells in a spreadsheet:

Policy 6gX1

All business units MUST implement Policy 6gX1

It doesn’t tell me much about the super-secret Policy 6gX1, but the clipboard has preserved the Hyperlink properties of the first cell. Ignoring the fact that WordPress has knackered the link (don’t bother clicking it), here is what it actually was:

<a href=”file:///C:/Documents%20and%20Settings/j.bond/Local%20Settings/Temporary%20Internet%20Files/Project%20Rattlesnake%20verysecret.xlsx#%27Guidance%20Notes%27%21AB23″>Policy 6gX1</a>

What can we tell from this:

• The sender is using Windows XP/Server 2003 or below, belied by the “Documents and Settings” folder
• The sender’s Windows logon account is called j.bond
• Policy 6gX1 is related somehow to Project Rattlesnake
• They’re using a later version of Excel (xlsx extension vs. xls)
• “Project Rattlesnake verysecret.xlsx” is in the IE cache directory, indicating that it’s available for download somewhere
• “Project Rattlesnake versyecret.xlsx” has a sheet in it called “Guidance Notes”
• The “Guidance Notes” sheet is quite large, because the link refers to cell AB23.

Not entirely earthshattering information, but something like this could just provide a social engineer with enough additional context and terminology to establish a credible pretext.

Take care with the clipboard; who knows when Clippy will exact his vengeance!

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

Information Escapology, part two – The Perils of Top Posting

Posting styles are a matter of personal choice; top posting is probably the most common one, possibly influenced by the design of everyday email clients. When replying to a message, software like Microsoft Outlook will put the original message below the caret, leading to an ever-growing top-posted exchange between the participants.

I’m not going incite a flame war by debating the various merits of each posting style, but I do have a word of caution.

With a top-posted conversation, it’s very easy to get into the cycle of hit-reply->type->hit-send. The context for your thoughts is the message you are directly replying to, the last one in the chain; it’s easy to lose track of what’s been said previously.

The problem comes when you introduce a third party to the conversation – how many times have you received an email like the one below that arrived in Tim’s inbox:

From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director; Tim, IT Support
Subject: RE: Outlook

Tim,

Email seems really slow today. Please could you investigate as a priority.

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

It’s not just you. Every message I’ve sent today has taken ages to get through.

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: RE: Outlook

Is it just me, or is email really slow today?

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

That’s true, but he’s better at his job than the other two are at theirs. Perhaps we should cut his salary as well as let someone go?

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: RE: Outlook

Can we get rid of Brian? He gets paid twice what the others do.

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

Possible candidates:

Sue, from design.
Tim, from IT.
Brian, from marketing.

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: Outlook

Things aren’t looking good. We’re going to have to let some people go. Any thoughts on who?

Bob

It’s perhaps a silly example, but you get the idea. Bob and Ken’s focus has shifted from their company’s impending doom to a technical matter, and they’ve inadvertently disclosed to Tim far more than they intended to. The “top post by design” nature of their email clients has caused them to lose awareness that this email exchange is getting longer and longer and is containing more and more information.

The next time you receive an email with RE: in the subject line, scroll down and see how far the rabbit hole goes. The next time you send a reply, make sure you know exactly what you’re sending. Otherwise you’ll end up on the receiving end of Tim, Sue and Brian…

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