Official Blog of Trustwave's SpiderLabs - SpiderLabs is an elite team of ethical hackers, investigators and researchers at Trustwave advancing the security capabilities of leading businesses and organizations throughout the world.
Over the many years I’ve spent training various local, state,
federal and law enforcement organizations on forensics methodologies, one story
always sticks out in my mind as I
prepare for courses. As I get organized for the upcoming Computer
Forensics & Incident Response for Investigators course on July 27th
– 30that BlackHat USA
in Las Vegas or hear
about another breach in the news, I’m reminded of the following story once again.
A certain engineer retired from his job of 37 years at a
very productive factory of a very well-known company. Prior to his departure, he trained three
young college graduates with engineering degrees on the ins-and-outs of the
factory. Because the retiring engineer
did not have a college degree his replacements quickly discounted his
admonitions as the ramblings of an "old man".
SOURCE Boston is coming up in April, and Mike Ryan and I are
giving a presentation about making packet analysis easier for the masses. One
of the challenges with building new protocol parsers for tools such as Ettercap
and Wireshark is many of these parsers are written in C. C is very fast and
powerful, however you run the risk of introducing vulnerabilities in the
software. And, for folks who aren’t fluent C programmers, building these
parsers can be intimidating.
So, what are we going to do to change this? One of the
pieces we’ve been working on is trying to merge Lua into Ettercap. We did a
presentation at Derbycon last year about how we planned to do this, and now we
have some practical uses. We’re going to take a look at how to build easy to
use scripts, similar to the Nmap NSE scripts, to allow manipulation and parsing
of data that would otherwise require C code.
A few months ago, I was asked to present a keynote at RSA
Conference 2013. This was a rather intimidating request given I was in a lineup that included Vint Cerf, Dr. Condoleeza Rice, Jimmy Wales and Andy Ellis.
For those who were not in San Francisco last week, this
isn’t a small conference. There were an estimated 22,000 people at this year’s
conference and the room the where the keynotes were held could have up to 5,700
people seated.
I have attended 100s of security conferences around the world. While I have seen
some very insightful and interesting, the common opinion by many con-goers is
that the keynotes are sometimes not all that enjoyable to watch. They are typically
not technical at all and are usually a 30-40 minute monologue around a single abstract point or idea.
I very much wanted to present a talk that I would enjoy
sitting and watching for 30 minutes. So I did my best to make that happen.
Back in December, I was traveling on business and after getting
to my hotel rather late I turned on the television. I happened to flip to a
local ABC channel and Jimmy Kimmel Live was on. I watched the first 20 minutes
or so and realized that the format used on late night shows might be the
perfect way to give a keynote at RSA.
When you watch a late night show, they almost always follow
this format at the start of the program:
A monologue
Some sort of show and tell
A special guest with a Q&A
I decided to organize my keynote in the very same way:
A monologue on cybercrime from Victims to
Attacks and closing on the Process used by criminal organizations.
A live demo of a web-based attack showing both
IE and Java exploits
A special from the United States Secret Service
and questions crowd sourced from Twitter.
If I would have had more than 40 minutes rather than 30, I actually thought of asking DualCore to perform as the musical guest.
Having given a TEDx talk a few months ago, I had learned
from that experience that less is typically more keynote or short format
presentation. I didn’t want to use dozens of slides having bullet builds and text.
Instead, I started by story boarding my talk and then worked with a graphic
designer to create a presentation based in Keynote that had very visual
auto-building slides and even video segments when the animations were a little
more complicated than Keynote could handled. Most of what you see on the screen, didn't involve me clicking a button to advance things, they did so on their own while I was speaking.
I have also learned that using speakers notes can be a bit
of a crutch when speaking publicly. For some this may be scary, but once I
jumped into this way of presenting it is hard to go back. I feel like I am able
to be more visual in my explanations, I don’t just focus on exactly what was
planned for the talk and I am able better read and connect with the audience.
If you are an experienced presenter in the security industry, take a leap of faith and try this way of presenting. You audience will thank you, and you'll have a great experience.
This past weekend I was lucky enough to attend Microsoft’s
BlueHat Conference in Redmond WA and Security B-Sides Seattle. The combination of some of those talks succeeded
in keeping some persistent issues alive in the hopes of finding a
solution. We live in a world dominated
by the Internet and rapidly changing technology. Most people regularly use at least some form
of social media online whether it’s Facebook, Twitter, Reddit, etc., and it’s
accessed and updated from a home computer, tablet device, or smartphone. And while the Information Security world is
far more cognizant of what transpires online your average user really
isn’t. And it’s sad to think they either
don’t care, or have a “it will never happen to me” attitude. I’m not sure how much of my online life is
made up of paranoia, anti-social behavior, or just that I feel what I do is
none of anyone’s business but my own. I
don’t have a real Facebook account, I have a “sock puppet” account. I have a
twitter account, but if you look at it, it’s all angry rants. I try to minimize my web footprint as much as
possible, but I love my email accounts.
Yes, that’s right -plural. All
are different user names, with different email services. Each is associated with various logins to
different services on the Internet. So
what about the average user?
A number of months ago, I was approach by the organizers of TEDxNaperville
to speak at their next event. Until this time, I was loosely familiar
with TED* and had heard many other people talk about the great talks
they watched on their website or via their iOS app. I had never attended a TED event nor had I really watched a talk in its entirety before, so I wasn't sure what would excite this audience.
Obviously, the topic I was asked to speak about was security and privacy, but there wasn't anything more that was required of me. As someone who often speaks at various events each year, I didn't want to do a talk based directly upon topics I normally speak about. I was also encouraged by the organizers to reach outside my comfort zone and really challenge myself. So I made a list of the items that I was not comfortable doing or talking about on stage (or to anyone for the most part):
The following thoughts
on internal network penetration strategies are drawn from "OPFOR
4Ever," which I'll be presenting later this week with my colleague Chris
Pogue at Microsoft's BlueHat Security Conference.
Network penetration testers love to complain about the
unrealistic scope restrictions that get placed on our work. "Please exclude these IP
addresses." "Please only test
between 1 and 5 AM Pacific Time."
"Layer 2 attacks are out of scope." These are familiar refrains. But we have only ourselves to blame.
Our clients place these restrictions on our work because at
some point in the past they got burned.
A penetration tester locked out user accounts, created an accidental
black hole in the network, or brought down a production server.
But isn't it ironic that blackhats bent on data theft so
rarely cause system outages? Especially
since modeling blackhat behavior is the inspiration behind penetration testing
in the first place? Blackhats place a
high priority on stealth, naturally. But
notice that stealth implies safety. If we return to our roots -- modeling real
attack scenarios involving stealth -- we get safety for free. By conducting safe tests, consistently, we
can build confidence in our clients to see the artificial constraints as no
longer necessary, and our tests will better model real-world risks.
This year I've been very busy in terms of conferences, and developing/coordinating new features for BeEF.
The move to GitHub has been successful: we are receiving many pull requests from our users, and we encourage everyone to do it. If you have something cool you are doing with BeEF, or just ideas, send us your code or let us know!
Conferences are always a great moment to socialize, drink and speak about hacking, without mentioning traveling the world basically for free.
In Louisville, Kentucky next month at Derbycon, Daniel
Crowley and I will be giving our presentation Vulnerability Spidey Sense - Demystifying PenTesting Intuition. The point of the talk will be that little
mistakes and small vulnerabilities in a web application can give pointers to an
attacker about where to focus their efforts.
As penetration testers, we aren’t fortunate enough to have an unlimited
amount of time to review the security of an application, yet malicious
attackers have as much time as they need to exploit a security hole. By paying attention to detail and focusing
our efforts on the places that vulnerabilities are most likely to be found, we
can attempt to close the gap between PenTester and attacker.
Here are some examples that might indicate further
vulnerabilities in an application.
Weak password
policies and security questions
Allowing users to choose weak passwords can allow an easy
brute-forcing opportunity for an attacker; and weak security questions, such as
prompting for the user’s birthday, can be discovered through basic
investigation into a user through social media.
However, bad policies such as these can also indicate that the developer
of an application does not understand some security best practices, and could
lead to other findings deeper in an application.
Test pages and
default content
Before moving an application over to production, all test
pages and default content (the phpinfo page, for example) should be removed
from the web server. Default pages can
be used to reconnaissance an application, and in some cases even provide
additional functionality that may be useful to an attacker. Test pages that were created during the development
process, even if their function doesn’t prove useful to an attacker, may not be
help to the same level of scrutiny from a security perspective that other
portions of the application are held, providing a useful gap in the
applications security for an attacker to exploit. Finding these items may also indicate that
there is additional content to be found if examined carefully.
Old technology
Seeing an application that is
written in ASP, or is running on IIS 5 or 6 should set off immediate warning
bells during a penetration test. Seeing
old technology that is still in use can be a strong indication that an
application is vulnerable to old or well-known vulnerabilities. Experience or a little research can help you
find well documented vulnerabilities and instructions for how to exploit them.
By watching for indicators such as
these, a PenTester can more easily prioritize their tests and focus on the aspects
of a system that are most vulnerable. Daniel and I will be discussing these,
and many other warning signs that an application is ripe for an attack, this
year at Derbycon.
Patsy (slang) - A person easily taken advantage of, cheated, blamed, or ridiculed.
My girlfriend (@savagejen) and I will be presenting at Derbycon this year about some research we've done into systems not configured as proxies, but which will pass traffic for you anyway. To understand the concept better, let's look at an example: Google Translate.
If you put a URL into Google Translate, it will go and fetch the page, then translate it using the languages you specify. If you were to launch attacks at the site using the Google Translate interface, the originating IP found in the web logs would be Google's, not yours!
This is just one example of a system that will pass traffic for you. There are many, many systems out there which will operate in similar ways.
The first obvious implication here is one for incident responders. It may be convenient to say that the IP which you found in your logs is owned by the person who attacked you. It is even more convenient to say so when the machine tied to that IP does not run any sort of traditional proxy service. However, it's not necessarily true.
Another danger associated with these "patsy proxies" is that since the application owner likely isn't aware that their application can act as a proxy, they might not go through the normal hardening steps to prevent abuse of that proxy. One potential danger of this is allowing network boundaries to be violated and firewalls to be traversed. An application which can act as a proxy might actually present a vulnerability which allows an external attacker to lay waste to internal systems!
To learn more about what systems can be used in this way, their potential for abuse, and the implications of all this hullaballoo, come watch "The Patsy Proxy: Getting others to do your dirty work" at Derbycon this year.
All trademarks are copyright their respective owners. The appearance of trademarks doesn't imply any association with their owners. Please don't hurt me with your legal hurty stick.
If you currently do a search online for a female’s perspective about DEF CON, everything is coming up sexual harassment. I’ve been asked a dozen times about my experiences in the past week alone and I can’t say anything overly negative about it. But that’s my experience. Mine. A small percentage might be because I’m not about to take anyone’s guff, part of it has to do with the people I surround myself with, but mostly using common sense saves me every time. Common sense is a wonderful thing and if you use it, you can still have a good time. The biggest problem is that there are going to be jerks aka rotten apples, both male and female, at any venue you attend be it a hacker conference, the neighborhood bar, a friend’s 4th of July party, or on a date, et nauseum. And it’s making me angry that complaining is winning out over problem solving.
