mailing list archives
Raising Robot Criminals
From: "porkythepig" <porkythepig () onet pl>
Date: Mon, 29 Mar 2010 20:28:06 +0200
"Raising Robot Criminals"
I would like to share few thoughts concerning my recent research of the
automated Sql Injection "seek and penetrate" attack vector, focused on
identity theft and robot-driven attack propagation.
This "report" is a compilation of some analysis done for the runtime code
results and some random thoughts and ideas written down, during different
parts of the whole 2 year case study (all thanks to the advanced MS's
technology called "Notepad")
While there have been dozens white papers on the subject of web application
security as well as on Sql Injection, this text is not yet another one.
Instead, it's a short tale about an automated tool's developement time,
inspired somehow by the subsequently intriguing output data it produced,
data that actually made the code grow and mutate into different shapes.
The main objective was to build up the code and find out how far a fully
automated seek-and-penetrate web-app probing code may go without any human
Moreover: to find what are the possibilities of future mutations for the
attack vector implementations.
I think everyone easily brings up in their mind one of recently most famous
comparisons in computer security research: an intruder who trespasses
somebody's possession to tell the owner that his door locks are not good
Well, this project from the very beginning was not an attempt to discuss
this famous comparison's pros and cons.
Instead I decided to find out what are the ACTUAL NUMBERS between the
execution of that particular attack vector in the wild.
The particular attack vector mutation that has been chosen to implement (but
definitely not the only one there to implement) was a combination of few
software and human factor vulnerabilities:
- sensitive data extraction through SQL Injection in web applications driven
by Microsoft SQL Server and exploiting ASP server side scripts
- personal secret unsecure handling (by owner),
- personal secret unsecure storage (by the trustee),
- weak (or lack of) web search engines anti-robot detection/protection
targeting malicious robot crawlers.
You should also understand, that from obvious reasons certain details
concerning compromised organizations, companies and government institutions,
have been removed or reduced to minimum in this publication.
Also, giving the type of the project and the nature of the "output data", I
have decided NOT TO publish any source code (at least at this moment).
But first a bunch of probably well known facts.
Eleven years ago, Dec 25th 1998 the first official SQL Injection paper was
published in the Phrack magazine, in an article called "NT Web Technology
Since then the attack vector became one of the favourite instruments used by
the cyber criminals in internet conducted data and indetity theft.
The second fact: today's cyberized organizations and companies that web
users trust - that hold their personal data and sensitive unencrypted
secrets: "passwords", bound to home addresses, phone numbers and social
security numbers - are opened for remote penetration.
The last fact is that ever since the SQL command injection attacks began to
sweep the internet's infrastucture, security researchers and grey hats
there, trying to point out and prove the existence of a security hole which
could open wide the particular company's database for possible user indetity
theft, had but three options:
1. To warn the system's owner and await prosecution for computer hacking.
2. Keep their mouth shut, waiting until a cracker does his job silently,
penetrating the system and trading stolen identity data to a 3rd party
and/or turning the company's system into a trojan infection spreading unit.
3. Do nothing and watch how some script-kiddie eventually blows the database
up, resulting often in a rapid and insufficient system patching, sometimes
even without knowing the heart of the issue.
Again: since a detailed public discussion about the actual's organization
cyber security (and their proprietary web applications including app links,
penetration entrypoints, etc.) may generate much havoc - efforts were made
to limit to minimum any details that could uncover direct penetration
entrypoints (ie: links, interfaces) for the vulnerable corporations or
government organizations systems mentioned in this text.
The reason behind that form of security advisory is quite simple - since no
source code will be published for now and additionaly there shoudn't be and
won't be any vulnerable app links listed in the text as "script-kiddie
verifiable" examples - there are actually really few options left on how to
tell something about the actual research results.
Therefore, instead of a formal advisory - here it is - a short story about a
code and the research time itself rather than its results.
Since I'm a programmer - no writer at all - please forgive me my poor
english, style and most of all, my dyslexia :)
2. The Impulse.
As a team of researchers noted, a vulnerability dies when the number of
systems it can exploit shrinks to insignificance.
Basing on that definition one could say that after the recent 10+ years of
rich research intensive exploitation SQL Injection attack vector is alive as
The whole thing with the research and the bot writing began during some
early spring sunday (as usual, somewhere between 1st and 2nd coffee) while I
tried to poke around to find some clues about a cryptography related problem
By a complete accident I've spotted a question message from a totally
different topic, from a user who was eagered to get some info about strange
looking log entries that he found on his Apache server.
He was intrigued by and entry containing part of code-like looking payload
and tried to get the answer if that logged event might have been some kind
of attack attempt. What dragged my attention was the answer, which
acknowledged his suspicions and identified the attack type as the Sql
Injection remote code execution...
Now, I must say here, that since i was kind of "raised" on the oldschool
assembler and rather low-level code tweaking (C64 forever:) over a hi-lev
languages interoperability - I still dont know how but I have, strangely,
kept certain distance as a programmer to any topic concerning SQL and
relational databases before.
Actually I practicaly avoided SQL related activities, either professionaly
or in private projects. The obvious result was my certain ignorance to the
topic, refleced in attraction to a low-lev security issues like memory
corruption and machine code reverse engineering. Finally, I trivialized the
severity of attack vectors aimed against databases in any possible occasion.
Now, you see I was a little bit confused following the SF's user post.
After reading one or two Sql Injection white papers and numerous shouty
articles describing this kind of attack vector multiple commercial system
penetrations, I've had that biggest question on my mind: isn't the DB
command injection threat something like 10 years well researched now and
should be a little bit, well uhhhmmmm .... dead ?
why would anyone seriuosly attempt this kind of attack this days if the
possible positive targets count would be close to zero, after that ammount
of time that passed since it's been first researched and through all theese
years of intensive exploitation?
And what's the deal with the remote code execution SQLi theese days?
Not a long time later, I've realized that being an ignorant has also its
good sides :)
Ironicaly it seems that empirical ignorance may sometimes become
one-helluva-impulse to a private research.
So I've had this huge question on my mind - all I needed was to check if I'm
wrong and the malicious code injection mentioned in the SF user's post was
just one on a milion - some last try of a 10 years old, dying rogue code,
hopelessly knocking on today's secure database world :)
After going through about five "how to crack an Sql DB in less than a
minute" 4yr+ old tutorials I've had all I needed: the algorithm of how to
find a potential victim and how to probe it for penetration ability.
Just as in the SF's user case, I've decided to pick PHP and MySql based DB
for start. And so I've began first "victim" hunt.
Asking google for a subsequent branch-types of companies I've been looking
for my first "accessible" remote DB table record somewhere out there.
And here it is! I've got it!
A sex wax shop...
A hack is a hack.
Just modyfying manualy application's Http/GET params and here we go: we've
got on our screen one by one all the accessible shop's customers details.
And about an hour ago I thought SQLi is a 10 year old dead attack vector :)
If few minutes of manual googling produces an arbitrary DB read access I
guessed it's worth a try to check if there was something more "interesting"
than an online sex wax shop.
After another day or two of sleepless Http/GET params fuzzing and a bunch of
accessed private corp client DBs varying from a fashion agencies to hotel
booking systems I've decided to make friends with the different injection
attack vector approach: ASP.
My collegue's first observation was - "Hey, MSSQL has a really nice user
friendly cracking interface". Nicely formatted error message syntax,
followed by elegantly served contents of programmer (or cracker) selected
table's record, and even precise hex error code number! Well, after all ASP
server side scripting technology is a Microsoft's baby so as usual you get
two in a pack of one.
The deal was actually quite simple: to locate a potential ASP SQLi attack
victim you needed to locate a vulnerable web application endpoint. To do
this you use URL target-filename pattern matching utilizing any web search
engine. The apps-endpoint had of course to interact somehow with
application's server side database, so that we could inject our query and
execute it. And which user's web application interface suits this goal
better than the password based authentication interface :)
So here I was. The nightmare started.
Nothing more but a common script kiddie, sleeping sth like 3hrs a day I
began to change into some kind of monstrous f***d up machine, typing
repeatidely, like a magic spell, one and the same sentence into browser,
again and again, asking google for subseqent matches against different
patterns describing possible system entrypoints.
4. Word play.
Any programmer's job is first to imagine how the "thing" you want to bring
to life is going to work and then comes the fun part - making the names -
for your classes, methods, objects. In your code, everyting has to be named
somehow and you're a god here to make it named. In security researcher's
case however it's quite the opposite - you need to try to stand at the
particular system's programmer place, imagining how could it have been
coded - when you do so, you may be able to pick the places, by a file name
pattern for example, where you would most probably make a mistake and left a
And of course the names... they are always the fun part.
After a day or two of brainless typing you finally begin to notice some
patterns describing the word combinations you type and the results you get.
So, the names were coming and going, one by one, right into the gogole's
System after system, inputting same apostrophe contating random sequence
into all the found FORM html fields, submiting and watching for any sign of
response page containing the familiar MSSQL's error code: 0x80040E14.
Funny that my finger-based "random generator" used for ASP "input fuzzing"
soon lost much of its randomness - after sth like a thousand manually typed
FORM input sequences they finally turned into: 'asd (one could say, it
became more like script-kiddie fingerprint :)
Obviously I did not focused so early on any specific SQLi mutation - giving
a Blind SQL Injection for one - nevertheless the goal remained the same (ie:
to check which one of the two is true: either the SQL Injection attack
vector could in fact become a successful weapon in a potential malicious
hands or that it's rather some old misty fraze nicely described in Wikipedia
and few years long dead).
So few next days seemed pretty same: brainless typing, matching for errors,
looking for subsequent targets, imagining any possible attack propagation
Somewhere at the begining of the third day I've found an entry into a
database of the bank... a SPERM bank to be precise.
"A bank is a bank. And I've just cracked a bank."
I guess I was repeating that to myself at least for next two days.
Anyway. When you notice you have began to act like a machine, repeating one
keyboard driven activity over and over - it is THE time. Finally, the time
to write some code has come. The code that will eventually relieve you from
your pitiful human-only drink/eat/rest limitations and make your vengence
possible upon the evil entity that turned you into machine for the past
The first idea was to code few simple search query generators based on a
static word permutation lists and hook them up using HTTP client into a
google. The case was all about shooting new words, grouping them into
semantic sections and build simple lingual generators that would feed on the
groupped word sections.
For example, the following two groups of words (taken directly from my
code's config file), are to be mixed together creating different
permutations to build a final web search query:
Group0 = Logon
Group0 = Logon1
Group0 = Signon
Group0 = Signin
Group0 = Log_in
Group1 = Client
Group1 = User
Group1 = Master
Group1 = Admin
Group1 = Member
Group1 = Employee
Group1 = Customer
Group1 = Supplier
Using for example this query generator (actually it's the Bot's query
q1 = "inurl:" G0 || ".asp"
q2 = "inurl:" G0 || G1 || ".asp"
q3 = "inurl:" G1 || G0 || ".asp"
q4 = "inurl:" G1 || "/" || G0 || ".asp"
q5 = "inurl:" G1 || G0 || "/" || "default.asp"
We receive something like this:
... and so on.
The whole problem with the search engines is that they provide only a very
small, limited part of the actual query results, that their web crawler
robots were able to harvest from the very start. Asking the search engine
with those queries, we will receive maximum a 1000 hits (for google), while
the number of matching results, following that query pattern is sometimes
several thousand times bigger. Therefore we add for example a second and
third level distinguish-groups, first describing the target company's branch
and second distinquising between domain suffixes.
Group2 = voip
Group2 = remote
Group2 = banking
Group2 = airlines
Group2 = telecom
Group2 = software
Group2 = hosting
Group3 = com
Group3 = org
Group3 = net
Group3 = biz
Group3 = mil
Group3 = gov
Group3 = edu
Concatenating every query definition (in this example q1 to q4) with the
sequence: nq = "+" || G2 || "+" || G3, as a result we get:
The algorithm for query generators is actually quite simple, starting with
the most basic combinations, like:
(combinations of words from just a single group) we expand the query with
different word groups each new level, using specific, programmer defined
At start we submit every generated query, store the results, and check the
result counter for them. If it is larger than the search engine's result
limit (lets say: 1000) we increase the generator level (to 2) and using the
defined concatenation method for that level we generate subsequent queries
with words from the next word group (ie: G1). If the predicted results count
for some or all of the produced query strings is again bigger than the
search engine's limit -> we go for the 3rd level generator concatention, and
The same scheme applies to password reminder services query generator:
Group9 = 1password
Group9 = 1pwd
Group9 = 1pass
Group9 = 1passwd
Group9 = 1pw
Group9 = 0login
Group9 = 0userid
Group10 = 1forgot
Group10 = 1forget
Group10 = 1forgotten
Group10 = 1lost
Group10 = 0find
Group10 = 0search
Group10 = 0email
Group10 = 1recovery
Group10 = 1recover
Group10 = 1retrieve
Group10 = 0get
Group10 = 1change
Group10 = 0new
Group10 = 1reset
Group10 = 1remind
Query Generator #2:
q1 = G9 || '.asp'
q2 = G10 || '.asp'
q3 = G9 || G10 || '.asp'
q4 = G10 || G9 || '.asp'
q5 = G9 || G10 || '/' || 'default.asp'
5. One toy story.
Programmatic automation of human behaviour and watching the code as it
interferes with random human beings is probably one of the coolest things in
Since that actually wasn't first bot coding attempt, I've decided to base
the code in major on one of my previous bot projects: an automated logic
decisioning code - browser MMO auto-playing bot.
The previous code was a kind of "vendetta" over Ogame - an MMO browser game
addiction that brutally took :) almost 3 months of my life (anyway a
differnet kind of story).
Three years after it was "brought to life" I've decided to use its "guts",
ie. HTTP client, HTML parser (bound together to provide a simple browser bot
engine) and basic AI Api (which actually had to be rebuilt almost from
scratch in this case) to create a different type of a robot code.
6. Robot vs. Anti-Robot.
The first problem the new bot stumbled across was Google's anti-robot
protection. Aside of all the rest of code that keeps Google engine alive and
kicing this code was built by them for two things:
1. To prevent the Google servers from being DDoS-killed by remote query
robot repeaters, the ones that for example are being used within automated
2. To recognize, signal and act against certain query patterns, being
possibly malicious, like for example automated web site infection software,
operating round the clock in search of new victims to embed the malicious
scripts within (or to steal the data from).
The first version of code executed without any delays between the queries or
any other kind of logic built in, to deal with the Google's anti-robot code
(I simply didn't have a clue it existed at first place :) and ended up very
quick with service-blocking entire NAT address space of my ISP and
successfuly disabling it to use google for ab. 3h.
The second launch locked the subnet for about half a day :)
So the very next thing done was building in a simple static 30s sleep()
between every page query HTTP request and disabling result-page jumping,
sticking up to just one-page-by-time incremental step. Constant delays of
course doesn't imitate human too perfectly, however the trick worked. At
least for some time...
About two weeks of bot's runtime later I've noticed that only first 100
results out of a thousand queries were dumped by the bot. Analysing the
issue it came out that after 10th result page, Google displayed its old good
"it seems like you're malicious robot trying to take control over the world"
info and denied going further with selected query.
So... Did they implemented a different robot recognition algorithm within
past two weeks, or what?
No. I don't think so.
Changing the delay to a bigger randomized value (90+RND(20)) did the job.
For the next month the first segment of the Bot (ie: the web search engine
hooked up target-seeker) executed without any recognition.
Fooling the Google's engine about being an actual human worked. After a
month turning the value of query page change delay back to static 90s
resulted instantineously with anti-robot service denial HTML warning, after
requesting 10th page. So the conclusion was - to trespass the
robot-protection the bot's thread should spend just enough CPU idle cycles
between every page increment to imitate a human behaviour.
The further analysis shown that the google search engine acts differently
for the queries containing certain URL file name specifiers like ".asp" or
".php". The search queries that has been recognized to ask for theese file
suffixes had simply a longer minimal page change delay to successfuly escape
of being recognized as a "malicious robot". It also has been noticed that
the google bot-lock of entire NAT area differs from 3 to ab. 32h.
Additionaly, the subsequent malicious-looking queries while in robot-lock
state hasn't been updating the lock countdown timer.
Google antibot code identifies remote human/non-human entity by IP not by
search sesssion cookie, resulting in that, a single search from any machine
within a local subnet behind the NAT that SUBSEQUENTLY uses the same search
query pattern (like for example 'inurl:"forgotten.asp"'), will lead to IDing
the subnet's public IP as a hostile by Google's code.
Anyway, long story short: to fool the Google's anti-bot protection we need
proper delays and human-like action randomization.
Building a protection against the query auto-generating process employed by
the robot software is not as difficult and obviously there could be
implemented more precise detection of the automated SQLi query syntax, by
the web search engine providers. Afterall, I guess it shoudn't be as easy as
googling your homework to search for the R/W accessible sex wax shop
customer database and get all clients info on the screen or to search for
the vulnerable US Department of Justice system like you would have been
googling for a dinner recipe.
However, it should also be considered that where a detection schema for
malicious action exists - there usually are always numerous ways to override
it. Fine detection algorithm shouldn't be taken as a "total cure" for the
attacks using "robot-googling" as victim search vector.
Ironicaly, while the bot got better and better dealing with google's
anti-robot recognition I was recognized few times by the very same system as
a machine (yepp), while typing search queries manualy, using just an old
school set of ten fingers :)
7. Bot's Development.
There were two major code architecture changes through the whole
developement time so three different, subsequentialy more complex versions
of the bot has been developed, until it shaped into the final (or at least:
current) automated system.
Since the code has been based mostly on previous bot's (MMO bot) code,
written in C++, there wasn't actually much choice to be made about the
programming language. Although one must point that the C++ isn't the best
choice if we want to code a web crawling automated bot - looking backward
from the whole coding time perspective if I had the choice today and had to
write it from the scratch - I would have chosen Python blindfolded (at least
for this kind of robot).
The very first version of bot was a simple automated google query repeater,
using static "target patterns" (ie: ASP file name patterns to search, formed
in a static input list). The static list of about 150 query-word
combinations produced several thousand potential targets, which then were
probed by the pen-test algorithm: retrieve HTML contents -> parse and search
for FORM's -> feed every text-input field with error injection seq (ie:
'having 1=1) -> parse response for MsSQL error message pattern -> if
matched: enumerate all vulnerable SQL query columns -> log target probing
The SECOND code's version was armed with more logic for google's
antirobot-protection "fooling" and introduced "run levels" into the probing
section. The code segment performing actual penetration of positive-matched
targets was given three run levels: vulnerability matching / database
structure enumertaion (tables/columns/column types) / automated record
harvest for every recognized (using name pattern matching) email/password
column name combos. All the harvested EM/PW pairs were stored in the
internal Bot's database.
The third (current) version went multiprocess. The code was divided into 3
sections (called later 'segments') interoperating together through the
internal DB and syncing through a named mutex. Two new major "toys" were
1. "Pattern Generators" (three for now) providing Segment-1 (penetration
target seeker) with possible victim's system URL patterns to use with google
connected query repeater,
2. "Data Objective Patterns" configured from config file, providing quickly
configurable regular expression based descriptions of what data the Bot
should look for, within the penetrable remote database (ie: email/pwd
combos, SSN/ID data, secret question/answer combos, credit card numbers).
The final (current) verions's architecture and execution flow:
The system consists of 3 independent code sections - called simply
'segments' - that perform interruptably their specific objectives in the
forever-loop. The segments are linked between just by a logic chain of the
input/output data - what is an result(output) data of one segment is the
input for the other. For example Segment-2 will not go operational until it
receives enough input data which is automaticaly-produced output of
Segment-1 is an automated web search engine crawler driven by the 3 (so far)
basic word-fraze generators, used to produce subsequent web search queries.
For now the segment is coded to operate on two web search engines:
google.com and search.com. It consists of 3 query pattern generators that
produce subsequently permutations of selected query pattern, utilizing a
specificaly preconfigured for the project 400 word dictionary, divided to 9
functional groups. Every generated query is then used to perform an
automated search using each search engine connected and the results are
stored as Segment-1's output. After last query pattern generator has
produced its last permutation - Segment-1 stops.
Segment-2 objective is to process every potential target address (HTTP/HTTPS
link) that Segment-1's produced. It probes each system ONLY FOR ONE PRECISE
type of SQL Injection vulnerabibity: attack against buggy ASP server side
codes interconnected with MSSQL database systems. After positive match it
builds a penetration entrypoint, enumerates all accessible databases through
the entrypoint and scans all database's table structures for matches within
preconfigured Data Objective Patterns. Finally it "decides" using the DOP
matching which data will be a target for final penetration and performs an
automated data harvest for every DOP matched through all the databases
accessible entrypoints. Then is stores the data, pre-analyses it and goes
for the next target supplied by the S-1.
Segment-3 is driven by the Segment-2's output data, pre-analyzed after every
successful penetration. Every data entry that matches EMLPW Data Objective
Pattern (email/password: every table that has been recognized to hold
email/password combos records) becomes its input. This segment has 2
operational modes. First one is a POP3 proto / HTTP(s) Webmail server
discovery tool. At first it tries to match an email server protocol and
location for every matched email/pw combos from Seg-2. After that using a
recognized mail protocol, it performs a password matching for its
corresponding email address. If the pair: EmailAddress/Password matches - it
opens a mailbox using recognized protocol, enumerates all the messages and
dumps every message containing one or more of the words: "account", "login",
"password", "confidential" or "classified". After processing last output
entry from the Segment-2 this segment stops.
8. A school for a robot.
Before any bot can leave its "master" and go by itself into the dangerous
human world it obviously needs a proper education and training :)
Just as its predecessor - the MMO bot for Ogame - training against different
human opponents on different game's "universums" (servers), trying to grow,
evolve and develop its best suited economic strategy algorithm - also the
SQLi penetration bot has to take its education somewhere. Unfortunately
there is one big difference between a game bot and a search-and-probe bot
like this: as Ogame's client-server game protocol (HTTP based) could be
reversed and described as a static sequence of URLs (links) to use by the AI
"puppet master", the penetration bot need to deal every time with a
different system - so it takes a lot more "training" for the second type of
bot to have the highest probability for that the code will recognize a
vulnerability if it exists and match the target as "negative" if doesn't,
for EVERY pen-tested system.
Keeping false-negatives count as low as possible is a key factor in this
kind of bot. Ironicaly it seems that the opposite situation may also occur
(which I'll try describe later) - the human trained robot could find a
vulnerability in a way that the human didn't even know about, actually, to
be able to train him :)
The first bot's penetration automation has been developed by training it
against vulnerable web database system (found earlier manualy), belonging to
an international, security training company (right, the irony is sometimes
unbearable...) providing private investigation / inteligence solutions. The
developement was just as long as the bot was able to perform successfuly,
ie. exited retrieving all the targeted data (personal information,
login/email/password data records), with no human supervision. First version
of the Bot performed ab. 100 subsequent penetrations of that system, until
it was able to do so, while I was trying to patch the bot's logic flaws and
to make the injection queries syntax used more simple and effective.
Although every time the code harvested the very same data (later
configurable as Data Objective Patterns in bot's second version) -
subsequently aiming data within tables holding logins, emails and passwords
of employees - the process must have been repeated as no code ever runs
bug-free after just first compilation. (BTW: if any of your 'release' code
could ever do so - according to the probability laws - you really should be
These subsequent coding/recompilation/execution steps in order to force the
code to gain exactly same results as a human before, makes the code grow and
learn in order to become a robot. But it is up to human (programmer) to
decide who to await at the end of the "teaching line" - a malicious "robot
criminal" or a vulnerability assesement and response framework.
There is also one big question on morality, left unanswered.
Why the hell to use an unaware life target for an excercise, becoming a
criminal with every single enter you press, while you could build your own
local vulnerable application server or even download a virtualized one,
witin few minutes, preconfigured and pentest-ready?
The question is good.
The answer is tough (if any).
At the begin of the research I was a total SQL newbie (as a programmer). One
of my first goals was to change it - combining the pleasant with the useful.
And it's quite obvious that without a proper theoretical preparation, a
tutorial-only based crack-and-destroy learning approach doesn't make a
researcher of any kind - it makes a script kiddie. Finding differences
within several different life vulnerable systems and matching them against
each other to find all common factors that render them vulnearable is far
more effective way to learn the automated vulnerability detection system
(and me), than study approach based on a single, often naive example, which
is usually already too old to make a realistic model.
While I was learning SQL language syntax - the bot was "learning" SQL
Injection attack vector. For that, I guess every security researcher is a
sinner somewhere there, wandering on his "split guilt" mindfields, leaving
the final "enter key-press" decision to a human robot-code operator.
9. Randomized target penetration.
The penetration target - particular company or organization system is not
human selected here.
The code, employing randomized target pattern matching algorithm "selects"
it for you.
Obviously, saying: "I didn't commited a crime probing the system for the
vuln, the code did it" - is somewhat childish, isn't it?
In the hands of a criminal any kind of pen-testing tool will always be
programmed and used for malicious activities, regardless of its automation
or manual oriented operation architecture.
Everything depends from the programmers intentions - if they were malicious,
the code's behavior should also be expected to be malicious. In practice,
the code that automates some more complex problem solving process is in fact
a kind of snapshot on the strategic planning algorithm of programmers mind,
either it is automated MMORPG tactics-decisioning bot code or a security
vulnerability seek & penetration system.
Therefore, it would be nice to see some day, that the automated tools
seeking for vulnerable information systems over specific country, industry
branch or worldwide are in turn operational and running under control of
people whoose job is to protect us from either cyber criminals or enemy
cyberwarfare, (like for example every country's national CSIRT/CERT units).
At this moment it is not possible for whitehat "samaritans" out there to
perform a remote system penetration testing without previous formal
autorization from the systems owners - no matter how good their intentions
would be and how detailed the pentest report prepared - they are considered
as criminals with the very first enter key pressed.
As long as the particular public web app / web portal vulnerability exists,
it makes a serious threat to any internet user who unaware of digital system
compromise risks, trusted the system creators letting them process his
private ID data along with the most sensitive of all: secrets and passwords,
often universal ones. Once compromised, the system leads an attacker
exploiting universal passwords to compromise of the person's digital
10. Primary Impact analysis.
After the bot's final version has been launched, it performed interruptably
(not including few blackouts during ligthning storms on my village) for
about a month. It probed from the Segment-1 produced list of 200K+ web
system addresses exactly 28944 systems for possible penetration entrypoints.
It matched "positive" against ASP/MSSQL Injection attack, exactly 2601
database servers, and tested them for possible penetration depth,
enumerating any fully accessible (read/write) database system using the
particular entrypoint DB User's access level.
Through a testing runtime month exactly 6557 databases from the particular
2601 DB servers has been matched by the Bot as fully accessible, using the
ASP based attack vector type.
The already known and widely recognized impact of the common SQL Injection
attack falls into few categories:
a) sensitive information disclosure,
b) loss of data integrity,
c) database server remote code execution and further network penetration.
Putting aside for a moment the impact analysis case, I'd like to mention an
accurate observation by a colleague of mine. One of my programmer friends,
not related to a security industry however, once he saw an MSSQL server
compromise in progress called it "an API for database cracking". It was,
after all, a very right comparison.
The default SQL server error reporting configuration, being physicaly one of
the motors of the ASP based command injection "popularity", equips an
attacker with easily text-parser traceable 32bit error code, strict syntax
and a single block error message containing apostroph enclosed particular
data record requested by an attacker - a heaven for parser writers - the
extracted data is prepared and served by server's error reporting engine
like a dinner in a good restaurant. The only thing the attacker should do in
order to watch the selected column's value on his web browser window is to
enforce an ASP server side application to cause an SQL data type mismatch
run-time error (a numeric/character type mismatch error, to be precise).
But lets get back to the impact.
As one security response team stated rightfully in one of its reports - one
of the reasons behind a spree of malicious code embedded within web pages,
may be infection of web page's administrator computer systems with spyware,
crafted specificaly to steal the FTP/SSH protocol passwords stored locally
by client software like TotalCommander or Putty. Despite the fact that
system administrators belong to the security threat highly-aware group, the
possibiblity of the compromise of the webmasters/administrators machine by
malware infection definitely exists.
But this is just one possibility.
On the other hand, a constantly increasing activity, observed in Sql
Injection driven attacks, and observations made during the research could
suggest at least few different infection scenarios.
While analysing Bot's gathered data - some systems that had been found
opened for the penetration by the code's pentest "reconasaince" section
(segment-2) had been also matched (after post-runtime "manual" analysis) to
be previously compromised by a different human attacker (or an attack code).
Certain database records, reflecting the webpage's contents, contained an
redirect the user who launched this particular web site's section or to load
and execute additional JS code from a different HTPP remote server. The
servers addresses in most cases were terminated with chinese domain suffix.
That gives us the first alternative.
The second one is a compromise of a web hosting company.
Serving a proper example right away: the bot gained access to a database of
Polish email/www hosting company, containing all the account login/password
records needed by attacker to take control of any website hosted by the
company, providing the attacker with correct FTP credentials (this case was
also mentioned in other sections of the text). The same schema applies also
to penetrable web application developement company databases.
However, the most frequently noticed (analysing Bot's results), opened way
for attacker to infect a website with a rogue redirection/exploit code, was
to exploit the SQL Injection vulnerability within a minor, less critical or
long time dead but not yet removed webpage, stored however together on a
single SQL server administrated by a more critical assets holding
institution. Exploiting the fact that the vulnerable server side code (lets
say an ASP in our example) while accessing SQL server data can use database
user account shared with many other databases stored on that single server,
an attacker executes automated enumeration of all the R/W accessible
accounts (using for example db_name() MSSql function). After that all he
need is to select any database enumerated earlier, suiting as a DB backend
for the particular WWW site - this time more critical and not vulnerable to
any direct attack - and to alter its contents, leaving the critical "secure"
webpage either defaced or trojan infecting.
An absolute record-holder of this type, giving the number of single SQL
server R/W accessible databases was a job portal developement company. A
minor, old, but still working job website belonging to the company was
tracked down by S1 and verified by S2 as vulnerable to a database command
execution attack using "Register Account" interface as SQL command injection
entrypoint. After enumeration of R/W accessible databases, Bot's S2 counted
800+ databases accessible using same DB user as used by the vulnerable ASP
script, including retired military officer job portal and law enforcement
The most critical system however, given the possible impact of webpage
defacement/malware infection attack, was the case of database server
belonging to the US Defence Logistics Agency (DLA). Five, out of twenty of
all server-stored databases were found write accessible, using same DB user
account shared with the vulnerable ASP code: a very old (dating last century
actually) and hardly operational but still online - same agancy's system,
developed and "maintained" (not that they didn't try) according to a welcome
banner, by the U.S. Space and Naval Warfare Systems Center (SPAWAR). It's
not to hard to imagine the possible impact factor of a defacement/trojan
infection code installment within an official military owned web system,
that utilizes the attacker controlled databases contents to render every
single piece of data and script embeded within their mainpage's HTML body.
Since I've never been a big fan of shouty, messy defacements - all that was
done in that case, to validate if the modification of the particular
selected DLA page's contents (www.desc.dla.mil) was in fact possible using a
vulnerability located in a completely different subdomain - was changing a
single small 'a' letter in the fronpage's welcome text to a capital one.
Actually, if the "mispelling" hasn't been noticed yet, it's quite possible
it is still there ...
One obvious conclusion is that the resulting, final impact of the SQL
Injection attack conducted through a vulnerable website's entrypoint, which
reflects the inter-connected database contents, can be also (for one) the
website driven malware infection, targetting client host machines. The
affected website (hosting a hostile script for redirection / malware
installment now) may be any web application whose contents is rendered using
the database system shared with the vulnerable entrypoint, through the same
ODBC user credentials.
11. I forget, therfore I am.
So, you say you use top-notch only well secured systems, where common
security holes are a far history, yet, your digital account still got hacked
Well, there's at least one thing we might be missing.
Even when you use trusted company systems like e-banking accounts,
government or military provided systems, which, lets assume for a moment,
are free from the most common security flaws :) , your password is long and
random, you keep it private and didn't even whisper it ever - there is still
a single thing that makes any of these different system accounts vulnerable:
your short memory.
The first primitive bot's version, messy coded, with statically compiled-in
search queries (describing just few possible victim patterns), after a day
or two has probed and matched a DB command injection flaw within one of web
applications belonging to an aviation-holding corporation operating in the
USA (the holding owns actually six different airlines).
The actual impulse that turned me to continue this project and to build the
multilevel attack code (rather than just drop the case after getting
acknowledged that the internet is just an SQL Injection swamp) was the
finding, made while "studying" this particular system. After getting the
admin's credentials using the particular SQLi vuln and logging into personel
data administration panel - a single Excel document file was downloaded,
containing updated detailed information of 1361 company workers. Besides
their addresses, phones and SSN numbers, every personal record had filled in
a proper email address, login name and an unprotected plaintext password
belonging to the particular worker of the aviation support company's branch.
Now, I'm sure it may be obvious to you right now, but it wasn't so obvious
to me at the time - while sitting there in the hard chair looking at my
laptop's display reading the ID records - after about half an hour lecture
(I know... I can't help I'm a slow thinker) I've realized I'm not looking on
a computer generated dictionary based passwords, given randomly by the web
application upon the registration - but on the actual VOLUNTARILY PROVIDED
users sensitive keywords, stored without any kind of encryption, keywords
with which every particularly asked person wanted to protect its account.
That, along with the fact that 2 columns on the left from the password field
in the document lay also voluntarily entered contact email address, began to
form that biggest question that haven't stopped driving my mind crazy ever
since: how many of those poor unaware people entered their email address
aside with the very password OPENING IT right into the vulnerable, browser
accessible database system...
That was actually the first time I stood before an option of unauthorized
email access. But since I was already, kinda "fallen researcher" whose
crawling-code was performing sth like 1000 unauthorized penetration tests of
different systems a day - my conscience didn't actually stand a chance...
Copy-pasting first randomly chosen email/password into the mail portal login
page and ... I've had an authenticated yahoo mail account session in front
Ten minutes later I knew the owner was a commercial aircraft pilot working
for a US based airlines, holding pilot license for ERJ-170 / ERJ-190
aircrafts. I had his license number along with the FAA issued pilot license
scans in high resolution (saved on his mailbox in 'sent' box), his SSN
number along with his 401K detailed form sent to an employer and credentials
to access his current funds state and finally an FAA's issued medical
certificate scan informing that he should wear corrective lenses.
But hey! That was just the first email/pwd combo from the list I've used -
it was obvious that it must have been just a fluke. And since getting into
some random email accounts and snooping through people's life was not a kind
of fun I prefer as a researcher I've decided to focus back on the goal: the
numbers behind the password matching attack vector. Until the rest of the
day I've been trying to manualy indentify number of matching/not matching
email credential combos, at least for some small part of the entire list.
Approximately 3 on every 10 passwords tested matched.
Some of them needed to be concatenated with '1' or '2' digit (either at the
begin or end of the password), some of had to be shortened, removing the
numerical suffixes (ex: 'bart1969' was the DB password - giving us
additionaly the victims DOB for free - and the simple 'bart' keyword guarded
the email account). Somewhere after the makeshift lunch I've run into a
hotmail account which happened to belong to a Delta Airlines pilot. That was
THE founding that actually changed my mind and let me decide to continue the
project. After quick search through the pilot's mail account I've noticed a
correspondence with the DA's IT branch, containing another pair of
credentials - a private Delta Airlines pilot web account (extranet)
login/password and a link to DA login portal (connect.delta.com), sent by
the IT branch after the pilot began his work for DA.
He didn't deleted the message (and why would he? - after all we all have a
weak memory) leaving it on his private email account - it is not the case
now to wonder why didn't DA provide him with an internal business mailbox
restricted to be accessible ONLY from a safe intranet or using IT provided
asymmetric enc enabled smart-cards, and finally why did they allow sending
such a sensitive information to a private email account. It is however the
case of what online services could have been accessed through the DA
electronic accounts. Let's just say one of the options that the system
provided to a user(pilot) was downloading airport specific security
information and accessing FBI issued documents concerning aerial terrorist
At the end of that day I've made up my mind: I will not bury the project
after just the first 2 weeks of the research but I'll try to make it grow to
bring up a fully automated code able to perform automaticaly every single
step I've done to get where I was at the moment. The goal was simple: to
find out what numbers 'in the wild' are behind every part of this particular
multilevel attack vector and moreover - what could be its possible
Later, the next morning I identified another DA's pilot email account within
the aviation company customer list downloaded the last day, hosted also on
Hotmail. That account also contained the email, sent from IT, with internal
DA pilot account login credentials. Also multiple other FAA's system
accounts were identified, provided for pilot training / career path
The equation is quite simple: if just one, single system you have ever
logged into (or have account(s) in), by giving it your universal password
scheme AND a contact email, happens to be vulnerable to a database access
attack vector: you may consider any other of your electronic password
protected accounts in different digital systems as compromised - often EVEN
if they haven't been protected by the same secret keyword pattern.
When the attacker gains knowledge about just a nickname/loginname/id held by
the victim to access a heavier protected information system using changeable
password interface (an online bank, business/service online account) it
could be all he needs to compromise the account. Afterall, he knows already
that the person used same password at least twice so it's quite possible he
or she could have used its combination pretty everywhere, isn't it? It is
good however to hear voices of security aware internet forum users
consciously admitting to separate their common passwords into few different
pattern groups: one for home/local computer accounts, another for private
email accounts and finally a different one for most critical accounts, the
ones provided by the office/service and the online financial services.
Additionally it would be a wise practice to try not to connect ANY email
account, either private or business, by the same password pattern coherence.
After all, you can never tell much about the security of the particular web
portal you are about to register a new account in. After inputing your
contact email address needed by the particular service registration process
it is crucial to use a completely different secret word / password scheme
than the one protecting your mailbox. You will sleep better, knowing that
after any possible database compromise in future this will be the first and
the last point the attacker could get while trying to progress in the attack
using information you provided upon the registration.
A good place for an attacker looking for email hijacking/cracking targets
could be job seeker portal databases designed for active as well as retired
military and government service workers. These systems are most often filled
with a highly sensitive information, including SSN numbers bound to detailed
personal info, business email addresses, client provided password/secret
sequences and also officer service performance reports. In fact, this kind
of data make a best suitable target for rather politicaly motivated
entities, producing in turn a cyberterror/cyberwarfare based threat to a
particular government organization or country, than just an another easy
prey for a common electronic fraud criminal.
Looking at the whole case through the attacker's eyes, you could actually
try to make a comparison that a particular vulnerable job portal database is
much similar to a bottle of wine... :)
After penetration has been made, all the compromised email boxes lie opened
on the intruders table. A particular victim that has registered its account
on job portal - after getting the first job / switching it to a better one -
usually advances with its experience and knowledge, leaving however the job
portal account not updated or even sometimes forgets about it. Additionaly,
while the email given in the online registration at the portal is usually
the same email address the victim contacted recruitment office of the new
job - the attacker can easily identify the new victims occupation as well as
any email message forwarded by the victim itself between an old email
address (the portal registered one) and a new business email address. But
since the victim advanced - its personal info importance as well as
professional competency along with scope of digital access have gained on
value - just as an old wine in the 'insecurity basement'. Finaly, right
after opening the bottle, an intruder by simply linking the facts can
"learn" the victim from its correspondence stored on differnet subsequently
opened business/private mailboxes sharing the same password pattern.
Accessing more critical infrastructure accounts belonging to an attacker -
by using either known password pattern bruteforcing or "forgotten password"
reminder services - an attacker can compromise the victim's multiple company
business accounts, reflecting a victim's career path.
An example of Bot pentested job portal system may reveal a little bit the
magnitude of possible compromise impact. A portal - designed by a US based
company explicitly for a retired military and law enforcement officers
looking for a job in a higher (secret/top secret) security clearance
requiring civillian companies - was identified by the Bot to contain an
exploitable server side flaw within the "New Account Registration"
interface. Most users registered there hold or used to hold a military
related career path ending with an officer rank. Often they also hold the TS
security clearance level. The runtime code managed to auto-identify and dump
the email/password combo records within the database (provided at
registrtion by the account owners) and passed them to the bot's segment-3
for further automated password/email matching and mailboxes message contents
Among any other penetrable accounts, it was able to gain access to US Army
Lt Col's private Hotmail mailbox.
While holding a "Top Secret" clearance, his last occupation - according to a
detailed unclassified CV stored within the mailbox - was a position of
Branch Chief in the U.S. Defence Inteligence Agency (DIA). You could ask now
of course why a guy holding a security crucial position like this, did use
the same password pattern more than once.
But that's not the point. Everybody uses a password pattern of some kind
just as everybody has a weak memory (especially me).
There are better questions however: why didn't he deleted the message sent
to him by the US Embassy in Paris, containing information on a 6 day
'Ambassador' hotel reservation, that included highly sensitive detailed
payment information. The data within the embassy's message contained a still
valid VISA credit card details used during room payment before the
particular European NATO event, ie. a full 14 digit credit card number, its
expiration date and what's most weird: the sensitive 3 digit security code
(CVV2) needed for any online payment authorization. Much better question
would be: why did the Embassy sent such a sensitive information via an
email, especialy on a private Hotmail account?
And that's just one example.
Out of about 30 thousand stored mail address/password combos on this portal
database, out of 800+ different other db_name()'s stored on the particular
MSSql server and accessible through the flawed ASP interface using the
shared DB user account, out of about 29 different recruitment companies
whoose web systems were found vulnerable to database injection attacks by
the Bot so far.
You do the math...
12. Second Stage Attack Impact And Propagation.
The mailbox credentials matching attack vector, after just few weeks of
play, became one of the primary subjects of the research. It has been
implemented as bot's Segment-3. The attack vector, employed by S1, S2 and S3
bot segments bound all together, was called for naming purposes simply:
'SIDECAM' (SQL Injection Driven Email Credentials Active Matching).
In theory, after compromising the victim's mailbox password, a malicious
attacker may follow different attack propagation paths, depending strictly
on his goals - being either purely chaotic/destructive, financial or
politically motivated. Just as the motives behind the attack may differ -
the final impact of the SIDECAM based final stage compromise may also vary,
ranging from a sensitive information leak, up to different machine
compromise, ending with secure intranet infrastructure penetration.
The impact of the final 'SIDECAM' attack stage alone (S3) is in fact the
impact of a successful password compromise attack against a particular email
box, either private, business or government provided.
Before launching S3, the gathered Email/Pw pairs were checked against
password frequency. 40 most frequent passwords (ie: passwords harvested by
S2 - NOT the passwords indentified as matching their corresponding email
addreses by S3), within gathered 150K base, sorted by descending frequency,
When Bot's S3 was able to go operational (after S2 provided it with enough
mail credential pairs) it processed first exactly 16344 email/password pairs
(out of 151595 gathered totally by S2 during its first few week runtime).
The S3 was configured to target only specific free mail provider accounts:
Hotmail, Msn, Gmail, AOL, Verizon, Comcast and EarthLink.
After reaching 16344 processed mailbox credential pairs (ie: ones belonging
to the preconfigured provider pool list), Segment-3 was shut down. It
matched positively exactly 3127 pairs (ie: ones for which the particular
password was successfully opening its corresponding email account, accepted
either by providers POP3/IMAP4 mail server or through S3 implemented HTTP/S
webmail login interface parametric proxy).
The final "password reusage factor" (PRF), visualizing level of universal
password usage among the internet users, oscillated through runtime around
0.15 - 0.24 (shortly speaking: aprroximately 1 on every 4-5 processed email
owners use the same password scheme for its digital, password protected
accounts). Then, it should be also mentioned, the PRF's oscilation amplitude
through the runtime depended at most on 2 factors: the type of the system
(its infrastructure criticality level, expressed directly in the trust that
the users have to the system) and the age of the particular S2 compromised
system (the age of the most recent account created).
The reasoning behind the second factor is rather obvious - for a 10 year old
portal / web system account we have far lower probability to that the Em/Pw
combo will still match (it is more probable that the the password has been
already changed after a compromise (or as a result of users security
awareness increase) or the account was abandoned / deleted).
The first factor expressed itself most evidently in the case of the
vulnearable U.S. Department of Justice system. The users here were in most
US Gov officials, being usually a law enforcement workers. The highest PRF
factor (around 0.24) was noted in this particular systems case - the highest
number of Em/Pw combos were found matching by the S3.
Later, apart the free-email-provider S3 runtime, a different S3 test case
was executed (one, targetting non-free gov provided email account passw
matching). It resulted accessing multiple email accounts, belonging in most
to PD officers and Sherrif Dept officers. It's unclear however what was the
true factor behind the numbers in this particular system case - whether they
were a result of some kind of "reckless distance" a gov worker has to its
job ("I don't need to care for every single digital account gov gave me,
until it's not my bank account") - which however, in this specific systems
case (DoJ) would be somehow ironic - or rather completely the opposite:
"while I'm registering the account and entrusting my personal ID and
password in the hand of gov department that handles peoples security, how
would it possibly be unsafe and opened to a compromise? - ie: my universal
password is safe here."
Finally, the runtime results were corelated and compared, showing PRF
factors for each separate email provider.
ProcessedHotmail = 7070
ProcessedMsn = 792
ProcessedGmail = 3750
ProcessedAOL = 2625
ProcessedVerizon = 308
ProcessedComcast = 996
PositiveHotmail = 1664
PositiveMsn = 184
PositiveGmail = 386
PositiveAol = 490
PositiveVerizon = 45
PositiveComcast = 189
HotmailPosFactor = 0.23
MsnPosFactor = 0.23
GmailPosFactor = 0.10
AolPosFactor = 0.18
VerizonPosFactor = 0.14
ComcastPosFactor = 0.18
Although in my opinion EXTREME CAUTION should be taken before drawing any
real conclusions based on theese numbers, there is at least one thing
drawing attention: over twice as much statistical users with positive
password reusage match for Hotmail and Msn (while treated as two different
test groups, amazingly, they resulted with the same, highest PRF factor,
both being corelated by their mutual service provider, ie. Microsoft) as
statistical Gmail users with positive password reusage match.
There are also questions concerning reasoning behind some protections,
either security or commercial based, implemented by particular email
providers. Gmail and Hotmail, for this example, have well implemented
captcha solution, to verify if the following mailbox auth attempts are
driven by human (ie: from security reasons). However, if one chooses a POP3
protocol based mail synchronization, free accessible there for anyone, he
can easily execute an automated robot code.
In the Yahoo! Mail case, we deal with an opposite situation - since there is
no free POP3 mail server available to Yahoo Mail free service users, just a
commercial solution called "Yahoo! Mail Plus", there is no easy way to
complete an automated POP3 driven password match (when we try and use a POP3
mail server using particular free-mail Em/Pw pair we will result with
AUTH-FAILED error, just as the account/password given wouldn't match -
however when accessed through a yahoo's webmail interface - we could be able
to log-in successfuly). Since the Yahoo Webmail interface doesn't implement
any captchas, one could easily execute an automated credential matching code
just by implementing a HTTPS webmail proxy wrapper.
The second part of this section was focused on the successful SIDECAM attack
propagation - what could happen AFTER the hostile succeeded with breaching
our mailbox. Since the further exploitation paths, succeeding unauthorized
email access, are limited just by an attacker's imagination, we could give a
try and sketch few most probable courses of action for a hypothetic
The very first thing an arbitrary attacker would probably do after breaching
the victim's mailbox is enumeration of any other accounts and systems that
the victim has the access to. One good way to do this would be simply using
the webmail 'message search' features and looking of any message containing
words 'password', 'account' or 'login' - theese emails will either contain
different system registration confirmation credentials, password reminder
data or any additionaly details revealing the existence or other electronic
accounts belonging to the victim (social portals, job portals, business or
service restricted systems, web admins / web developers FTP credentials,
After enumeration of the less critical, low security system accounts (the
ones which credentials were either already stored wihin the mailbox or could
have been retrieved successfuly using just their login/id and apriopriate
send-password remider services), the attacker may focus on stronger
protected system accounts, like online banking accounts and electronic money
Lets look at the facts here.
Todays well designed financial assets operations system is a fortress. Or
should we rather say: it is meant to be a fortress. Most probably, it would
be one, if both - its defense system operators and its clients - were
In the real world however the security of a particular fincial's system
client depends STRICTLY on his security threat awarness and - what's far
more important - on the threat imagination he managed to develope.
Lets take a look for example at a common, well secured online account,
facing a possible related email's credentials compromise. The particular
online bank provide the account's owner with brute force attempt
protections, newer allow to send any sensitive data to related email address
(so the attacker couldn't just simply "email-remind" the account's
credentials), employes 2- or 3-level password authentication mechanisms,
separately for cash and non-cash operations (including one-time passwords
and SMS transaction authorization) and finally harden the password
forgotten/reset operations with different ID information challenge-response
But as usual, there is one tiny issue in the whole case - no matter how hard
a security specialists would try, we are just humans - not robots.
Quite often the ammount of ID data embeded within correspondence and
different sensitive documents found after Bot's reconaissance done on a
particular mailbox was all the intel the malicious attacker would need to
perform the bank account password reset. SSN numbers, DoB's, addresses,
phone numbers, detailed health and service reports, even a secret
question/answer (universal as well) combo - could have be found on the
victims mailbox and through it - either within sent and saved CV documents,
detailed cover letters, business correspondence or the account
configuration. Also the SMS authorization services can be diverted (by
resetting/changing SMS number), using the info the attacker could have
acquired after the mailbox breach.
Finally, what could have been "noticed" during the research, in different
cases the particular person used its universal password sometimes four times
and more, in different places (including the email password), in one or
another form (often concatenating with a number '1' to meet the particular
password policy's requirements) - so it wasn't also much surprising to find
that in few cases the very same password protecting mailbox was also
protecting the particular user's online bank account.
Most surprising however, instead of all the warnings from the banks
correspondence disclaimers, was to find at user's mailbox a self-forwarded
message containing either partial or full credentials (UserID/Pw) to access
a particular web bank account. Even better: one particular person have made
an email folder named 'my passwords', where he did stored all the "needful"
sensitive info, including Paypal IDs and aviation portal / systems accounts
(he was a pilot). It seems that the one thing distinguishing a human from a
robot is most definitely a weak memory.
The easiest (but less subtle) action an attacker could perform is email
account hijacking (changing its password, secret question and answer).
Although it's probably the last thing to do if one wants to keep the
account's credentials compromise undetected for as long as possible, it
could make a successful tool for further blackmail and extortion attacks.
Finally lets not forget about the spam robots and automated email spoofing.
I agree: remote machine hijacking, using malware and exploitation of the
physical access to victim's email account data along with its contacts
stored within the host machine email client - is one of the most often ways
for spammers to obtain both: spam zombie robots and a valid email account
credentials. But I guess not the only one.
Accounts compromised after an automated SIDECAM attack can make as well an
effective fuel for any kind of spammers.
Browsing through a compromised's sherrif department mailbox belonging to a
IT Division Chief (after completed SIDECAM phase on the mentioned earlier
one of vulnerable Department of Justice systems), I've spotted a message
describing a recent incident involving spam being sent from one of sheriff's
dept email accounts. It cautioned the SD's users ONLY for rechecking proper
AV settings when operating from home machines. However if the leak source
was not the malware infection of the government worker home machine, but a
similar SIDECAM-like attack on DoJ - reinstalling an AV or even setting up a
new clean version of OS wouldn't make a difference for the attacker who
targeted the particular sheriff's department account through the attack, as
the source of the email credentials compromise was both: the leaky DoJ
system and the password reusage vulnerability.
The previous example introduces second, far more interesting group of
attacker's courses of action, involving social engineering mechanisms and -
unlike the spambots - targetting precise, high value targets (chosen by a
specific profile attacker, being for example financialy or politicaly
Since this type of attack to be successful requires from an attacker a
proper study of the victim's profile (by using for example the info gathered
from its correspondence and social portal accounts), it cannot be automated
(I mean: at least until 2029 you will need a human to deceive a human :)
Lets focus at start on an attack employing spoofing of identity of
compromised email's account owner (lets call him: "victim1") and targetting
specific person ("victim2") from the breached mailbox's contacts list.
A hypothetic attacker, after checking victim1's contacts (by either
analysing mailbox contents downloaded using POP3/IMAP or simply accessing
the contacts list using the particular webmail interface) will begin with
building a personal identity pattern for the victim2 including every piece
of info he could found: what he/she likes, which web type of sites it visits
(has accounts in), current and previous occupation, interests/preferences,
what kind of information is exchanged between contact and mailbox owner,
what is the highest priority matter to victim2 at the moment, and so on.
Following that, an email must be forged employing stolen identity intel,
containing as much personal data as possible to render the message credible.
The attacker's goal will be to urge the remote mailbox owner (victim2) to
response "positively" (according to the attackers objectives), either by:
- visiting attacker controlled web site hosting malicious remote attack
- launch attached script/binary,
- reveal a sensitive information.
The possible impact of such attack is obviously compromise of victim2's
client machine and sensitive information access.
A specific mutation of this attack vector, not demanding from the attacker
however execution a successful password matching SIDECAM attack, could be
exploited in so called "spear phishing" scheme. It involves a phishing
attack with one major difference to common phishing - the fact that the
attacker already knows that the owner of every email address within a
spammed list is in possession of the account in the particular system
(social portal, online banking system, particular corporation's employee
restricted system), account that the attacker is interested of. After
properly researching the targeted organization the attacker will target the
precise account type.
Note, that this attack may be launched by an arbitrary attacker after any
successful database email records harvest, especialy when neither Login nor
Password data could have been retrieved successfuly by the attacker (were
properly one-way encrypted for example) and just bare email list and maybe
some basic ID data was retrieved (like name, phone or address) - this kind
of data is all the attacker needs to forge a trustworthy, credible message
pattern and execute a spear phishing attack, targetting for example
Login/Pwd account combos of the particular system.
Another kind of possible email breach exploitation (either SIDECAM based or
not) would be inverted (in reference to previous example) identity spoofing,
ie. the case when the attacker while spoofing some other email identity (for
example one of victim1's contacts - ie. victim2 in the previous example)
sends a spoofed message to a controlled (breached) victim1's mailbox,
exploititng the intel gathered so far through the victim1's email access.
After forging a credible, detailed message, an attacker can execute social
portal credentials phishing, bank account phishing, aim for victim1's
sensitive data (ID data/business secrets/service related confidetial data),
spoofing victim1's company representives (anyone with high enough rank,
found in contacts or by email analysis) or execute remote execution attack
by sending malware of any kind the mailbox server operator won't filter out
(executable / document embeded 0day) authenticating the message with intel
gathered so far on either victim1 or its spoofed contact, victim2.
Possible impact: compromise of breached mailbox owner's machine (victim1's).
A specific subtype of the above attack type would be the "active
conversation interception". In this scenario an attacker, basing on the
mailbox event tracking (analysing any newly opened conversations, awaiting
answers to victim's question/topic) will try to intercept
(detect/read/delete) any possibly high priority message (answer awaited by
the mailbox owner - victim1) forging and sending a spoofed message inducing
victim1 to either share sensitive information or reponse by executing
(opening) a malware (exploit) attachment. The more is the conversation
valued to the victim - the higher the probability of successful attack.
Most expected to be exploited using this kind of attack would be for example
resume (CV/cover letters) sent to a remote company and awaiting response,
conversations with old colegues and family members (but only those for whoom
this (email) is the only way of communication with victim), a job offer from
registered job portal (since its most probable the attacker will gain access
to the job portal using already known victim1's universal password - he will
also be able to monitor any events within the victim1's job portal profile,
so any messages FROM the portal after profile updates can be expected high
priority to victim1), etc.
Another example would be execution of ID phishing attack, spoofing any
actively (currently) used job portal mail account, with message containing
link to an attacker controlled ID-data-phishing web site and requiring
additional, sensitive ID data (service reports / current job involved
projects / etc) giving false impression of having possibly attractive and
available job offer.
Certain mutation of that attack scenario would be a phishing attack
targetting credit card data.
After noticing that the victim has a credit card in his possession and
recently used it in any online shop (by looking for any possible shop's
response email messages on victim's mailbox containing succesful purchase
notification), after interception of the message (deletion) an attacker can
begin a phishing attack and imitate a shop's CC data update website, similar
to one that the user has previously registered his card in, requesting CC
data update, motivating the operation with ex: security reasons and victim's
shop account validation.
The last interesting way to exploit the unauthorised email account access
that I've came across during the project was self forwarded attachment
The idea appeared after accessing an email account belonging to a Victoria
Police Department computer forensics detective. Among investingation
reports, forensic software FTP account data, and other, service related
messages, my attention dragged a recently self forwarded message containing
a zipped instalation version of a cell phone forensics software.
While the only reason of forwarding the installation binary to myself (it
happened to me few times) is to be able to quickly setup the software on a
clean machine in new place with just the internet connection - there was a
quite reasonable assumption that the file would be used (remote executed) in
the nearest future.
An attacker could exploit that fact and after replacing the recent message
with one containing altered attachement, ie: the same software installer
combined with a trojan code.
The resulting impact would be compromise of any machine that the victim1's
would install the attached program on.
Apart the particular example, any properly conducted, sophisticated social
engineering attack exploiting a compromised police department email account
may also result with infection and further penetration of police department
secure intranet system.
Note: spoofing driven attacks may most likely after relatively short time
trigger a response message from the target to person which identity has been
spoofed, with questions about the suspicious message (assuming only that the
person is highly aware of common security threats), which in turn will
result in uncovering of the attack, and most likely of the mailbox
compromise as well, triggering further actions by the victim such as
compromised machine cleanup. Therefore attackers time-window to utilize
compromised system will be relatively small.
Lets also not forget that a properly designed, EXTERNALY (internet)
accessible webmail interface should provide every account holder with
mailbox login-event IP/Date tracking features, accounting at least few
previous logins, (Gmail would be one good example of such proper
On the other hand - finding the "source" (eg: a particular credential
information leak source) of victim's mailbox password compromise is a
After the problem has been signaled, even if one can assume the compromise
source was SIDECAM-like attack, it would be hard to point out quickly a
precise system that after being successfully attacked using SQL Injection
(or any other data-targeted attack) has become the source of the sensitive
information leak. The particular victim could hold many accounts in
different systems - systems that could be old enough to hold multiple,
different type vulnerabilities.
The affected person might have also forgotten about some of the system
accounts long time ago (it happened to me few times actually), accounts that
are still active, or even hadn't been logged into once, trespassing theese
systems just to "check&leave" there his most precious sensitive information
(universal password for example). After some of more critical system
accounts are compromised it may be sometimes practicaly impossible to track
the origins of the particular victim's password data leak.
I should mention at the end, that all the presented attack patterns above,
belonging to the second group of attacks (attacks involving social
engineering) are THEORETIC SCHEMES ONLY, and haven't been executed by me in
any real situation during project time.
13. Teaching a robot how to "value" its victim.
Since the 'SIDECAM' attack vector is an example of a randomized-victim
attack type, to gain most valuable results, an attacker must focus on
creating a proper parametrization of its code: he must design it in such
way, it could target ALONE, elasticaly described, most valuable critical
This is all the game of probability and time.
For the SIDECAM attack vector, the point is to generate (for example) google
search query patterns derived from easily enough configurable regular
expressions, describing internet system interfaces like for example job
portals, retired officer portals or any social web application systems
provided for critical infrastructure workers - the places where most
experienced people stored willingly their email/password data, unaware of
The strength of this attack vector (assuming a randomized-target attacker),
is based on the access level given to an attacker by the sensitive data he
can obtain afterwards, using all the intel and credentials gathered after
breaching the particular victim mailbox. The more sophisticated victims
occupation / higher security clearance / more experienced person - the
bigger the final attack impact.
Probability works fine in real - after stumbling for few days upon a
different US .gov domain systems, the bot identified a vulnerable Texas'
Department of Justice database system developed to support a different US
DoJ workers with criminal backgroud checking service. The vulnerability
existed in a 'password reminder' interface. As it could have been predicted,
most of the registered users there were law enforcement services workers. A
30000+ user account records MSSQL database were then enumerated and
selective-dumped, targetting auto-identified login/password/email records.
The final scanning stage was the segment-3's job. It performed automated
password validity matching for the selected email/password combos.
The major part of the DoJ's system accounts were registered by the law
enforcement representatives, that presented their official gov-provided mail
account addresses upon the registration. Now, since most of the properly
designed government and military information systems should provide access
to an email services ONLY from machines belonging to an internal institution
network (intranet), it is impossible to connect to their login interfaces
"from outside" or without presenting a valid VPN/HTTPS certificate issued by
the CA either for the precise user's machine and secured localy by MS's
DataProtection API or carried by the user on his/her smartcard.
But again: 'most' doesn't make 'every' :)
Relaying again on our new best friends - probability and automation - all we
need is to properly identify whether a particular mail gov-domain support
some external POP3/IMAP server or if it provides any external webmail
interface. The most often used HTTP/S mail domain prefixes/suffixes found
were: 'mail','webmail', ,exchange', 'owa' and 'email'.
The results that came up after a day of work or so, were lets say, at least
somewhat unexpected. Several police department and sheriff's department
email accounts were matched as accessible (DoJ system presented password was
reused). The email accounts were provided by either US or Canada government
and included: a deputy sheriff detective, police dispatchers, a computer
forensics detective, narcotics division detective and information technology
14. Passwords, secrets and the pain of hashing.
Every 9 on 10 systems that were found vulnerable to ASP/MsSQL SQLi attack by
the Bot, while holding some form of user password, did not encode the
sensitive values or hash them in any way, storing them in a plaintext, using
either 'varchar' or 'nvarchar' SQL type fields.
Less than 5% of compromised systems just encoded sensitive information,
using mime64 algorithm in most cases, rendering sensitive data easily
reversible after the DB attack. It was really nice to find manualy once a
time a secure websystem welcoming the user on the 'new account submission'
page with message like this:
"For security reasons, your password is stored in an encrypted state in our
database, which prevents the system (or anyone else) from reverse generating
The only way to protect a user provided sensitive data - not only from
remote attackers, but also from the malicious insiders - is to use strong
enough, one way, collision resistant encryption algorithm, commonly known as
hash function. Using up to date hash methods (like SHA-2 for example)
protects the user before any sensitive data leak, caused wheather by a
remote intruder breach, authorized employee malicious action or accidental
Probably the most obvious reason behind this "pain of hashing" reflecting
the numbers, is the kindness and generousity of corporation's programmers to
support lost users with the extraordinarily powerful feature of password
I can not speak of if "password reminder" option is simply GOOD or BAD -
it's not black or white.
But this is a bad policy.
The only thing I could speak of, to be objective, is that the option
implemented for the "users good" is far less secure than its completely
reasonable alternative - password reset feature. At first - user password
plaintext data may be harvested (and decoded) as a result of SQL Injection
compromise of the vulnearble corporations database. Secondly - the password
may be intercepted/retrieved by any attacker who gained access to victm's
email account credentials (exploititng for example a successful SIDECAM
attack result data). And finally - after breaching a users mailbox account,
attacker can exploit "password reminder" features of ANY particular system
that the victim has been registered to and take control of the accounts.
The existence of a password reminders service is in fact a real evidence
(and the only one the attacker would need) for that the web application
doesn't use any type of sensitive data (password) hashing but stores the
data as a plaintext (since for the properly constructed hashing algorithm
there is no (mathematic) way to "recover" the hash operation input argument
from the result value).
Going further - in my opinion, at no point to be honest, should be a user
given the option to provide the remote, critical assets system (like an
online banking or a official government mailboxes) with ITS OWN password,
neither during account registration nor at password reset operation. We are
just humans and human doesn't execute every single policy given, as robot
does with the scripting code. The password may be to short, it may lack of
randomness (be vulnerable to brute-force attack) and most of all - after
possible compromise of the database system it may reveal to much information
about the "cryptographic inner" of the user. Very short, dictionary based,
character only password would for example indicate either users's
recklessness or his unawareness of security threats.
Lets take a real life password example: 'susan1'.
The password has been found to be matching the coresponding email address,
using SIDECAM attack vector by S3. The password indicates 3 things: first,
that owner likes susan :) second that most likely he is a male and finally
most important to an attacker - that (in this specific example) he
intentionally concatenated word 'susan' with number '1' without being told
to do so by the remote system (the particular system's password policy
(email portal) didn't enforced the user to use numbers or special
characters) which leads us to a conclusion that the user is:
1. Aware of the password complexity attacks and could have used the hybrid
password to protect one of his more critical assets ie. his mailbox.
2. Uses still approximately short password most probably to easily memorize
That all together indicates that the user's "security fraze pattern" was
used to lock his "things" in more than just one place and it could to be
expected (with a reasonable probability) a combination of word 'susan' and a
digit most likely ranging between 1-5.
After about an hour of getting known the user better while talking with
susan1, 2 other accounts could have been accessed - user's second mailbox
password was pattern-bruteforced and verified to be also the keyword
'susan1' and the online bank account used (first level of authentication
only / non-cash operations) by the user was identified to be protected by
the password 'susan3'.
Another real life example - a Mensa Poland member's emailbox, accessed by
the Bot was noticed to be protected by the password 'dupa' (meaning: 'ass',
in Polish language). The conclusion here however was slightly more
difficoult than in the previous example. The best I could have came up with
was: the higher the IQ the stranger the password is ...
Definitely the most ironic case however was the AOL's user, who had chosen
to protect her electronic accounts (including the one within a buggy, SQLi
targeted portal) along with her AOL email account all together using the
same password: 'idiot1'.
The unencrypted password records stored at the vulnerable database should
not be considered afterall as the most critical user's asset to be
protected. Giving the Bot's gathered system examples, many of them contained
other sensitive data type stored in plaintext - secret questions and
Analysing SIDECAM opened mailboxes, an attacker already knows that the user
used the single well memorized password in at least two different places.
With a reasonable assumption that the mailbox owner uses also similar
"secret question" / "answer" strings for stronger protected systems and with
the help of additional personal information like DoBs, addresses, phones or
even SSN numbers stored within victims mailbox documents (CVs attached to
job emails are true personal information mines) - an intruder can try to
conduct a successful attack against strong protected victim's accounts that
the attacker is already aware of, after study of the victim.
15. Parametric Data Objectives.
To be able to "tell" the bot which type of data within every penetrated
database system we are interested in and which is unimportatnt, a simple
mechanism has been implemented to describe it - "Parametric Data
Objectives". The idea is to bind the public parts of the targeted data with
its corresponding private values. For example if we'd like to tell the bot
to look for any ID Data containing specific secret element (say a SSN
number) we describe it defining a list of string-patterns both for the
public and private part. We define a DOP scheme by NAME and then describe
the lists of Key and SubKey strings to follow this pattern (ie: contain one
of the Key/SubKey words)
Example from config:
Key = ssn ss_n ssan social_security socialsecurity
SubKey = email name tel addr phone dob year ammount number date time code
The whole idea is that data keys must be bound to at least one subkey -
without it accessed data has no value for a particular attacker. Lets say we
are interested in any table containing Password/Email columns - we need to
tell the code how a login column name could look like and moreover - what
different column should it be bound to to, to be valuable. Therefore even if
the robot manage to find the email records within the penetrated system, but
can not match them with corresponding passwords values (cannot locate
related password column by either name or contents matching) or secret
data - it is useless to him as long as it employs SIDECAM vector only (seeks
for automated email account breaching).
For an attacker, there is however a different possible area to exploit
separate email address records, not bound to plaintext passwords: Spear
Utilizing SQL Injection attack vector as the first stage of a Spear Phishing
attack is in fact a book example.
Despite the mechanism to describe the "priority data" pattern (DOP at Bot's
Segment-2), there was also second pattern-description-mechanism developed
(at Seg-2) to parametrically define the most crititcal systems (like
military, gov, financial, health, energy, IT, etc.) within which to search
vulnerabilities for and to distinguish them from less critical
16. Robot Hits His Postgrade Education.
Before the next Bot's version, that implemented additional solutions like
Data Objective Patterns could have been launched it needed a proper training
of course :)
However it was a month or two already since the last bot's live
reconnaissance and "hunt" for vulnerable systems, so I've figured out that
it was a great time to find out how much of database systems initialy
matched as vulnerable have been already patched (without, obviously,
noticing the company/organization about the fact of vulnerability existence
in any formal way).
The first thing I've done was to setup DOP to harvest every
login/email/password triplet recognized as well as any personal ID data
(address, phone, DOB, etc.) bound to SSN numbers.
Then I cleared the 'done' flag for the same security / private investigation
company mentioned earlier (the one the second Bot's version utilized as
training ground for the automated penetration testing) and launched the
Basing on the output data gathered by the previous version of Bot the
company database held about 30 employee records containing private SSN/ID
data and few houndred of client records with email/password/login combos, so
the new bot's automation should have performed successfuly without any human
supervision, recognizing these data entries as matching against configured
DOPs, performing an automated data harvest.
But it didn't...
The penetration stopped at the vulnerablility matching procedure - it seemed
that the company have patched the hole.
Anyway - since an automated code's console printout is not enough to confirm
if the hole in my favourite security training :) company indeed have been
patched (I could simply have made ton of bugs in the new bot's code, so it
could just be malfunctioning) - I needed to check it myself using an
oldschool script-kiddie ninja techniques. It came out the vulnerable Html
FORM indeed have been fixed, but since the Bot doesn't have implemented any
sense-of-humour recognition algorithms (yet...) it obviously missed one
precious detail of the company's patch.
Previously, if the user would have forgotten his credentials for example,
the login interface would warn him, using big red font, that "The provided
password is incorrrect". Now, the fix for the SQLi bug consisted entirely of
writing an input parsing procedure that checked if the user input data
contained either 'select' or 'union' SQL words (the words that were SQL
injected a month ago into the very same database something like 5 times a
second, for about few days while "training" the bot). The stunning part was
the coded-in response of ASP programmers for the recognized SQL word
patterns. After using either "select" or "union" keywords in the
Login/Password fields, right in the place of common incorrect-password
warning message, with the same big red font, we were given now a big red:
Well... I guess if no other automated penetration bot trespassed the
company's database area last month - it was quite probable that this message
was meant explicitly for the Bot.
The second, disturbing part of the case was the fix itself. Althought in
fact the faulty 'customer login' interface has been patched, it took about
60secs to find another penetration entrypoint - vulnerable 'password
forgotten' FORM. After redirecting the Bot to the new entrypoint it
harvested all the DOP configured data successfuly, while taking it to heart
to "go away" from the 'Customer Login' interface, and to never, ever, use
this entrypoint again while penetrating this particular system.
Some time later, I did try to analyse a random group of previously
penetrated and vuln-matched systems selected from the Bot's printouts. It
seems that approximately 8 out of 10 database systems that 3-6 months
earlier had been scanned, penetrated and data-harvested either did not fix
the hole, fixed it inproperly or didn't take an effort of wide-scanning
whole web app for other similar attack vector vulnerabilities.
Since NONE of the Bot penetrated system owners were ever informed about the
successful/unsuccessful compromise attempt of their systems, these numbers
would only indicate that either intrusion detection infrastucture or
incident response procedures in the penetrated institutions leave a great
deal to be desired.
A very similar example, to one in security training corp's case, was an
Australian telecomunication company system providing commercial anonymous
SMS services. Identified over 6 months earlier as vulnerable by the first
version of bot and opened for client sensitive information theft as well as
client SMS credit limit manipulation / SMS service exploitation, it was
completely rebuilt now (it had that whole new, sharp-looking graphic
design). Entire web page frontend style was changed and the SQL Injection
hole within the 'Logon' interface has been properly patched. However, just
as in the previous case the 'Password Reminder' service was left with the
very same kind of ASP based SQLi hole that the 'Logon' interface contained
before, opening back the whole database system for R/W access.
It could only suggest again that the whole attack vector case based on SQL
Injection may be sometimes either wrongly understood by the web application
developers, or based too much on shortsighted "how to hack web apps in
60secs" tutorials (defining methods how to crack a system, not how to
protect from being cracked), that sometimes could, in fact, be understood in
the way: "If you secure properly just your ASP web application's LOGON
interface then you are all secure against any SQL Injection, because ASP SQL
Injection <IS> just login based".
17. Enumerating Penetration Entrypoints
One of main goals of the research was to establish the numbers behind every
particular victim-pattern, using different, automated, search engine query
generators. Three generators were constructed, respectively for standard,
long time exploited 'Login' interface, then 'Forget Password' interface and
finaly 'User Registration' interface.
The Bot gathered data analysis shows approximately low positive counts
(target web systems matched as vulnerable) for the plain "login.asp"
tutorials-case-pattern, higher for patterns like "logon.asp", "log_in.asp",
"signin.asp", "log_me_in_god_damnit.asp" or their permutations and finaly
the highest for "register.asp" and "forgotpassword.asp".
The last group - password reminder web interfaces - was for example
statisticaly the most successful way to compromise a government owned
There seems be at least two main reasons behind these numbers: kind of
misunderstanding of the nature of common SQL query execution and echo of
malicious "penetration storms" sweeping through the database systems for the
Well documented algorithms to search and quickly-exploit, like "login.asp"
googling and infamous "'or 1=1" sequence used as authorization bypass magic
word, might have been more actively used by script-kiddies and automated
scanning codes that followed that search pattern. After such
script-kiddie-conducted attacks (with usually malicious/destructive
purposes, but lower effort goals) the compromise effects were usually quick
noticable, rendering a rapid victim's reaction (detection/patching), as the
impact of the attack was either database contents alteration or destruction.
Therefore most of the systems following the tutorial-described patterns have
already their unfriendly pen-testing all behind and so the final positive
count in that group is statisticaly lower.
You could tell that most of programmers standing behind the systems
belonging to the critical infrastructure group are perfectly aware of the
Sqli attack threat as well as of its possible impact to a system. Many of
those systems that have been found vulnerable to the attack vector had well
employed validation for almost every submitted data field, having also some
sort of "scarecrow" for script-kiddies bonus addition, leaving however
unescaped properly one or two other substantial interfaces that employed a
client-to-server input flow. These unnoticed connections between the user
input and server-side command execution, left in different cases the
particular company's web infrastucture opened to penetration.
A quite funny coincidence happened shortly after the begin of testing of the
first query generator (the 'login' interface name permutation generator).
Bot's S1 logged by mistake a YouTube movie link, indicating that it matched
a '"login.asp"+video' potential HTTP system target pattern. Nothing
surprising there however, since the movie contained a tutorial to SQL
Injection driven MSSql server attack. The description of the video added by
the uploading user contained fraze "login.asp", therfore it has been indexed
by google robots and found by the Bot. Ironicaly however, the tutorial
instructed that there is no value in searching for the SQL Injection victim
to look for any other interfaces that system administration login frontends
as they are the only possible way to compromise the system. Since we already
know that the possible remote system SQL command execution may be triggered
at any server-side user input processing interface, obviously needless to be
admin-login portal or moreover to be login interface at all - this finding
of the Bot wasn't afterall a false-positive :)
The second most often place to find command injection vulnerabilities was
"user registration" interface. Web application programmer needs to implement
the comparison of the users provided application unique user identificator
(USERNAME/EMAIL/AgencyID) with the ones already exisiting in DB, and display
an error message if needed. Since the only possible way to do this is by
employing an SQL query, another possible entrypoint type was introduced into
the Bot's code.
A perfect example is one of U.S. Department of Agriculture (USDA) database
systems with well designed code employing illegal character filtering at
main login interface - even warning the user about any recognized SQL
But again - the User Registration interface designed for U.S. based
companies doesn't properly check its User ID field - the server side code
does not escaped the user's special character input before comparing the
proposed ID value with the ones already stored in database to check for
possible repetition - rendering the system exploitable through the attack.
An interesting different type of Sql Injection "pin-point" was spotted by an
accident during early phase of the research.
First version of the Bot have found a hole in major Polish commercial email
portal. Few hours after the system has been probed matching it vulnerable by
Bot's S2 and handed over to penetration worker-queue for further database
contents scanning and DB structure enumeration, the vulnerabiblity has been
patched. Unfortunately S2 didn't manage to gather any additional info about
the database structure and contents, because all its workers were busy at
After I've noticed that particular system penetration some time later while
analysing Bot's few days logs, together with a friend we decided to "check
out" if the company's programmers didn't miss anything...
After an hour or less my friend noticed (thx Sl4uGh7eR, btw) that
concatenating an apostroph with the '.asp' file name within the browser URL
will produce a HTTP 500 error containing our favourite MsSql 0x80040e14
syntax error. Now the only question remaining was why?
After quick investingation the case became quite clear - the remote server
application was employing mechanism to validate every client's HTTP file
request, coding it to match against database stored dynamic list of files
that a user is allowed to request.
Since such code needs obviously to match the filename requested by a
particular HTTP/GET against the ones stored within the database - it also
needs to execute somewhere a proper SQL query command containing client-side
provided URL string, that unescaped correctly is all the attacker needs.
And so the Bot gained another, third HTTP based SQL Injection pin-point type
implemented, aside HTTP/POST based Html FORM varialble fuzzing and HTTP/GET
But the the cat-mouse play continued. A week after the last friendly
pentesting the hole has been patched, missing again however the point on the
issue and enabling an intruder to perform successfuly a Blind Sql Injection
attack. For this project objectives was obviously not the ravage and server
take over - just a research, numbers and the attack vector mutation
possibilities (and lowering also a little my ignorance to SQL language) -
after implementing new vulnerability testing pinpoint type into the Bot I've
decided to close the case of the Polish hosting company.
It came back to me, however, quite quickly.
The first bot version which spotted the vulnerable company's system didn't
have implemented a crucial feature yet - enumeration of every OTHER
databases (not just the one that has been queried by the vulnerable ASP
script code) hosted at the DB server that could be accessed through the
vulnerable web interface.
The feature was implemented later in the last major Bot's version. During
the final month-long runtime it spotted a minor vulnerable website's
database, provided for Polish barbers industry. After enumerating all the
other accessible databases on that vulnerable MSSQL server using same
db-user account as for the barbers portal login interface, amazingly, it
came out that the server is the VERY SAME db-server belonging to the
previous major Polish hosting company, hosting 94 other R/W accessible
databases, including for example the biggest Polish international cycling
racing event website - "Tour De Pologne".
Since all the server hosted databases were aministrated and serviced by that
single hosting company, all of them were protected by the SAME db-user
account, rendering R/W accessible every database hosted there through that
single minor barber portal - including WWW/FTP customer account credential
database, company financial operations database (customer credit card data),
and so on.
It should be also mentioned - even if its too obvious - that SQL Injection
vector attack does not have to be even HTTP protocol based. Vulnerability
could be exploited connecting at any kind of user data entrypoint (protocol)
designed to transport the input to the remote client/server application for
final processing. No matter what happens, implementing proper 'processing'
of that input at server's side is the key to stay secure or to get
compromised in future.
18. Obscurity != Security
"If it runs, it can be broken" - every software protection cracker's
favourite fraze. It's quite simple actually - every locally runnable code is
reverse-engineerable and can be re-sculpted into anything else, limiting the
possibilities just to cracker's imagination.
The same rules applies to client-side-only web app protections and code
Interesting observation was made during the bot's runtime and afterwards -
analysing the vulnerable system entrypoints list. It seems that many of
heavier client-side protected web applications that has been in turn matched
as penetrable by the bot were either a government or military systems. And
to be clear: by "heavier" I meant here approximately higher ammount and
sophistication level for the code responsible for the CLIENT SIDE user input
For example, the second version of bot found and penetrated quite old but
still operational DoD owned system belonging to one of US Air Force
contrators - Lockhead Martin.The JScript code there employed really annoying
for an attacker, timer-based input validation protection. "Annoying" of
course for a human attacker with browser scripting turned on... :)
To try to disable the input validation timers manualy, using just for
example FireFox FireBug plugin would be a real pain in the ass, as the timer
validation procedures were embeded into different HTML tags and
cross-triggered each other causing the loss of FF's input focus after every
inproper character pressed (btw: huge applause for their programmers
From the bot's perspective however (ie: from its "handicapped"
robot-perspective), the whole JS code built by the system's programmers is
pretty irrelevant - just as the bot doesn't employ any JS engine to execute
the retrieved HTML scripts searching directly in the HTML and its subframes
for every submitable FORM tag - this validation code was simply an excessive
piece of HTML encoded text. After matching the system as positive against
SQL Injection, the bot built and stored the penetration entrypoint
description. Right after that, S2 successfuly penetrated it and dumped about
3K Email/Pwd/SSN record entries of US AirForce cadets and officers.
Every client side software protection providing input data validation can be
reversed and disabled.
Thus, the input filtering on the server side IS A MUST to be implemented in
any secure web app. Employing client-side FORM field data validation in
search for invalid characters - has no bigger value as a security mechanism.
Obviously, it serves very well as data syntax validity double check
mechanism as well as the first line of defense from annoying script-kiddies
(like me for example:) typing one magic injection word into every queried
google link looking for a single-hit "world domination" internet doors.
Using tools built for browser-side session data manipulation, like FireBug
plugin for FF or WebScarab http-proxy tool, one can quickly bypass
protections of this kind. Specifically, automated internet robots, using own
HTTP-payload processing, can do with the client side script code pretty
anything that bot's programmer wished them to do - ranging from validation
code autodetection up to selective execution.
On the other hand, one good way to stop a fully automated robot
(vulnerability probing robot) on his web-app crawling/scanning road would be
captcha implementation. Robot code behaves as blindfolded as only a machine
can. Of course business-time counsuming implementation of additional anti
robot functionality like this without focus on true bottom of the issue, ie.
the application security assessment, would be shortsighted. Obviously, while
captcha won't stop any human auditor conducting precise web-app pentesting
ordered by a customer company, it will definitely stop a robot from either
full enumeration of the web-app interface or progression with specific
interface fuzzing process.
Another interesting, yet still powerless protection facing an SQL Injection
vulnerability was an SMS based 2-factor web authentication solution,
implemented by one of Johanessburg based Colleges, which handled parent
authentication logon to the child education progress monitoring system.
Bot in its early second version tracked down the vulnerability, accessing
without any trouble sensitive ID data belonging to both students as well as
their parents (email/password combos, names, phones). Despiting a certain
threat of ID theft and mailbox hijacking by criminals, the SQL Injection can
be used here in a quicker way to manipulate the SMS phone number records to
gain unathorized access to the system.
The authentication implemented there had two steps.
At the first one parent was asked to provide its Parent_Code, ID_Number,
Email_Address and Password. Then, using the database stored (at
registration) phone number, server-side application sent a special security
code on that phone number and asked the user to enter the code at the second
logon screen, before giving him the access to the monitoring services.
Exploiting however the R/W access to a database records, a malicious entity
can easily change any particular parent phone number to the desired one,
redirecting in result the SMS containing the Security Code.
19. Learning new tricks from your own code
Shortly before the end of the final Bot's testing month, during some early
october morning it found an entrypoint into the vulnerable HP customer
support web database. Since the tool was running silently without my
supervision (the time of the initial system's vulnerability match followed
by an automated penetration was something like 4AM here in my country, while
I was sleeping deliciously), over a week has passed until I've decided to
look over the recent data gathered by the Bot.
When I've spotted the HP penetrated system's printout in tool's output logs
my attention was attracted by the list of databases stored on that DB
server. It contained Intel's, Amd's, HP's as well as about 20 other "bigger"
company customer databases. It seemed that the server belonged to some IT
outsourcing company which offered its customers DB-Server hosting services.
Unfortunately all I've had before me was the server's sub databases name
list and its structure - it seemed that the Bot didn't recognized any
potentialy "interesting" (DOP specified) data on the server (at the time it
was configured to look only for login/email/password combos) so it did not
"decide" to perform further data-harvest. Still, after quick human analysis,
it seemed that some of the accessible databases contained tables with column
names suggesting sensitive customer information. Obviously I must have done
a quick "manual" check to be sure :)
Launching web browser -> copy-pasting vulnerable system URL -> entering
manualy SQL query sequence into the input field enumerated earlier by the
Bot and ... here goes nothing. Ehmmm.
Has the system been patched already?
Well. Uhmmmmmm. OK.
Good for them.
The guys did their job well and patched the system after noticing Bot's
friendly "pentesting visit" last week.
So I thought...
First of all you must agree that the teaching-dependency-line linking the
programmer with his penetration testing robot is rather unidirectional :)
I mean, it is the coders duty to learn the code enough tricks he know in
order to create automated attack robot. In other words - the vulnerability
recognition errors are meant to be more like domain of machine - not the
human. So if you code a program telling him how to enumarate and penetrate
the system, then the code finds a system and says - "I've matched an
entrypoint to the database at web interface X" - and some time later you try
to access the database manualy at the very same entrypoint specified by the
code but nothing happens... the answer is obvious: the system has been
patched. Right ?
In other words: it couldn't have been you - the teacher - who made a mistake
validating the entrypoint's security, while all the tricks the code knows
are your tricks ... :)
But that was a system hosting databases of Intel, Amd and Cisco...
I mean, you just have to be sure to sleep well, if they didn't fix just one
particular entrypoint leaving another one unpatched. Quick checking all the
other input fields, password reminder interface, sumbmit new account
interface, website search interface - nope. Nothing. The vuln has been
So the last thing (but you could say - completely unnecessary - basing on
what has been said earlier) was to order the bot to target the system again
and repeat the penetration test from a week before. So, we launch the
config, clear the "pen-test-done" flag by the systems url entry and wake the
20091128125443 Initializing Ellipse 0.4.73 SEG-2
20091128125443 Cleaning up abandoned VlnConn targets...
20091128125505 Op mode: 0
20091128125505 Mutex ID: VLNDET-MTX-001
20091128125505 Entering MainLoop...
20091128125525 [ SYSTCH ] Connecting system at >>
20091128125525 [ SYSTCH ] http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
20091128125528 [ SEG2 ] Initializing Entrypoint Search...
20091128125528 [ SEG2 ] Entrypoint #1 found
20091128125528 [ VLNCONN ] Going processing level: 0x20
20091128125528 [ VLNCONN ] Running initial passive vuln detection...
20091128125534 [ VLNCONN ] Passive-Scan result: Negative
20091128125534 [ SEG2 ] Entrypoint #2 found
20091128125534 [ VLNCONN ] Running initial passive vuln detection...
20091128125538 [ VLNCONN ] Passive-Scan result: POSITIVE
20091128125538 [ VLNCONN ] Going processing level: 0x21
20091128125538 [ VLNCONN ] Running active vuln detection...
20091128125543 [ VLNCONN ] Scan result: POSITIVE
20091128125543 [ VLNCONN ] Going processing level: 0x25
20091128125543 [ VLNCONN ] Running primary query element scan...
20091128125543 [ VLNCONN ] BaseQuery column extracted:
20091128125556 [ VLNCONN ] Going processing level: 0x26
20091128125556 [ VLNCONN ] Validating query item count...
20091128125556 [ VLNCONN ] Validation Succeeded
20091128125556 [ VLNCONN ] Validating Mode2DatAccess...
20091128125557 [ VLNCONN ] Mode2DatAccess Enabled
20091128125557 [ VLNCONN ] Going processing level: 0x3A
20091128125557 [ VLNCONN ] Scanning global DB Names ...
20091128125557 [ VLNCONN ] DB #000: hp
20091128125558 [ VLNCONN ] Accessible
20091128125558 [ VLNCONN ] DB #001: master
20091128125558 [ VLNCONN ] Accessible
20091128125559 [ VLNCONN ] DB #002: tempdb
20091128125559 [ VLNCONN ] Accessible
20091128125600 [ VLNCONN ] DB #003: model
20091128125600 [ VLNCONN ] Accessible
20091128125601 [ VLNCONN ] DB #004: msdb
20091128125602 [ VLNCONN ] Accessible
20091128125602 [ VLNCONN ] DB #005: pubs
20091128125602 [ VLNCONN ] Accessible
20091128125603 [ VLNCONN ] DB #006: Northwind
20091128125603 [ VLNCONN ] Accessible
20091128125604 [ VLNCONN ] DB #007: intel_collateral
20091128125604 [ VLNCONN ] Accessible
20091128125605 [ VLNCONN ] DB #008: vishay
20091128125605 [ VLNCONN ] Accessible
20091128125605 [ VLNCONN ] DB #009: milieu
20091128125606 [ VLNCONN ] Accessible
20091128125607 [ VLNCONN ] DB #010: seagate
20091128125608 [ VLNCONN ] Accessible
20091128125608 [ VLNCONN ] DB #011: dbSanDisk
20091128125608 [ VLNCONN ] Accessible
20091128125609 [ VLNCONN ] DB #012: hp
20091128125610 [ VLNCONN ] Accessible
20091128125610 [ VLNCONN ] DB #013: dbInFocus
20091128125612 [ VLNCONN ] Accessible
20091128125612 [ VLNCONN ] DB #014: intel
20091128125613 [ VLNCONN ] Accessible
20091128125613 [ VLNCONN ] DB #015: BMC
20091128125614 [ VLNCONN ] Accessible
20091128125614 [ VLNCONN ] DB #016: dbInFocusPP
20091128125614 [ VLNCONN ] Accessible
20091128125615 [ VLNCONN ] DB #017: dbInFocusSC
20091128125615 [ VLNCONN ] Accessible
20091128125616 [ VLNCONN ] DB #018: snc
20091128125619 [ VLNCONN ] Accessible
20091128125619 [ VLNCONN ] DB #019: SANDISK_POP
20091128125620 [ VLNCONN ] Accessible
20091128125620 [ VLNCONN ] DB #020: dbIntel
20091128125620 [ VLNCONN ] Accessible
20091128125621 [ VLNCONN ] DB #021: Nokia
20091128125621 [ VLNCONN ] Accessible
20091128125622 [ VLNCONN ] DB #022: dbShowcase
20091128125623 [ VLNCONN ] Accessible
20091128125624 [ VLNCONN ] DB #023: dbPMG
20091128125624 [ VLNCONN ] Accessible
20091128125625 [ VLNCONN ] DB #024: AMD
20091128125625 [ VLNCONN ] Accessible
20091128125625 [ VLNCONN ] DB #025: Purina
20091128125627 [ VLNCONN ] Accessible
20091128125627 [ VLNCONN ] DB #026: AMD_TEST
20091128125628 [ VLNCONN ] Accessible
20091128125628 [ VLNCONN ] DB #027: TEST_dbInFocusSC
20091128125629 [ VLNCONN ] Accessible
20091128125629 [ VLNCONN ] DB #028: TEST_InFocus
20091128125630 [ VLNCONN ] Accessible
20091128125631 [ VLNCONN ] DB #029: STB
20091128125631 [ VLNCONN ] Accessible
20091128125631 [ VLNCONN ] DB #030: BackupAwareness
20091128125632 [ VLNCONN ] Accessible
20091128125632 [ VLNCONN ] DB #031: nvpc
20091128125633 [ VLNCONN ] Accessible
20091128125633 [ VLNCONN ] DB #032: dbCisco
20091128125634 [ VLNCONN ] Accessible
20091128125634 [ VLNCONN ] DB #033: tUserLogin_bak161105
20091128125635 [ VLNCONN ] Accessible
20091128125635 [ VLNCONN ] DB #034: jackson
20091128125635 [ VLNCONN ] Accessible
20091128125636 [ VLNCONN ] DB #035: Michelin
20091128125639 [ VLNCONN ] Accessible
20091128125640 [ VLNCONN ] DB #036: dbMcAfee
20091128125640 [ VLNCONN ] Accessible
20091128125641 [ VLNCONN ] DB #037: PMG_VA
20091128125641 [ VLNCONN ] Accessible
20091128125641 [ VLNCONN ] DB #038: MCSoptimizer
20091128125642 [ VLNCONN ] Accessible
20091128125642 [ VLNCONN ] DB #039: Maxtor
20091128125643 [ VLNCONN ] Accessible
20091128125644 [ VLNCONN ] DB #040: Xtentia
20091128125645 [ VLNCONN ] Accessible
20091128125645 [ VLNCONN ] DB #041: NokiaLetsNetwork
20091128125646 [ VLNCONN ] Accessible
20091128125646 [ VLNCONN ] DB #042: Print_Optimizer
20091128125646 [ VLNCONN ] Accessible
20091128125647 [ VLNCONN ] DB #043: GiftShop
20091128125647 [ VLNCONN ] Accessible
20091128125648 [ VLNCONN ] DB #044: GiftShop_en
20091128125648 [ VLNCONN ] Accessible
20091128125648 [ VLNCONN ] DB #045: dbOrderingTool
20091128125649 [ VLNCONN ] Accessible
20091128125649 [ VLNCONN ] DB #046: SingHealth
20091128125650 [ VLNCONN ] Accessible
20091128125650 [ VLNCONN ] DB #047: Watson_Wyatt
20091128125651 [ VLNCONN ] Accessible
20091128125651 [ VLNCONN ] DB #048: VATest
20091128125652 [ VLNCONN ] Accessible
20091128125652 [ VLNCONN ] DB #049: seagate_sdvr
20091128125653 [ VLNCONN ] Accessible
20091128125653 [ VLNCONN ] DB #050: HM
20091128125653 [ VLNCONN ] Accessible
20091128125654 [ VLNCONN ] DB #051: dbVirtualAgency
20091128125654 [ VLNCONN ] Accessible
20091128125655 [ VLNCONN ] DB #052: Seagate_Xmas
20091128125655 [ VLNCONN ] Accessible
20091128125657 [ VLNCONN ] DB #053: Seagate_CNY
20091128125657 [ VLNCONN ] Accessible
20091128125658 [ VLNCONN ] DB #054: SeagateCM2
20091128125658 [ VLNCONN ] Accessible
20091128125658 [ VLNCONN ] DB #055: SeagateSecuTecheInvite
20091128125659 [ VLNCONN ] Accessible
20091128125659 [ VLNCONN ] DB #056: ICG
20091128125700 [ VLNCONN ] Accessible
20091128125700 [ VLNCONN ] DB #057: SeagateCM2_China
20091128125701 [ VLNCONN ] Accessible
20091128125701 [ VLNCONN ] DB #058: IntelServerConfig
20091128125702 [ VLNCONN ] Accessible
20091128125702 [ VLNCONN ] DB #059: SeagateCM2_Korea
20091128125703 [ VLNCONN ] Accessible
20091128125704 [ VLNCONN ] DB #060: IntelServerConfigTest
20091128125704 [ VLNCONN ] Accessible
20091128125705 [ VLNCONN ] DB #061: SeagateCM2_Taiwan
20091128125705 [ VLNCONN ] Accessible
20091128125706 [ VLNCONN ] DB #062: SeagateCMS
20091128125706 [ VLNCONN ] Accessible
20091128125707 [ VLNCONN ] DB #063: dbNSNCafe
20091128125707 [ VLNCONN ] Accessible
20091128125707 [ VLNCONN ] DB #064: SCMS_XDB
20091128125708 [ VLNCONN ] Accessible
20091128125708 [ VLNCONN ] DB #065: SCMS_AU
20091128125709 [ VLNCONN ] Accessible
20091128125710 [ VLNCONN ] Scan done -> 66 total DBs found
20091128125710 [ VLNCONN ] 59 accessible DBs found
20091128125710 [ SEG2 ] Vuln Connection Done.
What the F**K is going on...
Bringing back FF, locating manualy the 2nd entrypoint specified in the Bot's
logs and ... It seems that it's "Forgotten Password" interface - the very
same FORM that the Code penetrated the system through before. Manual
injection -> not a single MSSQL error. Maybe it's within some hidden text
area or in background color - anything that I could have missed.
The HTML source is clear. Not a single ASP db-error string.
Now, this is the moment I guess a programmer lives for :)
To feel weak and stupid in front of the code you have just written.
It seems that afterall one can learn a new tricks from his own code. After
quick debugging session and watching the code as it runs through the
vulnerability matching steps the case was solved.
The reason behind that the code could have successfuly penetrated the system
and I couldn't was the Bot's bug (oh yeah...) that I left while coding the
bot's HTML parser. The parser implementation I adopted from one of my
previous projects (the Ogame robot) did not have the rule to evade properly
any HTML code within escapement seqences. Actually, it was coded in, but the
minor true/false logic bug prevented it from execution.
The vulnerable "forgotten password" FORM was indeed vulnerable. But not the
one rendered by the browser.
The one tracked and targeted by the code was also a "forgotten password"
interface but it had a different FORM's 'action' URL-path parameter and lay
entirely within one of the HTML commented areas. It seems that some web
programmer with really sharp sense of humour patched that earlier vulnerable
interface, gave it a new 'action' param path leading to a new secure code
interface but not only didn't remove the other vulnerable interface from the
server side ASP code but also left the old vulnerable FORM leading directly
to the remote interface just commented within the HTML code.
Anyway. A buggy bot code, helped the penetration S2 code to find completely
different application's bug.
You simply LIVE FOR these tiny, ironic moments.
20. SIDECAM Robots vs. Honeypots And Attack Vector Recognition
Every time an attack vector evolve one can design and implement a proper
diversion/IDS facility - a honeypot.
Now, since I was focused in general on ID theft attack scenario driven by
SQL Injection based mailbox credential matching, one could construct a
solution trained to recognize such attack in progress, track its propagation
and with some luck tell us something more about the remote entity, that
originated the attack and/or actively exploits the stolen data.
For a specialized, SIDECAM-bot autodetection framework we would need at
first to spread the smell of honey far away, ie. to be highly visible for
automated google-driven target seekers.
A proper positioning combined with building in most common SQL Injection
entrypoint patterns (lets narrow it down just to ASP for now) - like the
unfamous "login.asp" scheme for example, plus certain "data sensitivity
flavour" to taste good (lest say something more critical than a sperm-bank
customer database) - that should do the trick.
When attracted to our phony target, the attackers S2-equivalent code should
find easily the email/password record entries crafted and left there by us.
These mail accounts prepared specialy for the attack IDing purposes could
then be robot-monitored by the honeypot framework - any valid mailbox
credential login will indicate a SIDECAM attack vector exploitation in
The list below contains selected, non-detailed, most critical vulnerable
institutions' systems, identified by the Bot during whole research, in some
cases opening penetration paths to several different organizations /
Some of them might have been patched since the initial vulnerability match,
some might have been shutted down.
From the reasons that have been mentioned in the first paragraph, neither
links nor any further details will be disclosed publicly.
Vulnerable educational organization systems:
- University of the South Carolina, (multiple entrypoints)
- Bulgarian Svishtov Economic University,
- Cracow Jagiellonian University, medical sciences department system
- California State University, student health web service
- University of Washington,
- University of Minnesota,
- Truman State University, (multiple entrypoints)
- Hunter College,
- Dallas Baptist University, graduate admissions system
- University of Arkansas for Medical Sciences
- Association for Information Systems database
Vulnerable government institution systems:
- Argentina Ministry of Foreign Affairs system,
- UK Vehicle Certification Agency system,
- UK Vehicle & Operator Services Agency system,
- Arizona Department of Transportation system,
- California Department of General Services, Online Fiscal Services system
- California Department of Education system,
- California Tax Education Council system,
- California Department of Justice (3 separate systems)
- Florida Department of Financial services system
- Colorado Department of Personnel and Administration system
- Maryland Information Technology Advisory Council system,
- District of Columbia Public Service Commission (multiple penetration
- Arizona Information Technology Agency system,
- U.S. Department of Transportation maritime service system,
- Texas Department of Justice system,
- Federal Mediation & Conciliation Service,
- Alberta (Canada) Advanced Education and Technology service,
- Georgia gov-job portal database,
- Georgia Financing and Investment Commission system,
- City of Grove City (Ohio), contractor application database,
- Geary County (Kansas) Gov Taxing web serivce,
- Sarpy County (Nebraska),
- Sawyer County, electronic taxing / land administration web system,
- Fauquier County (Virginia), county's goverment eNotification system,
- San Bernardino County web system, Purchasing Department Administration
Vulnerable US Department of Defense systems (including contractors and
- Rock Island Arsenal U.S. Army database system,
- U.S. National Defense University system,
- Jacobs Dougway (DoD and NASA contrator) performance and reporting system,
- DoD Severely Injured Service Member system,
- DoD Health Services Evaluation system,
- DoD troops civil carrer database ("Troops To Teach"),
- Lockheed Martin, (multiple entrypoints),
- U.S. Defense Logistics Agency system - defense fuel energy services
Vulnerable Financial institution systems:
- International Monetary Fund system
- U.S. National Association of Corporate Directors system,
- American Economic Association system,
- Global Banking "employer only" job board web system,
- Employee Stock Ownership Plan database,
- Mortage Bankers Assoc of New York system,
- American Society for Training & Development system,
- International Fund Research Corporation database,
- numerous financial advisory companies and institutions
Vulnerable security companies and organizations:
- US based international security / law enforcement / private investigation
- Private Investigators Portals database,
- Private detective, crime, security and software community portal database,
- Retired military officers job portal, entrypoint gives R/W access to other
- Associated Security Proffesinals (ASP) system
Vulnerable aviation and space systems:
- German Aerospace Center subsystem,
- International aerospace company providing equipment and airline
- Canadian airline ticket centre system,
- Air Traffic Control Global Events, air traffic security conferences
Vulnerable health organizations systems:
- US Department Of Health, Disaster (hurricane) response online service,
- US Department of Health and Human Services University, learning platform
- US Center for Disease Control and Prevention (CDC),
- National Association of Clean Water Agencies / Water Enviroment Research
- International company providing validation services for pharmaceutical,
biotechnolgy and medical device industries,
- US Nationswide Drug Testing Services Company,
- French Association of AntiAge and Estetique Medicine,
- International health recruitment database,
- Cleveland Clinic Center for Continuing Education,
Miscleneaous vulnerable systems:
- 160 million hits per month global basketball portal for player promotion
- One of Polish commercial email/web hosting company database,
- Rediff Portal system's database,
- an online-casino client account database,
- Computer share governance services,
- National Geographic's expeditions alliance company,
- An advertising network database system, serving 9 Billion ads on 1500+ web
sites per month,
- Fuji client eSupport database,
- Dialogic corporation (IP, wireless and video solutions) client support
- Nestle corporation's database, Employee Benefit & learning subsystem,
- Australian business electronic messaging (SMS/MMS) provider,
- Event organizing and publishing company with 60+ yrs experience,
- Brasilian VoIP provider, client account database,
- International casting resource database for professional actors,
- few web hosting companies, including small and large business clients.
- numerous dating portals, including one major dating web engine,
- recruitment companies and job portal client databases (29 systems),
including IT, health, law-enforcement and ex-military.
22. return -1
I think there is no doubt that the process of search for the victim, seeking
for vulnerable systems containing credit card numbers along with their CVV2
codes, matching further system penetration entrypoints - even the whole
process of an intrusion and subsequent system penetration: everything can be
parametrized, mathematicaly described and finally automated using two
things: a programming language and a machine. I guess, everybody's familiar
with the fraze: the word is stronger than the sword, right? Well, I must say
that sometimes I like to feel DWORD is twice stronger :)
Although different "friendly" robot-codes exist out there, helping us round
the clock, like for example HTTP web crawlers building google search, there
are also the bad guys. Obviously, the very same automation is being actively
exploited by criminals to track the vulnerable faster and to exploit them
There is one more important thing to note about the whole project. As
probably everyone has already noticed :) the whole Bot code DOES NOT
implement any miraculous, new, 0day attack vector "discovery" - it's just a
PLAIN combination of few human and software vulnerabilities which are just
as old as probably the internet itself (password reusing, email credentials
matching, script engine code injection). There are HUNDRETS of more advanced
and more sophisticated automated and semi-automated tools and scripts doing
probably better their job in comparison to every single particular Bot's
part (segment) alone. The main target of this research was however the FULL
automation, ie. binding all the "penetration phases" together and limiting
as much as possible the human factor in the seek-probe-penetrate-analyse
In my opinion, the most disturbing observation of the research is the fact
that the results can be accomplished easily by anyone out there just bored
enough - sitting in home, after or in between a dailight job and/or without
a budget. The question is: what are the capabilities of a potential criminal
entity WITH the budget, unlimited research manpower and malicious goals. It
would be really shortsighted to say that a fully automated codes of this
kind - but emploing few times wider range of protocols and targeting
different server side compromise technologies - aren't operational for a
long time and under control of the darker shade underground.
Nevertheless, it's pretty obvious: one can not implement a PERFECT
protection for our personal secret data - as we are the only holders and
protectors of that secrets each other - all we can do is to EDUCATE, how to
build them strong and handle them safely. Though, I guess it would be nice
to see some movement around automated and semi-automated robot code projects
implemented and operated by white hats this time, ACTIVELY targeting places
that seriously weaken the global information infrastuture and open the
users' personal ID information for theft.
I mean, the banks are are obliged to protect the money of their customers by
following specific protocols which are developed and validated externaly
through apriopriate audit procedures, right?
Is it then a hard one, to imagine an automated or semi automated system,
working more or less like a country-wide cyber security sonar, that would be
able to pinpoint and instantialy alert apriopriate response/tech-support
organizations, about those specific "identity data bank" web applications
and systems which CAN'T and WON'T protect our sensitive secrets - passwords,
keys, CC data and IDs?
And all because of a single programmers flaw, which exploited by an attacker
compromises our electronic security instantly.
Anyway, theory is one, reality is another...
Thx and Greetz: SIN, Sl4uGh7eR, Vo0, Andrui, Mario, Rothrin.
porkythepig () onet pl
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Raising Robot Criminals porkythepig (Mar 29)