Web 2.0 tutorial: Security awareness for Web 2.0 attacks

Web 2.0 tutorial: Security awareness for Web 2.0 attacks

Date: Jun 15, 2011

In this special Web 2.0 tutorial video, security luminary Robert “Rsnake” Hansen discusses serious Web 2.0 attacks that pose a severe threat to the Web security landscape. This exclusive in-depth presentation looks at an array of attack methods and what can be done to better recognize and secure these threats against your organization.

Topics include:
Primer of Same Origin Policy - 2:11
Cross Site Request Forgery - 3:56
CSRF Mitigation - 6:11
Cross Site Scripting - 8:58
XSS - 12:29
XSS + CSRF - 13:41
Clickjacking - 14:50
CLickjacing examples - 17:15
Google Bowling - 19:44
PHP File includes - 22:58
SEO via PHP RFI - 25:38
Malvertizing - 26:29
Future of spamming - 30:03
Clouds of insecurity - 32:34
Other related threats - 34:14


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.   

Web 2.0 tutorial: Security awareness for Web 2.0 attacks

Robert Hansen: My name is Robert Hansen. I'm really glad to be here.
I am extremely tired. I just came back from Munich and from all the jet-lag.
If I've no nod off in the middle of my presentations, somebody throw
something at me. I run a small consultancy out of Austin, Texas called SecTheory.
We do a lot of web application penetration testing, network design, review
architecture. You just heard Richard talk about APT. We're sort of the
simulator. We actually pretend like we are the bad guys and try to break
into companies and show them what's wrong and all that kind of stuff.

We also run a small hosting company for companies who don't know how to
host. We break into a lot of hosting companies and a lot of people got
really annoyed and said OK, what do we do about that but we can't make any
recommendations because we don't know where to send them, so we started our
own. We also do some advisory, capacity stuff for investors and financers,
and Angels. Lastly, we have a couple of websites, Hackers and Slackers. We
can find a lot of information about web application security, in
particular. You got all that on your documentation. I recommend
specifically checking out Slackers. That's the most current and will say
it's the most up-to-date.

For those who don't know, I really do speak all over the world, I even
speak at the Pentagon. I don't do a lot of smaller conferences. I generally
do very large conferences, but I do speak all over the world so, I am going
to go speak at Abu Dhabi, for those who asked and that is, the easiest way
I can put that, and I also speak to a lot of Black Hats. They're Black Hat
only conferences, not black as a conference, real Black Hats, bad guys.
They have their own conferences. A lot of people ask why do you do that?
It's just the easiest, most simple way I can say that without please don't
ask me more questions is sometimes it's really valuable to know what the
other side is doing. So you have to trust me.

Let's start off kind of simple, we'll get a bit more complicated as this
goes by. For those of you that don't know what the Same Origin Policy is,
it's the most important thing you'll ever have to know about your browser.
It's the single thing that keeps you protected from most of the client site
attacks that guys like me care about. Kind of just walking our way this
way. You have a protocol, http or https, that means secure. I did an
entire presentation to Black Hats in Vegas, showing that it's not secure
but, for most intents and purposes, it is.

Sub-domain. You're most familiar with www but it can be anything. Like
ours is ha, for hackers.org. Domain is kind of this whole
in thing in here. YourDomain.com. Top little domain is .com. It could be
.org or .mil or whatever. Path to whatever you're talking about, so index
dot html or whatever. Parameter and Value and back here is Anchor tags.

For most intents and purposes, this is the part that matters. Everything,
protocol, sub-domain and domain, is the part that matters the most when
you're talking about the browser. That's the thing where Javascript is not
supposed to read anything that's not exactly matching that. So, if I have a
little piece of Javascript on the page, it's supposed to be, to stay
restricted. That's true, except when you're talking about Cookies. Cookies
kind of fall down. I do an entire presentation just on how broken cookies
are. But for the most intents and purposes, this is how it's supposed to
work. If this ever broke, I could read data from your bank, if you're on my
hacker website. Or I could change your router settings or anything I wanted
because, anything you've got access to, I'd have access to. So, it would be
extremely, extremely bad.

There's a lot of ways around it. The first is Cross-site request forgery.
Cross-site request forgery basically means, you come to my website and I
tell you to go to a different website. While I can't necessarily read
content from another domain, I can send you to another domain and I can
send you to another path and that path can include variables and then that
path can tell you Delete my Account or Add Money to my bank account or
Transfer money out of my bank account or all kinds of bad things. As long
as I know what the path is and I know what the data is or I know how to
post that data, I can basically make your browser post and send data to
these other websites. That latest Twitter worm, not the one that, actually
there's two different varieties. There is one that's a JavaScript only and
there's one that's a Cross-site request forgery. The second one is Cross-
site request forgery. This is basically how it worked. You went to a
website, they forced you back to the same website, back to Twitter and
then, you're posting data and it kind of propagates.

Anything, like Images, iFrames, CSS, Javascript, all that stuff, I'm
allowed to make Cross-domain requests. Not allowed to see the data
necessarily but sometimes I can, sometimes I can read that data, depending
on what we're talking about. The difference between a Benign Cross-domain
request and a non-Benign Cross domain request is really very subtle. How do
I know if you're making a request to my Twitter page that I didn't want you
to make that request in Twitter? If I design that functionality to work
that way in the first place, how do I know if it's bad or good? There's
very subtle indicators and it's very difficult to detect. Primarily you
just have to assume it's bad and try to whittle out into things you
necessarily know are good, which isn't a particularly easy thing to do.
There's some defenses we'll talk about in a second.

A lot of people talk about Get versus Post, when you're talking about Cross-
site request forgery, like, Post is so much more secure. That is 100%
false. They really don't matter. There are certain cases where it's easier
to do attacks if it's Get but, primarily from my perspective as a bad guy,
it just means I need to get you to visit a page versus visit a image source
or something. It's slightly, slightly harder but it really is not a major
protection to use Get versus Post. So, if anyone ever tells you that, you
can just 'A-ha! You're wrong' because you talked to the guy who knows
better.

Nearly all banks, Mil, everything is vulnerable. We have lots of stats to
back this up. There's some guy who came out, who was adamant that it never
occurs. Well, you know it occurs - it occurred on Twitter. There was a worm
just a couple of days ago. It's on nearly every website. Websites we used
all the time. Here's some of the mitigating factors and, the first one a
lot of people say it's a terrible method so don't do it. Just remember that
this is possible, just don't do it. Check referring URLs so you see where
the traffic is coming from. So, if it's coming from a different domain, and
I don't expect it to come from a different domain, well maybe that's bad.
The problem is, it's really easy to turn off refer. You can turn it off
using Meta refresh. You can turn it off using SSL. If it's a local, if it's
file pulling or a local host or something, their browser knows better not
to send referring URLs from your local machine.

And also, there's a lot of security tools that turn it off so just refer
sometimes it isn't there. You either have to build a caveat to allow refers
not to be there, in which case the bad guy just works around it by using
one of those methods I just told you about. Or you have to block all things
that don't have referring URL and then you're going to block a lot of
invalid traffic. Doesn't work very well. But ultimately, I can still just
get the user to click on it for me from the page that had the valid link.
If I can craft that valid link on the correct domain or a correct domain,
then I can just get them to do it for me, and I'll show you how that works
in a minute.

Here's the better method. NONCE, stands for Number Once. A one time number
that you, the website share with that user so it could be their cookie
value or some derivative based off of something you know in the back-end
or whatever. Some will input, this is html, where it's a hidden value. It
doesn't necessarily need to be hidden, but you probably don't want to show
this on the page. Your N
once can be whatever but its value is some non-guessable thing that me, as
a bad guy, I can't force someone to go there because I don't know that
number. If I knew the number, I'd win but I don't know that number because
it's cryptographically secure or unique or whatever. So I really come down
to the same sort of thing. If I can get the user to click on it for me, I
still win. Or, if I can steal it, I still win. I can also guess it. That
would be bad. The other one is embed a link like a Flash movie or
something that is much more difficult to steal off the page, because maybe
it's in a completely separate domain. Again, same sort of deal, if I can
get them to click on it or steal it, I win as a bad guy or if I can guess
it. Let's assume it's cryptographically secure and it's just one of those
things where I can either get them to click on it or I steal it. Let's take
them one at a time. Let's try to steal it first.

Stealing it comes down to getting some Javascript on the page and pulling
that data off the domain. So, how do I do that? There's this thing called
Cross-site scripting, XSS. Not to be confused with CSS, which is Cascading
Style Sheets. Let's say there's an input value. I type in, it's like a
search box. What do you want to search for? I want to search for "toys" or
whatever. Let's assume instead of typing toys, I type in something like
"end angle bracket, angle bracket script alert XSS end script. That's just
a very simple thing to create, some alert box, but it could be much more
complex. It could be like the first Twitter worm that we saw where it's
actually performing an action and doing something bad. Here's like it would
look in the page once it actually got rendered. You can see it jump right
out of that input box and now it's firing Javascript right there on the
page. So any Javascript that a valid developer on that system would be able
to develop, I can develop for them. It just might not go be as nice as
theirs.

So simple things I can do is steal cookies, I could overwrite the entire
page with my own login form, I could force them to make cross-domain
request or same domain requests. Pretty much anything that you can possible
imagine that you'd be able to do as a developer, I can do on their behalf,
which would be bad. Here's an example on some random military site, real
example by the way. It happens all over the place. You can find them in
literally 80% of websites. It's almost so bad it's not even really worth
talking about because it's everywhere. Everyone has these vulnerabilities
because no one is properly sanitizing their inputs to make sure that
they're not jumping out of these variables.

We know for a fact, because we have a lot of scanners out there that are
doing this type of research, that around 80%, more than 70% and we think
that 80% is the right number, of dynamic websites are vulnerable. If you
count non-dynamic websites, like static webpage’s or whatever, not so much.
But that's probably a very low number. We think the number is probably
closer to 90%, maybe even 95%. It's just that the type of scanners that
we're using to do this type of math tend to not do very good with really
complex methods of obfuscation. This is a very, very simple
example. There's much, much complicated examples.

The first really good example of Cross-site scripting was a Samy worm.
He's a great guy. Samy's hilarious. Some people in this room have met him,
he's hilarious. He wrote this worm thinking OK, this worm on MySpace, it's
a social networking platform. This worm will propagate but it will
propagate and it will be exponential but he's thinking it will propagate
maybe one 1 month and then 2 the next and 4. In 4 or 5 months, I'll have a
good laugh and I'll shut it down. Well, within 24 hours, he had over a
million friends, so a little bit faster than he thought and he couldn't
shut it down and MySpace couldn't shut it down. They shut it down the wrong
way and it kept kind of rebuilding itself. It was just the way it was
written. He's a smart guy. And so it all started with him trying to say,
instead of him being in a relationship, he's in a hot relationship. That
turned into one of the largest Cross-site scripting worms ever very
quickly. We know it's actually not a million though. We know it's probably
closer to about 2-3 million because a lot of people weren't actually
authenticated to MySpace when this attack was happening. So we don't have
the real numbers but we know it's way more than a million.

Things have changed since then. That was around 2005. There's Internet
Explorer. As of 8, there's a Cross-site scripting filter built into it. No
script diffuse Firefox, as an extension you can install it. It also has a
Cross-site scripting filter that the IE8 filters based on. Those do a good
job of protecting against certain types of Cross-site scripting. There's
other types that don't do such a good job at but it's certainly better than
nothing.

In general, this is really good for helping steal affiliate cookies or
building affiliate cookies, or if you're in the Black Hat SEO world, which
I know a lot of those guys. They make anywhere between $1 and $20 million a
month doing stuff like this. There’s a lot of phishing schemes. They can
make, one guy claims he was making $50 a second. I don't know what that
math works out to be. Cross-site scripting is certainly very, very
lucrative, if you know what you're doing. And it's so lucrative that
there's even jokes on the Internet: "You appear to be writing a PHP content
management system. Would you like me to automatically insert Cross-site
scripting vulnerabilities?" It's so common. It's really hard to find
applications that don't have this issue.

Here's kind of another take on Cross-site scripting. Remember, anything
that this user gets to see, I get see. So if I try like an SSH brute force
or something and that port's not open, I'm not going to be able to do
anything. Try to break in through NetBIOS but the port's not there, there's
nothing listening, again, I can't do anything. FDP, same deal. But, if that
user goes out and makes a request and pulls back dynamic content as
rendering on the browser, whatever that user can see, I can attack. Well,
that user can see all kinds of stuff that I can't see, because it's behind
a Firewall. So, if you have content management systems behind, hear bug
tracking systems, internal works, IP telephones, anything that sort of
responds, and doesn't necessarily have to completely respond but just
mostly responds to line feed based protocols like http, which is a long way
of saying a lot of things respond to this. I can basically break in all
this stuff, steal all the data, infiltrate it, pull it out, all with
literally one line of Javascript.

Alright. So how 'about the other method? We've talked about how you steal
the credential. Javascript can steal that credential. What if I want to get
someone to click though? I want to get someone to click on something,
whatever we're talking about and do the bad thing. Well, in this context,
it's embedded inside a flash movie. This is the flash settings manager
page, which most people don't even know exists. This is our Macromedia.com
and it is probably the most important page on the internet for your
security and you don't even know it exists, which is really scary. But
basically there's this one particular button here that basically turns off
all your security in your browser. This turns off the Same Origin Policy
within Adobe, which would be 90% of browsers essentially, maybe even higher
than that, 95, 99, somewhere in there. So if I can get you to click on
this, that would be very bad. So how do I do that? How would I get someone
to click on something like that?

Let's say I put that thing into an iFrame and now let's say I put that
thing into an iFrame. And now let's say I put that thing into an iFrame and
let's say that I hover that thing underneath your mouse pointer. What if I
made that transparent so that you can't actually see that. Anything you
click on that page, as these things are hovering underneath your mouse, is
going to be the thing I want you to click on and that's Click Jacking and a
huge percentage of sites are vulnerable to this. So let's take a little
walk down memory lane. Here's another take on this exact same issue. This
is a guy named Ronald Van Heitkamp. You want to remember your login, please
click to allow. Well, he's surfacing, he wants you to be able to see,
another example. Would you fall for that? Probably. I would. Sure, I want
you to. OK. Click.

What about this one? This is a slightly different example. This is the
access to flash camera and microphone. When we first came out with this
exploit, Adobe was pretty upset and said please don't release this because
the only people who can use this really are pedophiles and foreign
military. Please don't release this. So we gave them time, they had a
chance to fix this. Somebody else used the kind of the premise of what
we're talking about to build a code just before they released the fix for
it but you get the idea. If I can get someone to click this button, I have
complete access to spy on them. What about that? Do you want to allow Ajax?
Well, everyone wants to allow Ajax. Web tube porno's great, right? I want
to be able to have my maps work and all that crazy stuff. Well, if you
click that, instead of giving me access to Ajax, now you're giving me
access to your camera and microphone. There are tons of examples like this.
Anything that's kind of like a single or multiple clicks and doesn't
require a lot of user interaction is going to be vulnerable to this. So
something like this delete user accounts. Very simple.

What about this? Auto purchase something. If I can pre-load the data and the
URL and get them to click that last button that they just need to click
confirm, I'll get them to buy things in my behalf. Something like stocks,
for instance. Send an order, buy a trade. I did a Pen test fairly recently
on a company that was vulnerable to this exact thing. Even nearly looked
exactly the same. Reset the router to factory defaults or what about
completely removing all of the deny access list on their Firewall. So now
their Firewall does nothing. It's not even theirs to off. What about
making your profile public on MySpace or Facebook or whatever. You thought
you were being all private, your scanning pictures to your boyfriend or
whatever, husband. Well, now everyone can see them. In Word press, I can
deactivate things that might be security plug-ins or things that get in my
way as a security guy or a hacker or whatever.

Social bookmarking sites. All are vulnerable to this. In fact, there's a
bunch of click-checking worms that have gone around, both against Twitter,
which is only semi-interesting but more interestingly is the Like feature
within Facebook. So there's a lot bunch of things. You might have heard
about Like-jacking. It's based on this concept.

Or MySpace, you can actually make somebody your friend. Well, they weren't
your friend before because a lot of times, once you get a relationship
built with them; you can do some of their actions. You can start
communicating with them in a context that you weren't allowed to before.

This is a pretty bad problem and it's not going to get fixed anytime in the
near future. I've done some analysis with a couple of big browser vendors
and there's a whole bunch of reasons you can't really fix this and you'd
probably not be super-shocked to find that you don't probably care about
most of them. Only one of them really affects you and it affects you in a
negative way anyway and that's banner advertising. Who here likes banner
advertising? Right.

Unless you're an advertiser, and you want people to come to your website,
in which case, those people are very loud, vocal, but a minority of the
internet. They tend to drive a lot of changes within the browser and
therefore, it's a cross domain, iFrame, that people want to click on it
maybe really, really small. That's banner advertising. If they fix click-
jacking, they have to turn that off. So that's why it's not being fixed.
You can go yell at Microsoft.

Has anyone heard the term Google Bowling? Ever? It's not a common term. It
basically means, I'm trying to use Google to hurt my competition. Let's
say, I am a retailer and I got a bunch of people out there who are selling
the exact kind of thing. What if I kind of took them out of Google's
listing? That'll be kind of interesting. There's a bunch of different ways
to do it.

A couple of years back, I developed this technology called Slowloris. It
was designed to exhaust and sort of delay Apache, which is the most common
web server out there, from serving up requests. I released not thinking a
bit, I didn't think that would be much of a big deal because I release a
lot of stuff just like it and no one seems to care. But this one just
happened to be released, without my knowledge; I was not paying attention
to the news, the same day that the Iranian Elections were sort of
exploding. The Iran resistance started using other types of denial service,
at first, to try to take down the Iranian networks. They were taking down
everybody though, instead of just the Iranian Government networks. Because
Iranians, they don't have like these really big fat pipes, they're kind of
small things. So the problem with that though is they were taking out
protesters within Iran who were messaging out we're getting beaten or put
in jail or whatever so there's please don't use these gigantic denial
service tools that are just blatantly taking down our networks. Use
something much more targetive like Slowloris. It just came out today. It's
really good at doing, it was taking down Government websites and people
were 'Hey, hey. Look at me. I'm taking down...' I'm like please don't tell
me that. But it is really nice if you need it to take down your
competitors. After a while, Google started saying well, you're not a very
reliable site, I'm going to down-grade your SEO a little bit, I don't think
you're as reliable as these other sources. Things like that.

DNS Cash Poisoning made the news a lot when Dan Kaminsky came out with
this. You might have heard about it. It was all over the news a couple of
years back. A lot of people think it's fixed but it's not at all fixed. His
particular bug is fixed but not the core problem which is that I can brute
force DNS. While before I could do it within minutes, now it takes maybe a
day or more but, if I have a really big competitor out there and I really
want to do something bad, I might be willing to spend a day, so I can spoof
some static competitor.com, which includes their Javascript and I can start
serving up Malware. Now they get on Google's bad guy list like 'Oh, no.
You're serving up Malware. You're one of those guys. Sorry.' And suddenly
everyone stops going to their website. These are more complicated ways to
doing Google Bowling. Any sort of persistent Cross-site scripting, we've
talked about that before. If I can get, let's say it's a comment field. If
I can get somebody to post a comment and that comment can run Javascript,
well, then I can source in Malware. That's actually how a lot of malicious
code already works today. I'm not trying to infect anyone because I care
about infecting anyone, but I just want to ruin the reputation of my
competitor.

Let's talk about something different. PHP file includes are one of the
easiest ways to take down most PHP enabled websites these days. It's
starting to become less and less of a problem because people are starting
to realize OK, this is actually a big deal. The way PHP is configured is
starting to come out. I'm sorry, it's a little dark. Basically it's a URL,
question mark URL equals or path equals. And basically what we're telling
PHP is, there's some code that I want to include on this page, please go
fetch it from somewhere and usually that's meant to be local to the file
system but, if it's mis-configured, it allows you to pull it from the
internet. The bad guy just sources in their own malicious PHP file, pulls
it in, runs it and puff! So instead of responding, a File that's TXT in
this example, won't respond with anything super-malicious. It'll just say a
number, for instance. And the number will be like some crazy long string.
But it is something that it knows. A robot will come by, make this request
and, if it sees that crazy long string appear on the page, it knows it
worked. And if somebody goes by and tries to run the code and say, OK well,
what sort of malicious things they were doing, all they will see is a
number. It's not particularly useful.

But that robot knows that it worked now, if it did work. If it didn't work,
no harm, right? All they found was a number. They can't see our database
strings, or they can't see the command and control infrastructures going
off, making RC-connections. If this is vulnerable. What they'll do is
they'll change it and put the real payload, maybe it's completely different
site, but the real payload will be a second request. So, only in the case
where they know it actually worked, they will make that second request.
Then you'll see this gigantic stuff start happening to the system, will
take over the database, start making manic control of the internet, import
6667, 6668 or 6669. And so that bot propagates. So once that bot gets on
that box, it starts doing the exact same thing that the previous bot did to
compromise that box and it keeps growing. It's really simple to turn into a
worm because all you have to do is run against all your logs, see who's
attacking you, turn it around, start attacking anyone who is attacking you
and you take over your competitor's bots as well, because they were also
vulnerable to PHP command injection, remote file includes. Then there's
other ways to change the site in ways that are not perceptible, by changing
404s, File not founds, Except 200, OK status codes. It's much less likely
the person will see it but you don't really need to do that. This is Blake
Ross' website. He is one of the Firefox’s developers. I have nothing
against Firefox, by the way. I know these guys really well. He is one of
the original guys, founders of Firefox and here's his website. This is what
it looks like. Most people going to his website, this is what they're going
to see. Nothing wrong with that, right? You don't see anything wrong?

This is with Javascript turned on. What if he had turned Javascript off?
This is what robots see. Robots see that he is selling [four-set] [26:02],
which is probably not what he thought this website was originally designed
to do. There are tons of examples of this out there. People don't even
realize they've been compromised but they're being used for marketing
purposes or whatever. Often times, they're delivering up Malware and they
don't even realize it. So Javascript is not necessarily your friend.
There's another thing you can do. It's called Mal-vertising. I didn't come
up with this term, by the way. I think it's kind of a dorky term. Mal-vertising is
where somebody is delivering something that, well, there's two
concepts. One, is they're delivering something that looks like anti-virus,
even though it is a virus. And they go like "Oh, you got a virus infection.
That's the one I'm giving you." And then the other one is, if you're
looking for anti-virus, are you on the market for it and they will try to
surface it for you. Anything that says like anti-virus 2010 or something,
it's all Malware, all of it.

This is a really horrible example. It's the only one I could find on the
internet. It's too bad because actually found a real example the other day
on one of our customers. It was good. Here's how it works. So this guy
comes in. He's on the phone. He's like 'Alright. I got a $20,000 media buy
but I got to do it by the end of the day, and it's like 10:00, we've only
got like a couple of hours. I need it up. Your Best Buy, we want this
thing today. If I can't get today, our budget's blown. We're not going to
be able to do this'. And the other guy on the other side of the phone's a
sales guy. He's like 'It's end of quarter. Damn it, Yeah. I got to get this
thing in.' So he's like 'OK. I'll make it happen.' Quick review of the
creative, makes sense, looks good. Alright, blow it out the door, right?
It's a fake credit card, by the way. Or stolen credit card or whatever.
Then nothing happens for a while. Looks legit and he starts looking at the
time of day. The time of day is really important when you're trying to
figure out when people are actually at work. Guys like me tend to only work
9:00 to 5:00 or whatever if we're in corporate jobs. Maybe less.

But that's also based on time zones. So, if I have one office that's in one
place, let's say that that's where the media buy happened. That's the
advertiser. Then you have another office which is the retailer, let's say
they're in a different time zone. That entire block between 8:00 am and
5:00 pm of all of their work hours combined, is when you don't want to
surface your Malwares. So, as long as you can kind of figure out what that
is ahead of time, you're good. So you don't deliver Malware anytime of the
day when they might be at work. Then you also do GIP based Malware. So you
don't deliver Malware if you know that they're coming from, let's say they
have an office in Seattle. Anywhere in Washington, just don't deliver to
anyone in Washington. If someone's working from home that day, they're
going to catch it. Just don't. Blacklist all of Washington, they don't get
Malware. Then they kind of redirect you off to this Malware thing.
Sometimes they'll do some Javascript detection in there and say OK, if you
got a really, really big browser window, you're probably kind of computer
savvy and we probably don't want to give you Malware. But if you got a
little 6 by 480 or one of these guys, absolutely we're going to give you
the Malware. Because you're probably not computer savvy. I tend to get a
lot of Malware because I got a little computer. So you get these Malware
advertisements and this happens fairly frequently and I'll show you kind of
how in a little bit. Spamming. Like I said, I spend a lot of time with bad
guys. Really, really, really useful people to know. I spend as much time as
I can with them. They know more about bad guy stuff than anybody because
they are the bad guys. I was hanging out with one a couple of years back
and he was talking about this system he's developed. Let's talk about an
online persona. He creates this entity that's not really a person, it's
just sort of a list of attributes.

Let's say his name is Bob. He is 20 years old. He lives in Colorado.
Single, which will indicate interests by the way because if you're single
you got slightly different interests than if you're in a couple. Zodiac, is
whatever, he's a Libra or whatever. Birth date, whatever, he's like I said,
he is 20 years old. He's got some friends, his friends are other personas,
also not real people. He's got, perfect weather, let's say his weather is,
he likes warm weather but he lives in Colorado which is not exactly a warm
weather place. Usually, anyway. If we kind of tie that together, you can go
off and query weather databases. And the weather database says oh, well.
It's cold, cold, cold. Oh. Suddenly warm. Well, now our persona gets happy
and he starts blogging on a social network and starts twittering. 'Hey all,
thank God it's finally warmer. I'm going to start going to' his nearest
interest. I like biking or whatever. 'I'm going to go look for the nearest
bike park. I'm going to go biking at such and such park. Tomorrow, blah,
blah, blah. It's going to be great. Going out with my buddies' who are on
the friend's list or whatever, who are also the nearby attributes. Make
sure they're in the same locale and you can start building out something
that looks really good, like to the point where he actually showed us some
examples.

He had four copies. This is a conference of bad guys. He had four copies
and he said 'Tell me which one you think a human wrote' and only one
person, there was 30 of us, only one person got it right. Statistically
irrelevant. I mean, it looks extremely good. So if he can build about a
million of these a day and if you can start taking over social networking
platforms, where you're putting out so much spam that so many people
believe it's reliable real information, you can do anything. You can take
over elections. You can say, smear campaign, I don't like that person. Or I
love this product. I love this Rolex. I really want one for my birthday and
it's really increasing the brand. These guys are extremely clued in about
ways that they can change social perception. They's master social
engineers. The best in the world. Very scary people. That's even more dark.
I can't even read that one. Sorry about that.

A lot of people are talking about Cloud. We're going to move into the
Cloud. Cloud's where things are. The second presentation I'm going to be
doing today is largely about that. I'm not even going to spend too much
time on it. There's all kinds of things that you can do like deny service.
It is really easy. If I take down one Cloud computing environment, I'm
taking down maybe hundreds or thousands of people or companies or whatever.
They don't necessarily segment data properly so, if I'm taking some data,
I'm taking all data. Even one tiny little hole and it's kind of game over.
They don't necessarily have the right access controls. I'll talk about that
a lot in the second presentation. What happens if they go out of business?
Once company goes out of business, where's your data? How do you get it
back? I actually had one of my friends used to work for a company, a very
large hosting company that went out of business and literally it's a fire
sale. The machines are going out the door with customer data on them and
are being sold at auction. That literally could happen to you if that's not
a viable business.

There's also things like, a lot of people are talking about Amazon web
services, moving to that type of environment. But Amazon has actually came
out and said 'We cannot give you certain types of PCI compliance. We can't
do it, because we can't allow you to have the level of access that you
would normally have in your own environment.' And that's just compliance.
That's not security. That's just compliance. And then we have things like
Twitter using Google docks and that getting compromised because of weak
passwords. You have to be careful with you're picking Cloud providers and
know exactly what you're getting into. I'll spend a lot more time talking
on that later.

So it's all kinds of things that we're not really going to be talking about
in this presentation, but you should be aware of. Things like inter-
protocol exploitation. Just because browsers are only supposed to speak
http doesn't mean that the other side doesn't sort of understand what it's
talking about. So, in certain context, I can post data if the protocol is
polite enough to ignore getting data that doesn't expect and then only
read the data it expects to get and it starts ignoring the rest again
because it doesn't make sense. Well, it can speak other protocols. Things
like Send mail. There's been exploits in Astrix servers. This is a very
expansive list of things that have been exploited. And, unfortunately,
there are quite a few other protocols out there that have not been tested.
65,000 ports, of which we know 4 or 5 are vulnerable, out the top of our
head that we've tested. There's a lot more testing to be done.

SQL injection is a very important topic for web application security. It's
just a little too complicated to talk about in this presentation but
basically allows bad guys to steal information from the database.
Sometimes get XP command shell actually get full control over the
machine. It's pretty nasty stuff.

History stealing - This was really big in the news for a long time
because it was actually being used by bad guys but Firefox is
actually shutting this down so you will no longer be steal history
using CSS.

This basically allowed bad guys to do is figure out where you've been as
you traveled across the internet. If they know the question to ask, Have
you been to Bank of America? You'll say yes or no, kind of a binary switch
and that can give you a lot of information. Let's say I'm like, have you
logged into the State Department's webmail server state.gov/or, whatever
it is. Well yes, you have. OK, well you're a Senator or you're one of his Aides
or something. Have you log to this porn site. Aha. It's gay porn, aha. You
can see where this is going. DNS re-binding - I will talk about this in the
next presentation so we're not going to spend much time on it here.

RFC1918 cache poisoning - We'll talk about but there’s a ton of other things
out there that, a lot of other types of exploits that we won’t be talking
about. This is such a complicated topic. It's really impossible to spend.
I'd probably have to stand here for days to get through it all. But I
really encourage you to go check out Slackers to kind of get an idea of the
different types of vulnerabilities out there. Make sure you got No script
turned on and make sure you're not doing it from your own computer. It's a
little bit like the Wild West.

More on Web Application and Web 2.0 Threats

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: