I mentioned in previous
posts
that I had been working with Nessus -- I used it a lot. At the end of
the engagement, we had almost a gigabyte of Nessus data saved in nbe
format. So to quickly go through and analyze all the results, inserting
it into a database was essential. I was using
Nessquick at
the time, which was a couple of Perl scripts used for inserting the data
into a database and exporting the data. I also had a bunch of sed and
awk scripts that would then clean up the results and fix various
punctuation and presentation issues I didn't like. The process became a
bit tedious, so I decided to write up a Python script to do all this for
me.
Here are some example uses from the usage:
./tissynbe.py -d database -f results.nbe ./tissynbe.py -d database -o output.csv ./tissynbe.py -d database -o output.csv --order scriptid --sort desc ./tissynbe.py -d database -o output.csv --count ./tissynbe.py -f results.nbe -o output.csv ./tissynbe.py -f results.nbe -d database -o output.csv
You can download tissynbe.py from the tissynbe.py project
page.
Now here's where I ask for some help. I'm by no means a programming
guru, so to all you Python developers and hackers, if you can take a
look at my code and offer any suggestions, I would greatly appreciate
it. I think I have a handle on most of the code as it's fairly
straightforward, but I think it could use some tweaking and optimization
in the clean_nbe() method.
Comments and suggestions are encouraged!
Posted by Marcin on Friday, May 23, 2008 in
Code and
Security.
Arbor Networks has a blog post up today about Using RPKI to Construct
Validated IRR
Data.
Resource PKI (RPKI) is an extension to
X.509 to allow for IP address
(prefix) and AS identifiers (autonomous system numbers -- the
organization-based assigned number used by the Border Gateway Protocol
to get you or your ISP "online").
My first introduction to hijacking traffic at a global level was in
1997. A certain ISP that I knew would typically test their attack
theories and concepts live by re-routing, redirecting, and outright
stealing traffic using BGP-4. It was often done to spammers, typically
those already in a customer relationship with the provider.
By using a TCP/IP routing concept known as a "more-specific route", or
MSR as I like to refer to it -- a route injected into the RIB (routing
information base, or "routing table" as most people call it) that has a
shorter-prefix (a /24 instead of a /23) will be selected by the RIB to
be the destination of all traffic that is categorized by that prefix.
If, say, the 2 /24's that make up a /23 are both injected into the RIB,
then all traffic destined to that /23 is now directed instead to the /24
MRS's.
Historically, there has been little to nothing to prevent this from
happening at a global level. As we spoke about in the Day 12: ITSM
Vulnerability Assessment
Techniques
post, even YouTube was recently hijacked by Pakistan using the exact
concepts above.
Note that this is different than regular IP/ASN hijacking. The YouTube
incident was BGP traffic hijacking. The difference (and they are even
worse when combined) is that IP/ASN hijacking involves modifying the RIR
(Regional Internet Registry) database records to new information, such
as contact, DNS, RWhois, and other ownership rights. The world was first
officially introduced to this style of attack in 1999 when
CERT
released an advisory detailing the Potential for False Authentication
in Registry
Transactions
aka the "MAIL-FROM:" attack, which works just like regular domain
hijacking.
Typically, the defense to these types of attacks has had one major
stop-gap: ISP filtering, in particular -- customer filtering, which is
typically/historically applied only on the customers. When L0pht
presented to Congress in 1998 and told them that they could "take down
the entire Internet in 30 minutes or less" -- Mudge and company were
likely referring to the fact that route filters were applied at the
customer level (and not even always there), but not in between ISP
peering relationships.
Route-filters on ISP peering, especially "default-free zone" (DFZ)
peering, often used the IRR (Internet Routing Registry) information to
build a preventative measure. Hoewver, the IRR system itself (the
primary vendor/organization being the RADB -- or the Routing Arbiter
Database, or now known as the "Router Assets Database") was typically
vulnerable to the same "false authentication" attack and other abuses
such as social engineering.
RPKI looks like it goes a long way towards ensuring an easy path for
ISP's and other BGP-speaking organizations to protect their routes and
deliver an infrastructure that could withstand simple attack vectors
such as these.
Posted by Dre on Wednesday, May 7, 2008 in
Defense and
Security.
In October of 2006, a vulnerability in IE7 known as the "mhtml:"
Redirection Information
Disclosure was discovered.
RSnake wrote up a
post
about how nasty it was. The basics: it took over the entire browser
experience.
Fortunately, the bug was patched quickly, it required access to the web
server/application (or HTTP header injection), and it only affected IE7.
There was also a lot of talk about the vulnerability, making it quite
obvious to monitor, discover, and track if you do those sorts of things.
Nate McFeters wrote about his trip to BlueHat
v7 on the ZDNet Zero-Day
Security Blog. There, he links to a more in-depth writeup on the
BlueHat
blogs
with a full recap of the conference. He spoke about a few things that
interested and surpised him along the way.
One big, glaring highlight of the talks, he spoke about -- and I quote:
Manuel Caballero discussed something that originally didn't catch my
attention. It initially sounded like the same research that's been
put into cross-site scripting attack frameworks, which basically
involved using XSS to create a bi-directional communication channel
between victim and attacker for exploitation of XSS. Then I realized
what Manuel was really talking about. Resident scripts have put the
fear of God into me. Whereas a normal cross-site scripting attack
vector is great for the site that was cross-site scripted, it
stopped there; it couldn't follow you off-domain. Manuel's can.
Scary.
Manuel's talk, "A Resident in My Domain", discussed using browser
malware activated by what sounds like an iframe and a bit of Javascript
magic. On Manuel's website, a deeper
look into the newly discussed concept speaks as follows:
Do you believe in ghosts? Imagine an invisible script that silently
follows you while you surf, even after changing the URL 1000 times
and you are feeling completely safe. Now imagine that the ghost is
able to see everything you do, including where (location) you are
surfing, what you are typing (passwords included) and even guess
your next move. No downloading required, no user confirmation, no
ActiveX. In other words: no strings attached. We will examine the
power of a resident script and the power of a global cross domain.
Also, we go through a step by step approach on how to find cross
domains and a resident scripts.
So, there you have it, folks. Manuel has appeared to have discovered a
cross-browser, multi-OS, unstoppable man-in-the-browser that can read
any activity that you do with your browser after it activates, including
crossing any domain boundaries. Unlike the "mhtml:" Redirection
Information Disclosure, this appears to be a vulnerability that will go
unpatched in browsers for possibly as long as XSS, CSRF, and other
same-origin policy violations.
I'm going to continue to explain to my mom that she should close her
browser (exit completely), open the browser again, log into and use her
banking web application, and then close her browser cleanly again after
logging out of her bank's website. Barring NoScript, I suggest you do
the same.
Update (Wed May 7 14:28 MST): It appears that Michal Zalewski busted
Firefox in a unique way that almost sounds similar to the above attack
vector. The Mozilla bug is called iframes from other sites can be
changed while pointing at
about:blank and
Zalewski's PoC is available from your browser as
ifsnatch.
Posted by Dre on Wednesday, May 7, 2008 in
Conferences,
Hacking,
Privacy and
Security.
So the other day I get a call from the forensics team at work asking for
help with some packet analysis. A client's users had reported phishing
activity, so they decided to run a full-content capture using Wireshark
on the external and internal network interfaces. Upon doing so, they
witnessed suspicious activity; commands such as cmd.exe were triggering
alerts on their Snort sensors as well. Oh boy...
After the attack was contained, the client's internal security team had
reconstructed the attack and learned that the attacker had compromised a
server, downloaded tools to C:\Windows\system32\, including
Foundstone's SuperScan and Sysinternal's
PsExec,
and then uploaded three RAR files via TFTP.
My goal: see what was in those RAR files. Whether it be intellectual
property, client information, etc, the most important task was to
identify the sensitivity of the data inside. I opened the raw capture in
Wireshark and identified the three TFTP streams. I thought I would
right-click and select "Follow UDP Stream," then save the raw data as a
RAR file. Unfortunately, when I did this, I could then not extract the
contents of the archive. Looking for an alternative, Landon pointed me
to tcpxtract (as detailed on
Bejtlich's
blog),
which at the time sounded good, but I couldn't get it to compile under
Cygwin and I wanted to get this done quickly. Oh well, with a name like
tcpxtract, can it even handle UDP streams?
So, looking at the packets again, there were only about 20 per stream, I
decided to do this task manually. Who knew if it would work, but I gave
it a try. I manually selected each individual TFTP Data Packet (not
acknowledgments!) and selected the TFTP Data portion which began at the
47th byte in the packet. I did a Ctrl-H (or select File > Export >
Selected Packet Bytes) and saved as block01, block02, block03 for each
packet in the stream. I then cat all the files and redirected stdout to
file01.rar like so:
$ cat block* > file01.rar
I opened the RAR file and extracted the contents without a problem. I
admit I was a bit excited at this point, interested to see its contents.
I later spoke with Richard about this, who pointed me to a blog
post from last
year about TFTPgrab. Remembering
this post now, I find it interesting that there was no way to rebuild
files transferred through TFTP before TFTPgrab. Yet, I successfully
managed to do so here.
Anyways, here are some lessons learned. The attacker was sloppy, amateur
at best. To call it amateur would be an insult to amateurs everywhere.
For the client, it was sheer luck they ran a full-content capture at the
moment of the intrusion and our adversary used a non-encrypted medium to
transfer data. Had he encrypted his files or used an SSL tunnel, we
wouldn't have anything. Not to mention, if this is the kind of stuff
that gets picked up during a random packet capture, who knows what kinds
of malicious activity they have been or are currently subject to. Even
more so, why are companies not doing egress filtering of traffic? TFTP
should have been blocked at the firewall no ifs, ands or buts.
One last lesson. When you outsource IDS monitoring activities to an MSSP
(who probably has one or two analysts per 30-35 clients like yourself),
attacks against you will not be treated with the same diligence you
would expect of your own staff. They just don't care as much as you do.
Posted by Marcin on Monday, May 5, 2008 in
Security and
Work.
Not to be outdone by Neohapsis
Labs,
NSS Labs also enters the fray with their blog, Security Product
Testing. Again, I think that NSS Labs
(like Neohapsis Labs) has been blogging for awhile, but it has picked up
more pace lately.
In the past, the TS/SCI Security blog staff were invited as
guests
by Martin McKeay for the Network Security
Podcast. Rick Moy of NSS
Labs
got the opportunity to speak his mind with Martin while at the RSA
Conference. Rick was additionally interviewed by the Bank Information
Security Podcasts on
Product
Testing.
Both of these might be worth a listen for the discerning security
professional.
Last week, NSS Labs approved the Radware DefensePro
1020 for
attack mitigation purposes. They claim that, "The DefensePro 1020
blocked 100 percent of attacks while passing 100 percent of legitimate
traffic without need for user intervention". I really like what NSS Labs
wrote on Security Products & PCI
Compliance,
where they state that:
Fact: No product will make you compliant. But having an inadequate
or misconfigured product can prevent you from achieving compliance.
We're hoping to see/hear more from NSS Labs in the future!
Posted by Dre on Monday, May 5, 2008 in
News,
Privacy and
Security.
