Re: Multiple .edu sites reportedly victims of db theft

[John Stauffacher <john () CAFFEINATEDNETWORKS COM>]

All,

John Ladwig pointed out to me an interesting point -- it seems that this
person is almost exclusively using SQLMap - at least in their previous
attempts.

SQLMap by default has a pretty standard user-agent you can filter on:

sqlmap/$VERSION (http://sqlmap.org)

Where $VERSION is a string...like "1.0-dev-5920d16" . It also comes
pre-packaged with a host of 'random' user agents that it can emulate:

https://raw.githubusercontent.com/sqlmapproject/sqlmap/master/txt/user-agents.txt

About 90% of the time the first request sqlmap will make is to
$URL/?UPnC=$PAYLOAD

So creating an IDS rule, or scanning your access logs for a combination of
user agent and a specific request will at least narrow down the people who
are actively scanning your sites with the tool.

There is also a thought that this person may be using Tor to mask the
source of the attack -- there is a list of Tor exit nodes available here:
https://www.dan.me.uk/torlist/  that is updated every 30 mins, probably a
good thing to integrate into your IDS if you haven't already. Scanning your
access logs for known Tor ips would probably also give you an idea how much
traffic you receive from the Tor network -- this may be considerably
smaller than regular internet traffic.





On Tue, Feb 3, 2015 at 12:16 PM, John Stauffacher <
john () caffeinatednetworks com> wrote:

> I'm going to assume though that these are just the top level domains --
> and that he has found an appserver on beyond just the www. If you check out
> his twitter feed -- he eludes to grabbing SSNs and emails. In the Metro
> article it was mentioned he had made off with Employee SSNs -- so my guess
> is he is targeting SIS or CRM systems...Maybe Oracle? Banner?
> WebAdvisor/Datatel?
>
> I realize this is a giant "find the needle in the needles" exercise -- I'm
> working trying to find more intel on who this character actually is, so we
> can start building a profile. For all of you not in AUS -- if you can cull
> your IDS/FW or even access logs looking for traffic that is coming from AU
> that is not normal, that may be a start -- or even just look for successful
> 200 OK returns for IPs that are not geographically within your normal
> traffic patterns.
>
> Just some suggestions. Thank you all for looking into this.
>
> On Tue, Feb 3, 2015 at 9:36 AM, John Stauffacher <
> john () caffeinatednetworks com> wrote:
>
> > My apologies for formatting, I generally take the daily digests -- so I
> > am picking up responses out of the listserv interface.
> >
> > Unfortunately, right now - I know very little. I'm working with a few
> > organizations here in the states to see if we can isolate traffic from
> > outside of the US that is suspect and is targeting their applications.
> > Having spent a good deal of time myself in Higher Ed, i understand the
> > enormous pressures your under and how budgets are always tight, time is
> > always tight -- but I would ask -- if you get some spare cycles start going
> > through your access logs or ids logs looking for sqli attacks.
> >
> > I wanted to include some comments that Gary Warner from UAB sent out to
> > another distro, as he went the extra mile to find even more background on
> > this:
> > - snip -
> > Not sure if there is enough to go on here or not, but when I visit the
> > Pastebin link by this kid, there are many examples of his URLs in his other
> > Pastes.  For example, here is a list of SQL probes he did against "nhs.uk
> > ".
> >
> > http://pastebin.com/5yxT6c8s
> >
> > His catalog of pastes can be accessed here:
> >
> > http://pastebin.com/u/abdilo
> >
> > Because he has also been probing the Australian government and many
> > Australian educational institutions, I'm also passing this information to
> > friends at ACMA and the AFP.
> >
> > Finding a single IP who hit several of those addresses, and then looking
> > for that same IP on some of "our" .edus might be a path forward, but I
> > believe it may be true that, as Greg points out, there is not enough
> > information here to move an investigation forward.
> >
> > If there is "proof" that this is happening, I would strongly suggest
> > sending a lead to our FBI friends who deal with academic breaches, but
> > again, I'm not sure if we have that much information yet.
> >
> > Just thought you guys would be in the best position to try to determine
> > what we might be able to do here.
> > - end snip -
> >
> > I think if we are going to make a run at stopping this person, we would
> > need to collaborate a bit and start sharing some information.
> >
> >
> >
> >
> >
> > > Is there any other information about how or what is vulnerable, or what
> > information was extracted?  More information will be required before any
> > organisation could do a response and begin the investigation into how to
> > remediate.
> >
> > Greg
> >
> > On Tue, Feb 3, 2015 at 1:51 AM, John Stauffacher <
> > john () caffeinatednetworks com> wrote:
> >
> > > All,
> > >
> > > I came across an individual a few days ago on twitter (@abdilo_) that
> > > was bragging about breaching multiple .edu's via sqli. He claimed
> > > responsibility for a breach of Metropolitan State University, and this
> > > afternoon dropped this partial list of .edu sites that he reportedly has
> > > breached and absconded with their databases:
> > >
> > > http://pastebin.com/yyhT6tzc
> > > uq.edu.au
> > > columbia.edu
> > > usyd.edu.au
> > > upf.edu
> > > vcu.edu
> > > williams.edu
> > > monash.edu.au
> > > uji.es
> > > hu-berlin.de
> > > exeter.ac.uk
> > > mcmaster.ca
> > > ubc.ca
> > > waikato.ac.nz
> > > uwa.edu.au
> > > ohio-state.edu
> > > handles.gu.se
> > > iwm-kmrc.de
> > > purdue.edu
> > > lancs.ac.uk
> > > uni-erlangen.de
> > > luiss.it
> > > unimib.it
> > > purdue.edu
> > > univ-montp1.fr
> > > uw.edu.pl
> > > pless.cz
> > > inscripcions.org
> > > uni-oldenburg.de
> > > 141.89.97.231
> > > idecisions.org
> > > uni-mannheim.e
> > >
> > > If anyone on this list is a member of these organizations, or can reach
> > > out to them -- it is important that they know. From the communication that
> > > I have gotten from this person (all via twitter) this issue seems to be
> > > systemic in some piece of software shared amongst all these groups. If that
> > > is the case, then we are looking at a vendor related flaw -- and the
> > > potential targets is pretty large.
> > >
> > > --
> > >
> > > John Stauffacher
> > > GPG Fingerprint: 5756 3A3B ADA3 22A6 9B26 6CA8 DB8D 2AC3 7699 0BD