We see it all around us, recently. Web applications get niftier by the day by utilising the various new techniques recently introduced in a few web-browsers, like I.E. and Firefox. One of those new techniques involves using Javascript. More specifically, the XmlHttpRequest-class, or object.

Webmail applications use it to quickly update the list of messages in your Inbox, while other applications use the technology to suggest various search-queries in real-time. All this without reloading the main, sometimes image- and banner- ridden, page. (That said, it will most probably be used by some of those ads as well.)

Before we go into possible weaknesses and things to keep in mind when implementing an AJAX enabled application, first a brief description of how this technology works.

The Basics

Asynchronous Javascript and XML, dubbed AJAX is basically doing this. Let me illustrate with an example, an email application. You are looking at your Inbox and want to delete a message. Normally, in plain HTML applications, the POST or GET request would perform the action, and re-locate to the Inbox, effectively reloading it.

With the XmlHttpRequest-object, however, this request can be done while the main page is still being shown.

In the background a call is made which performs the actual action on the server, and optionally responds with new data. (Note that this request can only be made to the web-site that the script is hosted on: it would leave massive DoS possibilities if I can create an HTML page that, using Javascript, can request thousands of concurrent web-pages from a web-site. You can guess what happens if a lot of people would visit that page.)

The Question

Some web-enabled applications, such as for email, do have pretty destructive functionality that could possibly be abused. The question is — will the average AJAX-enabled web-application be able to tell the difference between a real and a faked XmlHttpRequest?

Do you know if your recently developed AJAX-enabled or enhanced application is able to do this? And if so — does it do this adequately?

Do you even check referrers or some trivial token such as the user-agent? Chances are you do not even know. Chances are that other people, by now, do.

To be sure that the system you have implemented — or one you are interested in using — is properly secured, thus trustworthy, one has to ‘sniff around’.

Incidentally, the first time I discovered such a thing was in a lame preview function for a lame ringtone-site. Basically, the XmlHttpRequest URI’s ‘len’ parameter specified the length of the preview to generate and it seemed like it was loading the original file. Entering this URI in a browser (well, actually, ‘curl‘), specifying a very large value, one could easily grab all the files.

This is a fatal mistake: implement an AJAX interface accepting GET requests. GET requests are the easiest to fake. More on this later.

The question is — can we perform an action while somebody is logged in somewhere else. It is basically XSS/CSS (Cross Site Scripting) but then again, it isn’t.

My Prediction

Some popular applications I checked are hardened in such a way that they use some form of random sequence numbering: the server tells it, encoded, what the application should use as a sequence number when sending the next command. This is mostly obscured by Javascript and a pain in the ass to dissect — but not impossible.

And as you may have already noted: if there is improper authentication on the location called by the XmlHttpRequest-object, this would leave a possibility for malicious purpose. This is exactly where we can expect weaknesses and holes to arise.There should be proper authentication in place. At all times.

As all these systems are built by men, chances are this isn’t done properly.

HTTP traffic analysis
Analysing HTTP traffic analysis with tools like ethereal (yeh I like GUIs so sue me) surely comes in handy to figure out whether applications you use are actually safe from exploitation. This application allows one to easily filter and follow TCP streams so one can properly analyse what is happening there.

If you want to investigate your own application, the use of a sniffer isn’t even necessary but I would suggest you let a colleague that hasn’t implemented it, play around with your app and a sniffer in an attempt to ‘break’ through it.

Cookies
Cookies are our friend when it comes to exploiting, I mean researching any vulnerabilities in AJAX implementations.

If the XmlHttp-interface is merely protected by cookies, exploiting this is all the easier: the moment you get the browser to make a request to that website, your browser is happily sending any cookies along with it.

Back to my earlier remark about a GET-requests being a pretty lame implementation: from a developers point of view, I can imagine one temporary accepts GET requests to be able to easily debug stuff without having to constantly enter irritating HTTP data using telnet. But when you are done with it you really should disable it immediately!

I could shove a GET request hidden in an image link. Sure the browser doesn’t understand the returned data which might not even be an image. But my browser does happily send any authenticating cookies, and the web-application on the other end will have performed some operation.

Using GET is a major mistake-a-to-make. POST is a lot better, as it harder to fake. The XmlHttpRequest can easily do a POST. But I cannot get a script, for instance I could have embedded one in this article, to do a POST request to another website because of the earlier noted restriction: you can only request to the same web-site the web-application is on.

One can modify its own browser, to make request to other websites, but it would be hard to get the browser on somebody elses machine to do this.

Or would it?

If proper authentication, or rather credential verification, still sucks, I can still set up a web-site that does the exact POST method that the AJAX interface expects. That will be accepted and the operation will be performed. Incidentally I have found a popular site that, so far, does not seem to have proper checks in place. More on that one in another article.

Merely using cookies is again a bad idea.

One should also check the User-Agent and possibly a Referrer (the XmlHttpRequest nicely allows one to send any additional headers so you could just put some other token in the Referrer-field). Sure these can still be faked — but it may fend off some investigating skiddiots.

Sequence Numbering, kinda…

A possible way of securing one’s application is using some form of ‘sequence-numbering’-like scheme.

Roughly, this boils down to this.

One should let the page, or some include javascript, generated on the server side, include some token that the performs some operation on which gives a result which is used in any consecutive request to the webserver. The webserver should not allow any request with another ‘sequence number’, so to speak.

The servers’ ‘challenge-string‘ should be as random as possible in order to make it non-predictable: if one could guess what the next sequence number will be, it is again wide open for abuse.

There are properly other ways of hardening interfaces like this, but they all basically come down to getting some fixed information from the webserver as far away from the end-users reach as possible.

You can implement this as complex as you want but can be implemented very basic as well.

For instance when I, as a logged-in user of a web-enabled email-application get assigned a Session-ID and stuff, the page that my browser receives includes a variable iSeq which contains an non-predictable number. When I click “Delete This Message”, this number is transmitted with the rest of the parameters. The server can then respond with new data and, hidden in the cookies or other HTTP Requests field, pass the next sequence number that the web-server will accept as a valid request, only.

As far as I know, these seems the only way of securing it. This can still be abused if spyware sniffs HTTP communications — which they recently started doing.

Javascript Insertion

On a side note I wanted to throw in a remark on Javascript Insertion. This is an old security violation and not really restricted to AJAX, and not an attack on AJAX. Rather, it is an attack utilising the XmlHttpRequest object for malice.

If I would be able to insert Javascript in the web-application I am currently looking at in my other browser window, I would be able to easily delete any post the site allows me to delete. Now that doesn’t seem all that destructive as it only affects that user? Wrong, any user visiting will have its own posts deleted. Ouch.

Javascript insertion has been a nasty one for years and it still is when people throw their home-brew stuff into production.

On a weak implemented forum or web-journal, one could even post new messages — including the Javascript so that any visitor — with the proper permission — would re-post the message keeping the flood of spam coming.

As these technologies keep developing — and lazy website developers do not update their websites to keep up with these changes.

The recent ‘AJAX enhancements’ that some sites got recently might have been improperly implemented. This year might be a good time to check all those old web-applications for any possible Javascript insertion tricks.

If you didn’t mind the cookies getting caught — the sudden deletion of random items and/or public embarrassment might be something to entice you to verify your the code.

Digg This Article

1. Introduction

This article describes and partly implements a method to delete or re-locate, potentially sensitive and / or incriminating information from your UNIX flavoured machine, after the sad event of your death.

An older version of this article has been published before, yet it has since disappeared from the Internet and the Google cache; hence this re-post.

Initially, the intent of the whole idea of Post-Mortem Data Destruction (PMDD), or Post-Life Data Destruction, was humorous. Thus, this document should be taken lightly.

Incidentally it can be of use to interested people as this article does contain some useful tips / pointers if one decides to build such a system. For some of you that lack common sense: any damage you might cause to your machine after reading this document is entirely your own fault.

Note that this article, obviously, assumes that the machine that the data is on, is under your own control. We will continue to look at various motivations for PMDD, below. Note that this whole theory does not apply when you are using remote storage systems (i.e. virtual drives) as the information is then stored on a remote location and we cannot be sure that the remote system really deletes your data. Their EULA might state that they do but the truly paranoid wouldn’t make the assumption that they really delete it. I sincerely wonder why one would actually ever use such a remote virtual drive — by definition these are un-trusted. But I slightly digress..

2. Motivation

You can have various motivations for wanting your data destroyed after your death:

• You don’t want years of valuable research to fall into the wrong hands,
• You don’t want your girlfriend or room-mates to find your collection of granny pr0n,
• You are paranoid, or just uncomfortable with the idea somebody else will read your stuff after you have died.

Motivations for moving, i.e. sending out certain data upon the event of your death could be:

• You are the maintainer of an important piece of software and you want the other people working on the project to have access to the latest modification you have made,
• You suspect your elimination because of messing around with the wrong people, and want certain data (i.e. copies of emails) to be sent to, for instance, a newspaper.

After you have died, it’s too late: it will be virtually impossible to log in to your machine and delete data. Note that haunting is only reserved to a few (hurt) souls and such a state can not be guaranteed. Fat chance you’re able to sit behind a terminal in the after-life, too.

One could opt for encryption, making it hard for a person to recover the data — but that doesn’t really guarantee anything. In the event of your death, the partitions would be available to anyone that can get their hands on it. If the encrypted partitions are gone, they can never…

Let us continue by making a technical analysis of the problem at hand.

3. Technical Description

You are probably aware of the way that watchdog-chips work; basically they change a byte somewhere in memory regularly, and if that byte hasn’t changed within a set period of time, the machine is possible hanging and needs a reboot.

We can use a similar method to check whether you are still alive: a machine regularly sends you a message (either through email, an SMS or through a carrier pigeon, whichever you prefer) and expects an answer back.

If the machine hasn’t received an answer within a configurable time-lapse, the machine can safely assume that you have died.

This obviously isn’t rocket-science — implementing such a system is pretty straight-forward.

Setting it up is a whole other can of worms: you have to be careful as wrong settings might result in a false-positive. A false-positive might render your machine useless when you come back from your holiday to the Antarctic, where GSM and Internet coverage isn’t really that impressive.

In order for such a ‘system’ to be built, we can divide it up into three, logical, parts:

• Sender: This part sends out the ‘Are You Alive?‘-message (I will refer to this as the an AYA-message further in this document)
• Receiver: This part receives the ‘I Am Alive‘-message (which I will refer to as the IAA-message in the rest of this document),
• Checker: This part checks whether a message has been received within a reasonable amount of time — or not.

  The Checker is the core of the system that makes the actual assumption whether you are still alive (or not) and will initiate the data destruction process.

Below, we will look at each of these three parts with a little more detail.

3.1 Sender

This part must implement the sending of the message. Messages can be sent over numerous transport-media, i.e. email or SMS, so you have to pick the one you prefer. You could also choose sending the AYA-message over more transport-media to be sure that you will receive and answer it in time.

(UNIX users could use ‘crontab’ here to send it out, for instance every day at 21:00 PM. Some checkups need to be built-in though to prevent AYA messages from being sent when the last one hasn’t been responded too, etc. But those are implementation details I will go into later on.)

3.2 Receiver

This part must handle the incoming IAA-message. The location of the Receiver is dependant on the form of transport you have chosen; If you want the AYA-messages to be sent over email, the IAA-message will come in via email.

(UNIX users could use ‘procmail’ here in order to inspect the incoming message, and act upon it.)

3.3 Checker

This part checks regularly whether a AYA message has been sent, and if an IAA message has been received.

If the IAA isn’t received within a reasonable (configurable) amount of time the machine must assume you have died and optionally start emailing some data out before finally destroying it. We will go into the ‘Destruction Process’ later on.

UNIX users could write a simple script for this that retrieves and manipulates the state-information somewhere on the file-system.

All the above mentioned parts should have some redundancy built in and should properly react in error situations. It would be a pain to find out that a message could not be sent because of your ISP being down. In that situation you have never received, thus replied, the AYA message, and your machine will think you are dead…

If you don’t watch out, your data will be deleted and you might as well kill yourself.

4. Death Detection Caveats

Below I will go into various things that you need to keep in mind when implementing a Death Detection system.

4.1 State-Information

The Sender, the Receiver and the Checker all need to be fully aware of eachother: the Sender needs to know if a previous AYA has been answered. We do not want AYA’s sent out when the previous AYA hasn’t been answered yet as doing so might cause a flood of AYA’s that you have to answer to in time, to prevent your machine from destroying itself.

Either through some form of Inter Process Communication, be it in memory through the UNIX IPC system, or simply on disk by using a couple of files.The latter would be a more wise thing to do as it will retain your data in the event of a power outage.

The state-information should be accessible and writable for all the other parts of the system, obviously.

4.2 Configuration and Control

Sending Out The `Are You Alive’-messages
You have to keep a few things in mind setting the times the AYA message must be sent.

If you want your machine to detect your death as soon as possible you have to send out the AYAs every 5 minutes. But do you really want to reply to the email or SMS message every day? I don’t think so. And sending it out, say, every month creates another problem: you might forget all about it just before you go to a place without SMS or email access. Worse case scenario might be that you come back and find out your machine thought you were already dead.

Going On a Holiday?
If you go away on a holiday or know you have no access to email of SMS for some time, you sometimes cannot answer to the messages. Or I can imagine other situation when you don’t want to go through the hassle of replying to the incoming AYA messages, for a short while.

It should be possible to disable the system if you know you cannot respond to AYA messages.

If you want, you could build some extra stuff into the Receiver to handle specific commands. For instance, sending a message like this could disable the system for 14 days.

To: dd-at-domain.com
Subject: STFU 14D


Additionally you could insert a password to prevent abuse.

Implementing certain commands of course requires some changes in all the parts: the Receiver must set some flag in the state-information indicating the Sender and the Checker to do nothing until the flag is unset.

Incidentally, when the Receiver receives a ‘Command Message’ it should assume that the last sent AYA, if still pending, has been responded to. (It is a logic assumption to make that you are still alive if the machine receives a Command Message from you.)

Broken Phone?
Imagine the scenario where you have just received the AYA message — but your phone broke. Or your battery just went dead.

Not nice if you really need to send a message to your computer and the only allowed phone is the one with your Caller-ID.

Just make sure you can control the system from an ‘alien’ phone. Password protected, of course.

Sending Out Your Private Data
This functionality requires some configuration; if you want data to be sent out, the machine needs to know what data and which email-address to send it to. Of course you could also use secure copy (scp) as a way to get the data out.

As an illustration I include a sample configuration-file which should be parsed by the process handling the sending:

# Directory / Target email-address
/home/my_home/development/cracking_tools/ partner_in_crime-at-gmail.com
/home/my_home/911_conspiracy_evidence/ breakingnews-at-bbc.co.uk

After succesfully sending out the information, depending on ones level of paranoia, you could optionally destruct the local copy of this information.

5. Data Destruction Caveats

The only proper way of deleting sensitive data is by Drive-Slagging [too bad the images don't work on that link anymore].

Data destruction is virtually impossible to do if you’re not spending your after-life on Earth as a poltergeist. (See my other pending document which will be out as soon as I got some relevant hands-on experience.)

Be aware that, even after a format, the electromagnetic surface still contains traces of the data previously stored. Forensic experts could theoretically reconstruct the data. It would be harder for these experts if you have written random garbage over your old file-system a couple of times. (Some people say 33 times should be enough, others say 10, while other say “Given enough money and time, all data can be recovered.”.)

In order for us to be able to write over the partition we are possibly currently running on, we have created ourselves a little problem, especially if we want to overwrite parts of the disk a few times. After the first pass, the command you executed (and the libraries it depended on) are gone, so it isn’t guaranteed it comes to the 2nd pass (and you know what they say about assumptions).

An possible solution for this could be to install the Data Destructor on a different, non-mounted, partition.

This partition should be bootable and contain enough programs to perform the destructive disk access operations.

When the Data Destruction should take place, the current LILO of GRUB configuration should be altered to automatically boot into this special partition which will start the destructive task, and reboot making it active.

After rebooting and deleting and overwriting the data (optionally with multiple passes), the machine should shut down.

What finally is left is your special partition (which doesn’t really matter) and some partitions with random garbage on it.

If you want to impress your room-mates you could make this special partition, when booted, display the following message, or similar:

I am dead. You have no reason to look at my computer. Sod off!

Too bad you’re not alive to see the expression on their faces.

Digg This Story

Following the recent post by backbone, I decided to post a short introduction as well.

Background
I am from The Netherlands, Europe — a country most people probably have heard about. Either because of the legendary HackTic-foundation that later started the ISP XS4ALL and otherwise undoubtably because of our liberal stance towards soft-drugs and prostitution.

I have always been drawn to computers and remember tinkering with them ever since my parents bought one, a Commodore 64. At that time, we didn’t have that much money to spend so I was forced to write my own programs and games. This experience basically laid the basis for my profession as a programmer, later in life.

As time passed, other computers came into our house-hold, mainly because of my dad’s job. Things started getting really interesting on the PC. MSDOS, PCDOS, various programming languages such as BASIC and Pascal, applications suchs as DBASE.

In contrast to people who have only experience with graphical user interfaces such as Microsoft’s and Apple’s, because of the experience with the command-line, UNIX-flavoured operating systems don’t scare me.

In the Present
Currently, I am a programmer for a media company. The operating systems I work on are all UNIX-flavours. I can ‘speak’ most relevant (programming) languages available on those machines: C(++), Shell scripting, PHP, Javascript, SQL and HTML to name but a few. I have had the privilege to tinker with J2ME (that’s Java for mobile devices such as phones) as well.

I mainly implement the technology behind web-sites, such as content-management systems and various types of server-to-server communication. Additionally, I write plugins for interactive voice response systems such as Bayonne.

Additionally, I also do system administration on few of those servers so I have grown quite interested in server security as well.

In my spare time, because I’m cheap, I still write my own software. If I’m out of suggestion, my girlfriend sometimes has a request for something. For the last couple of years I love to make everything web-based. This fuelled my interest in web-based user-interfaces and the technology behind it, databases, scripting and secure communications.

Future
Being a coder, my articles will mainly focus on programming. How to, and how not to implement stuff safe and secure. Fact is, programs that rely on end-user input are by definition un-safe.

Knowing the business-side of the chain so to speak, I have come to discover that a lot of companies, simply because of the lack of knowledge, money or time, fail to implement online systems secure enough.

Technology is going faster than most people can keep track of it and this has implications that some people might ignore.