|
features post Articles
(Articles)
online chat server:
irc.xor.cx
channel:
#neworderrandom article
quotable quotes Those who foresee the future and recognize it as tragic are often seized by a madness which forces them to commit the very acts which makes it certain that what they dread shall happen. Dame Rebecca West
|
Targeted, Mass Distributed Mail Bombing : Theoretical Denial of Service Attack
@ Articles -> Security
Dec 06 2004, 15:30 (UTC+0) | psg writes:
0. Contents
1. Introduction
2. Method
3. The Attack Vector
4. Fictional Timeline
5. Effects
6. Conclusion
1. Introduction
Mail "Bombing" is perhaps one of the oldest and certainly considered one of the "lamest", that is to say; ineffective and immature, methods of "attack" available to the would-be "script kiddie" or otherwise malicious user online. Simply dating back to the first time someone realised hundreds of irrelevant emails sent to someone else's inbox could be an extreme, and most importantly time wasting, annoyance.
The theory behind the attack is relatively simple; flood your chosen targets inbox with as many junk emails as possible over a given time vector; for example an attacker may devote a few hours run time to sending the "bomb".
In practise the attack is easily achieved with varying degree's of success by any number of specifically designed programs able to send thousands, if not tens of thousands, of emails on command over a relatively short space of time.
However a flaw had developed with this attack strategy (which at it's conception was in fact quite effective). As the internet developed from an academic to a more commercial institution and due to the vast swathes of Spam mail (eg. junk mail) online, complex and often very effective anti-Spam (in this context interchangeable with the term "anti-junk") backend software (such as White Mail, www.whitemail.ie) has been developed with the soul purpose of preventing junk mail arriving in users inbox's.
Such software effectively nullifies a traditional Mail Bomb attack by such methods as:
a) blocking incoming mail from an IP when an inordinate/inappropriate number of emails have been received from that IP,
b) filtering emails by topic and content; blocking any which are considered by sophisticated backend databases to be Spam or
c) blocking known "problem" (that is to say open and or Spam generating) IP's in the first place.
But could you increase a theoretical "Mail Bombs" effectiveness if you were to randomise your "bombs" origin IP and content, how effective could such an attack be?
Additionally if it is possible to increase the effectiveness of a Mail Bomb as an unconventional Denial of Service attack; would that increase in effectiveness be further stimulated by specifically targeting it toward one target with the intention of not only causing the traditional virtual damage (in terms of network bandwidth etc.) but also aiming to cause maximum disruption to the targets "wet ware" network, that is to say real life employees, by exposing them directly to an online attack.
2. Method
The first objective was to locate sufficient open proxies capable of one way or another relaying outgoing mail. This did not prove to be any great challenge. A short search online located at least one extremely efficient piece of third party software which downloads an updated list of open proxies specifically for this task on demand.
The specific software will not be named in the interests of not unnecessarily increasing the possibility of malicious users actually utilising this attack or indeed, it becoming widespread; likewise any custom code used in the research of this paper. However it is important to recognise the fact that such software (and even if you ignore the previous statement) if not already existent, could easily be written, perhaps more dangerously, specifically written into purpose coded mail bomb software even to the alarmingly sophisticated extent of actually being able to cunningly spoof not only an emails domain of origin but ALL aspects of the email header on a multithreaded and randomised basis, thus totally cloaking the origin of the attack. The theory is sound.
The next objective was to theorise over a suitable target. I choose to speak to an employee of whitemail.ie; wanting to test this theoretical attack against the might of the White Mail back engine; one of the better anti-Spam solutions on the market.
To my surprise the White Mail engine was practically defenceless against a targeted mass distributed mail bomb attack; as I will assume all "anti-spam" backend software is simply and understandably because such software is not designed to defend against such attacks. The multithreaded nature (that is not say; multi-angled from an origin perspective) makes blocking such an attack a very complicated affair. You cannot prevent a target being affected by simply blocking an attackers IP address after a disproportionate number of mails. Further more, by carefully but definitively randomising topic and content to contain non-spam related keywords. Such as, for example:
Subject: Cheers.
Content: Thanks for letting this mail
arrive. Great help to me!
It is highly unlikely that any existing Spam blocking backend will filter out such inconspicuous emails. They simply do not contain any words or phrases which an anti-Spam database will consider threatening, or at least threatening enough to block. Additionally as pointed out to me by a number if industry related individuals while discussing this issue, attaching .pdf files of a suitably large file size will also often ALLOW emails to slip past anti-Spam software for the also simple reason that there is no reason to maliciously send a .pdf as it is largely impossible for them to be in any way malicious; other than perhaps in the case of this theoretical distributed mail bomb attack that is.
3. The Attack Vector
In order to attack a target one must first locate as many email address based upon the targeted network as possible. This would be the first task of any would-be mass mail bomber. The obvious, most effective and indeed simplest attack vector for this are internal mailing lists.
I sent out a questionnaire to a number of IT staff and network administrators to ascertain the legitimacy of my proposed attack vector but knowing from my own experience that a high degree of internal mailing lists are open to receiving email from the internet as opposed to the perhaps safer practice of limiting access to such addresses to the local intranet.
The questions posed were:
1) Does your company use mailing lists for departmental email notifications?
2) If so, are the mailing lists usable from "Net Side"?
One hundred per cent of the questionnaires returned a positive answer to the first question and of those fifty per cent of them returned a positive answer to the second question.
We can conclude roughly from this (without conducting detailed research into the common state of this attack vector over a much wider cross section, which although in the long term very possibly worth doing, was not the main aim of this particular investigation) that around fifty per cent of corporate (or commercial) networks are vulnerable to a theoretical targeted distributed mass mail bomb attack.
The attack vector legitimised and confirmed the next problem for a would-be attacker would be to attain the actual email addresses to bomb. Such addresses can be procured in a number of ways; perhaps the most simple of which being trial an error test mails to the most common possibilities: ie. accounts@target, marketing@target etc etc.
It is also possible (if a little unlikely) that you could socially engineer an answer from the target themselves. It may sound ridiculous to suggest that you could simply phone a targets switchboard, ask for accounts, then simply request the departmental mailing list address; but stranger things have happened, and with the right degree of skill, and a strong cover story anything can be achieved with social engineering. The weakest link in a network is often it's users.
Naturally there are other perhaps more sophisticated methods of obtaining internal mailing list addresses; if one was for example to gain access either on site (a job interview, obviously under a false name) or remotely to the network intranet (back to basics hacking) for example it is highly likely that such lists could be easily located. Additionally 'trashing' (the practise of going through waste bins for information) a target is also likely to yield enough of the internal addresses necessary for this attack to be effective.
There is also always the possibility of 'brute force' bombing. Firstly ascertaining the common syntax of email address for your target (ie. first.surname@target or name@target etc.) then emailing random combinations of names to the targeted network using our theoretical mail bombing software and a database of names (which is probably available or otherwise relatively easily constructed), which although from the attackers point of view would take longer and has a definite lower degree of effectiveness is never the less likely to be effective to at least some degree; largely dependent on how the post office on the target network deals with emails with unknown target addresses. The very worst case positive scenario for the attacker would be to utterly swamp a post office which sends all unknown mail to the postmaster (still not an uncommon practice) with all the mails that were aimed at random combinations of words/names. A result which still achieves some of the desired effect (ie. an increase in the Total Cost of System, such factors to be discussed in more detail later).
It is also important here to note the potential damage that could be caused by various attachments if used in a suitably cunning manner; adding .pdf attachments to mails to feign legitimacy has already been mentioned, but now consider for a moment the possibility of inclusion of compromised .jpg's (ie. jpg's which have been altered to contain code which when executed in certain Microsoft software, a recently patched but likely still extremely viable secondary theoretical factor to this attack).
Such .jpg's, for example, Within a .html based email (perhaps as the focus of the mail, perhaps as a false company logo etc.) could become a very effective tool. Dependent on what code you choose to add to these .jpg's all manner of havoc could be wreaked upon an unsuspecting intranet. The downside to this from an attacking point of view is the inherent increase in the likelihood of detection by anti-Span or anti-Virus software when adding known malicious code or exploits to your mass mails. However when talking about this theoretical attack one must always remember it's a) distributed and b) mass nature. If you send five thousand emails and only three thousand make it past whatever defences there may be, that can still be considered an effective attack within the context of the theory. The key here would be utilising the attack vector to deliver a new perhaps unknown virus or exploit.
4. Fictional Timeline
Imagine that the internal mailing lists for following departments within the target are procured and confirmed: accounts@ sales@ humanresources@.
Out of the target's posted business hours five thousand emails are sent to each of the procured addresses (a relatively low amount). On a random basis some contain large legitimising .pdf attachments, some contain .jpg's infected with virus code designed to destroy the working system directory on infected machines (you can interchange the use of .jpg's here with any java based attack past present or future and the designation to destroy the system directory with just about anything you can imagine; more subtle or otherwise).
Additional emails are sent spoofing localhost domains of the target and instructing users to execute more infected .jpg's (or java script) in order to read instructions on how to cope with the incident. This will further increase the likelihood of any malicious code which makes it past Anti-viral software actually being executed.
Employee's arrive for work discovering a vastly disproportionate number of emails in their inboxes, lost amongst which is their legitimate email. The common and indeed procedural response (confirmed by another question posed on this papers distributed research questionnaire) would be to either phone the IT Department, or lodge a formal request for IT help on a ticket system of some kind. It would not take long for an IT department to become swamped.
Some employee's would, statistically, fall for the ruse adding to the primarily "Wet Were based DoS" already caused by the sheer number of mails that have arrived a more traditional digital attack. Put simply; the more "traps" you send the more likely someone is to trip one; and ultimately an exploit is to be executed. It is an unfortunate fact that a high degree of non "IT Department" staff do not have sufficient computing knowledge to identify such threats. One professional going as far as commenting "The business I currently contract all my time out to? hopeless. Utterly hopeless." In answer to the question "How would you rate the general IT knowledge within your company?" on this papers research questionnaire. A response that can only be encouraging to would-be attackers in all shapes and forms.
The additional question: "Generally speaking do non-IT related employee's in your company understand the risks associated with windows related exploits?" Was posed to which the common answer was a resounding "No."
From this we can conclude with a high degree of certainty that unless the network was entirely and faultlessly patched (an attacker would naturally use the most recently discovered or indeed unknown home grown exploits) infection and or severe damage to at least some target machines would be unavoidable.
5. Effects
The effects on the target network would thus be five fold:
1) Employee's unable to sort their own legitimate email from a mass of junk mail and thus only able to carry out their usual function with varying degree's of success (depending on their function in the first place sales@ in this fictional scenario being perhaps most affected by this element of the "Wet Ware DoS"). This is the primary effect of the attack.
2) A swamped IT department. Perhaps unable to respond as quickly as they should do to any additional threat levelled at them (for example a more conventional DoS attack).
3) Actually lost or damaged data within the target network.
4) Depending on the code added to the planted .jpg's/javascript; viral infection of the network, possibly resulting in remote access doors being opened (naturally depending on the firewall software/hardware located at the target) effectively making this DoS a possible cover for the planting of a further future attack vector in the form of Trojans, or even perhaps data miners searching for specific data and emailing or otherwise sending back, such data to a specified location; it pains to imagine what information could be deliberately searched for on a targeted network; bank account details, employee personal details, perhaps even full and detailed lists of the targets email address (which could aid an attacked in sustaining the attack if the net side internal mailing lists were disabled by the targets network administrators; a sensible first line of defence). The possibilities are endless.
5) Ultimately the DoS causes a vast increase in the Total Cost Of System for the target; which will last as long as it takes to both disinfect the system and to purge all post boxes of junk mail. The beauty of this is that it is so simple to execute; the DoS could be automated, a process set up to attack the target every day at a certain time; with no methods of blocking such an attack being immediately obvious. Without taking drastic measures to block every IP from the distributed attack (a thankless task; given the fact there are always more proxies) this form of attack has the frightening potential to cripple a targets email indefinitely.
6. Conclusion
Due to the relatively obscure and surprising nature of this DoS (mail bombing is not commonly used to disrupt in such an organised manner) combined with the fact that the current generation of email filtering software (anti-Spam/anti-viral backends) are ill prepared to deal with such attacks, it is theoretically potentially disastrous to any target with an identified open main attack vector (that is to say mainly net side internal mailing lists) and is additionally equally as dangerous if a malicious user can otherwise identify, on mass, lists of email addresses relating to the target (via trashing and other methods discussed earlier).
On top of the primary effect; ie. the confusion and disruption potentially caused by this attack in its purest form it is also an effective and dangerous delivery system for, in particular, un-patched or new exploits/virii. An effective method for blocking such attacks needs to be developed before any damage is caused by one.
Research originally conducted for Sidhe Solutions.
|
| Top of page
|
