[ELECTRONIC NOISES]
[MUSIC PLAYING]
Welcome to the Hacker House hands-on hacking web
application theory module.
We're now going to switch our perspective back.
Having looked at some of the internal systems
that we might encounter on an environment,
we're now going to shift our mindset back
to external perimeter.
And we're going to look at more how most companies these days
might suffer a breach through the misuse of web applications
and things that sit at the application layer of the OSi
model.
So as opposed to looking at the infrastructure-- the web path,
the patches--
we're now going to focus more on the applications
that we may have seen as well a little bit of in the earlier
modules.
So the OWASP top 10, which we touched on briefly
in our first module for web services,
contains a reference to what's known as the top 10.
And these list the most common ways
in which computer breaches happen
through web applications.
And right there at number one is injection attacks.
Throughout most of this course, we've
seen a large number of injection attacks, variations
of injection attacks--
command injection, LDAP injection-- and we're
now going to explore some other injection attacks.
But we also want to look at some of these other types
of application vulnerabilities like cross-site scripting,
insecure direct object reference, and all those.
So again, a reference guide for you to look at--
go to the OWASP.org website.
No point reinventing the wheel.
There's some terrific informations
and fabulous documents there, and also numerous
cheat sheets and reference guides to help you out
as a tester.
So a very useful resource for you is OWASP.org.
So that leads us to application flaws in general.
So we might come across different kinds
of flaws which impact web applications in a slightly
different way to how they would impact on a network
service or similar.
So things like broken authentication
or links or flaws in the authentication or session
management code that can sometimes
expose account details, passwords,
session IDs, or URLs.
You can use these to kind of tamper with regular accounts
and gain elevated privileges, gain admin rights to a system.
Or you could steal them.
You could actually steal some session IDs using
other kinds of vulnerabilities.
So authentication-- when there's an information
leak or a flaw that allows you to bypass authentication
or misuse it in some way.
As an example here, if we were to look at a web request
to a web application, you've got this
get slash api slash log on.
You could actually take this cookie here, ai_user=john,
and you could change that value around to make it reference
something like, you know, ai_user=Matthew, for instance.
And then it may actually give you access to Matthew's account
instead of John's.
So that's an example of broken authentication,
simply specifying some other user name in place of another,
you know, trusting the client, things like that.
Broken access control-- this is when
users are not fully restricted from accessing functions
or data.
The attacker can change some value
in a parameter using HTTP parameter tampering that
may elevate privileges or give them access
to some additional apps.
So apps and APIs don't always verify
if the user is intended for the target resource.
So this is sometimes known as insecure objects or user
reference direct object reference that might be abused.
So let's imagine you have a function
and you click on a web app and it says get receipt.
And your get receipt comes back, and it says, here
is your receipt and PDF, it may well
be that receipt dot PDF is linked to an ID equals.
In our example here of broken access control,
you can see logon dot ISP, and then
account ID equals, and then the number which
references the account.
So this kind of broken access control
would be simply changing that number from 48 to 49
and then being able to access somebody else's account.
You might see this when you get your bank statement,
you click on Statement, and it says statement ID.
And if you change your ID to another ID,
you may get somebody else's statement.
That kind of thing.
It's not doing sufficient role-based access control
checks.
It's not checking that the user has the rights
to access the objects in the application.
So we need to be aware of those kinds of bugs-- direct objects,
accessing them directly-- very common kind of vulnerability
you might see.
Misconfigurations.
A lot of breaches happen because people just screw up.
We're people at the end of the day.
Humans are humans, and humans will human.
So default accounts will allow insecure installation scripts,
configuration files, things that might
be left out on the server.
They can happen at any layer of the application stack,
from platform web server, web applications, databases,
frameworks, and custom code.
Stack traces and error pages also
contain sensitive information which
may be of use to an adversary.
Things like Tomcat, Struts, Spring,
dot net model u-controller, and various others often
provide default configurations that can be seen as insecure.
So we saw some of that in our earlier module.
But misconfigurations, people have inadvertently
enabled the service or disabled a service in error.
You might see things like this in a web application.
If you remember, we stated that a HTTP state that's 500
is not good for you but great for me.
So when we see HTTP state say it's 500,
that's usually an execution error.
Something went terribly wrong on the server.
And as an attacker, that, to me, says
I might be able to do something good.
So in here, we've got an example of a stack trace.
You can see the version number.
Exposes some of the technology and use of some of the methods.
And this is where we could start trying
to abuse some of these functions,
trying to cause these errors and see is there any SQL in there,
is there any credentials.
I've had usernames and passwords spit out of these functions
before.
So it's always very useful to check for it.
Cross-site scripting attacks.
Another very prevalent and in fact
widespread problem that can be used
to inject web content and script into another user's browser.
JavaScript can be used to do all kinds of things,
from mining crypto currency, reading cookies,
injecting additional exploits.
You can do all sorts of things in JavaScript.
It's fascinating.
And cross-site scripting is one of the most widespread security
vulnerabilities in existence, simply
being able to execute or render scripts and content
in another user's browser by getting them to click on a link
and having that execute within the context
or domain of some website and do some evil stuff.
So stored cross-site scripting, again,
can be used to write worms.
There are two variants of cross-site scripting,
or two main common variants.
And that is reflective cross-site scripting--
I send you a link, and inside of that link
is a HTML file or some scripting error.
You click that link, and it will cause the script
to execute in the browser.
The other is a stored cross-site scripting
or persistent cross-site scripting,
where I go to a page, I set this string,
I set my JavaScript into that page.
And it's saved on the page.
So when everybody else looks at that page,
it will load my script from there.
So I don't need to send you a link.
I'll just wait for you.
More like a logic bomb in terms of I deploy it into a system
and I wait for the results.
So persistent cross-site scripting,
reflective cross-site scripting.
If I find persistent cross-site scripting,
I label it more higher and more severity because you can use
it to create autonomous worms.
And this is how Samy Kamkar was able to get
himself a few million friends on Myspace.
Sadly, I'm not his friend on Myspace.
But if you were, then you were able to--
he did that by exploiting a persistent cross-site scripting
vulnerability.
Again, SQL injection attacks, like we looked out
on the database module.
Databases in the three-tier architecture.
Web applications will be using a database of some sort.
And you might find that you can pass
into those HTTP parameters.
You might be able to pass in some arguments that
gets applied into a database.
And subsequently, you might have an injection attack
into that database.
As an example here, you can see SELECT firstname,
lastname FROM names WHERE firstname LIKE data.
So imagine if that data was what's the name like Matthew,
then I could inject SQL-like commands by simply adding
Matthew, a tick, and then using something
called Union, which would use another SQL query
and return it, provided it gets balanced and matches
the same number of columns as the initial Matthew.
So you need to make sure that the number of columns
match the original query when you're using things
like union injection to exploit a SQL injection attack.
You could also have just simply put a tick and a semicolon
and then just added more instructions on there for SQL,
SQL queries, and these SQL queries would then be run.
And that's known as a stack, a stacked SQL injection.
You can stack commands together.
Union is combining them.
And there are various others.
You can use SQL to concatenate values and get around
some of these restrictions if you want.
But that's just an example of how SQL injection
sort of raises its head.
And this is an example of using parameterized SQL
queries, which is intended to prevent
this kind of vulnerability.
So developers are generally kind of getting more aware of this
now.
You'll be hard pushed to find a developer alive today who
isn't working in the web space who isn't aware of something
like SQL injection.
They are much more aware of this kind of problem.
If they're using Angular JavaScript,
they may even think cross-site scripting is a feature, not
a bug.
But generally, SQL injection is a more understood problem
in cybersecurity, because it was the source of just so
many breaches, particularly from around the year
2004 and onwards.
It became very highly prevalent and was
exploited quite regularly in a lot of different regions.
CVE- 2014-3704 so-called Drupalgeddon
is a SQL injection vulnerability in the popular Drupal CMS
that you can use to bypass authentication and get
code execution.
It's important to remember that when you're doing a SQL
injection attack, everything that you did in the database
module can be done to the same database.
You're just going to have to work a little harder to do it.
So being able to execute commands,
being able to read files, being able to do all of that thing
is generally possible with a SQL injection bug, sometimes.
Not always, but sometimes.
And likewise, there's been some high profile ones,
like Drupalgeddon, so-called because it
was an Armageddon of all of the Drupal instances on the web.
However, we recently experienced another one in 2018
called Drupalgeddon 2.
That vulnerability was introduced
in a later version of Drupal when
it's used in our lab module.
So you can't use that attack against this instance.
But there is indeed another Drupal exploit
now surfaced in the wild which is being widespread
and exploited, mainly for the purpose of distributing
crypto currency miners.
XML External Entity Processing.
And what I've tended to see now lately in recent years
is that as developers have become much more aware
of things like SQL injection, they're much more trained
and they're more acute and able to spot it.
That, however, doesn't mean that they
are very aware of security problems in general.
And they may think that, you know,
XML entity injection or others are not really valid things,
or they don't understand how they can be misused.
So often, I'm finding a lot of developers
are now making a new mistake of XML external entity processing.
And that is that you can issue instructions
to the XML preprocessor.
When you send XML data and that XML data is being parsed,
a preprocessor will parse XML data.
And you can give that XML preprocessor some instructions
to do things like include files from an external disk,
include files from external computer, things like that.
And subsequently, we can use that XML preprocessor
and the errors that it returns to read data.
And in some extreme cases, even execute
files, even execute commands, or misuse
through things like PHP filters.
So anywhere that I can see anything
that looks like XML can be used to access files
and read its contents.
Anywhere that I see XML, I test for XML entity injection.
So anywhere I send XML or XML-like data to a server,
I could check for this kind of bug.
And here's an example of it using the external document
type to try and read the password file
and then include the contents of that password file
inside of the XML's output.
And the preprocessor would read that file, put that file
into the XML data.
And hopefully, we could then get that displayed back
to the user.
2014, there was a libxml2 Drupal vulnerability
which showed an insecure XML preprocessor configuration,
otherwise known as libxml2, that contained
various vulnerabilities within the Drupal instance.
That included a service module, or REST API,
that does not disable XML entity injection.
And this could be exploited.
It required no authentication.
So this vulnerability was found by a company called Syntactic.
And we were able to read through that paper.
And there's some interesting tricks in there
through use of PHP filters.
And they didn't provide a working exploit.
So we actually exploited this bug for ourselves.
And we'll show you how this vulnerability works
and what you can do with it.
It contains things that you'd be able to do here,
like read files from the disks, access things like settings
dot PHP, access things like credentials, et cetera.
So that concludes our theoretical introduction
to web application security.
This is a very dense topic in and of itself.
In fact, you could do an entire course just
on web application security and teach you all
the academic theoretical bugs.
However, we tried to focus on vulnerabilities
as they appear in the wild, so you can actually
get some experience of how these vulnerabilities manifest
themselves and what kinds of things you can do with them.
So we're going to try and avoid looking
at theoretical academic concepts and focus now
on actually breaching web servers using
some of the techniques we just outlined here.
So we're going to be focused on the external attackers
perspective again, and we're going
to now look at the web server 2ISO, which will provide us
with a slightly different web environment
than our first module.
We're then going to use that to target that environment
and try to breach that web server.
So thank you.
And I'll look forward to seeing you
in the practical module of this section.