[COMPUTER SOUNDS]
[MUSIC PLAYING]
Welcome to the Hacker House, Hands-On Hacking web
applications practical module.
We're now going to demonstrate from the external perimeter
perspective how to target a web application,
make use of some web application security tools,
and try to breach this server using a combination of web
application exploits, and maybe missing patches, and similar.
So the thing that you'll need to ensure--
if you look at the screen, you should
see that my VirtualBox is configured the same as before.
Only this time my ISO module is changed to web server version
2, and we can see various host-only network
configurations set accordingly.
So I'll now spin up this second lab virtual machine.
And we should see we get a familiar splash screen,
and then we should be able to boot up to a friendly console
prompt.
And from here, we can see we've got the IP address
192.168.56.3.
And again, from Kali machine, we just
want to check that we can see that system.
So first stages first.
We do our initial reconnaissance.
We do our enumeration.
We try to find our information leaks
and do our vulnerability profiling.
Let's try and find if there are any weaknesses
into this server.
So we're simply running a standardized port
scan and a very common Nmap scan with no additional options.
We get an indication that the only services
open on this website are 80 and 443.
This is much more commonly seen.
This isn't what I'd expect to see
in a kind of production web server or production web
application.
You would only expect to see some like web service ports
available.
And indeed, if we did a full scan of this box--
which we'll do now--
because we want to ensure that we get completeness,
we'll do minus sT. We would know that that would only contain
the web service ports as well.
But we'll disable pings.
We'll run our common infrastructure
probing to try and get that completeness in there.
Don't forget to do things like UDP probes as well.
But in this module, we're just going
to probe these services here--
make sure we're running the default scripts,
make sure I've got aggressive mode enabled,
disable DNS, make sure I've got pings disabled.
And then I'm going to output normal, stall
that as webapp.txt and also webapp.xml.
So just by doing a port scan and connect scan against this host
now, we should be able to get a complete picture
of the services offered.
And indeed, the only services offered here are TCP services--
http and https.
So remember as well, if you've been
doing some of our previous course modules,
you might sometimes need to clear your cache if you reuse
the same IP address or you have the same IP address for some
of your modules.
Otherwise, you may request things from the wrong place.
So we're now going to browse through that web server,
see what information we can learn about it.
And by browsing through this web server,
we can see that this is the Ministry of Ponies,
where friendship is magic.
And all these little cute pony characters
here, it appears to be that someone has created a fan
site for My Little Pony telling you that there is victory just
a wings beat away.
So we've got some kind of website
here that's used for My Little Pony.
It seems to be sharing some images and other things.
So we're going to-- well, the first thing that we would do,
we would do our standard infrastructure assessment.
Part of our assessment here is going
to be to look at these web applications--
do the web application security side of things.
However, we can still get some useful things.
You might find other bugs on their like, WebDAV
and a few other things that we've enabled,
just to kind of help you out.
And indeed, if you look at other things on there--
and we may have mentioned the Heartbleed exploit, et cetera--
if I was to do SSL scan against that service,
you would find here that this server
is in fact vulnerable to Heartbleed as well
and has a number of SSL-related vulnerabilities as well.
So there are plenty of weaknesses
in the system, plenty of indications
of things that we could do.
So before we look at some of those,
what we're going to do now is focus on application layer
securities.
So even though we know there are other vulnerabilities
in this module, we want to focus on the web application for now.
So try and ignore all those other vulnerabilities,
but they're just there for your convenience.
So if I was to minimize these now, what we could do
is we could load up a Burp Suite.
Remember, Burp Suite is a free--
there's a free edition of Burp Suite.
But they also have a paid-for edition, which I highly
recommend actually, as the active scanner produces
some phenomenal results.
But we're going to show you how to do similar things
with similar open source tools.
But Burp Suite now-- when you run Burp,
you see it comes up with the default configuration.
And it's around $300 or something like that.
So it's definitely worth getting a license for,
if you're going to do web applications
and you're going to do a lot of this kind of activity.
But you can, of course, use free tools.
There is a tool by OWASP that achieves the same thing.
And I have a preference for Man-In-The-Middle a proxy,
just because it's cursor-friendly and seems
to run in my terminal quite nicely.
As you'll have noticed, much of the tools
throughout this course we've done from the terminal.
But we can show you some graphical representations
and easier ways of conducting some of these tool tasks
as well.
So looking here, we've got target, proxy, spider,
scanner, intruder.
These are different tools.
Each of these tabs relates back to a different tool
that's within the Burp Suite tooling set.
So we've got here proxy.
We make sure that we've got our proxy enabled.
I go into my options and make sure
that I'm intercepting the server responses as well.
I want to make sure that I can see the server's responses
coming back so that I can manipulate anything
coming from my client and also coming from the server.
So I'll now go to FoxyProxy.
I'll enable FoxyProxy to turn on the proxy for my local host.
I've specified 127.0.0 for my proxy service.
And I'm now going to connect to this web page.
And if we look at my proxy service,
we can see that I've got an intercept,
and it's intercepted a request to that website.
And here we can see the actual get
request that my web browser is sending,
and then the response that comes back from the server,
and the various additional responses that
would follow from there.
So we can see here, we've got this intercepting proxy.
We can make requests.
And we can see what those requests are.
And if we want to now click on the target,
the target provides us with a visual way
to represent that web application or website.
So what I'll do is I'll click here to filter.
I only want to show items that I've actually requested.
If you notice, there a number of gray items.
So by default, as web rendering content and html and markup
languages returns to Burp, it'll pass through
and identify any kind of hyperlinks or external content.
And whilst it might not request it,
it will gray out and say there's a reference to this somewhere
and we can hide that.
So what I'm going to do is I'm just
going to remove those because I'm only interested in looking
at the website I'm targeting.
So this is everything my website is doing at the moment.
So here we can see visually I've got
a tab that allows me to click on this window pane
and visually represent the file system that might be
in use on the web application.
So I will disable my proxy service,
disable my intercept to allow me to browse
the website without any issues.
And a common hangup I see here with our students
is that they have an intercept enabled,
and then they can't browse the web.
And they're clicking millions of links,
and they end up with lots of web requests skewed because they
haven't cleared this intercept.
So they will still manually need to forward each request.
So if you find that your browser sticks,
remember to make sure have you got your intercept on or off.
So I've got my intercept off.
Maybe I'll try things like, well,
let's request the new password.
And if you recall, you can see this q equals user password is
part of the password reset.
A Drupal-- we may have used that string in the user
module to try and find servers running this software.
So that indicates we might be looking at a Drupal instance.
And we can see we've got use and inputs.
We've got some fields here.
And these forms, these are areas where
we would be looking to inject some content to try and cause
some malicious input for an attack known as forms
poisoning, where we try to feed malicious input
into the parameters and variables that are supplied
to some server side function.
So clicking on there, request new password--
if we now go back to our target, what we can see on our target
now is that there is, in fact, more parameters.
We've seen like the name.
We saw the request that we just made.
And we can see that it's actually
trying to build up information about what we're doing.
So you can see we've got this little cog here.
The cog informs us that this is an application of some sort,
that it accepted data from the user.
And then this example of a message
here with a little icon, says it posted
this information-- it sent this information to the server.
And if we look down here, we can actually
see the kinds of information that
are being sent to the server.
We can actually see the requests,
and we could try to tamper with them.
And if we were to right-click, we
could send it to, say, a repeater.
And we can make lots of changes to it
here, send it to the server over and over,
and keep experimenting with one particular function.
But at the moment, what we want to do
is we want to get an understanding
of the site and its structure.
So the way that I do that is to browse along the website,
have a look what's going on there.
We can see we've got some keywords.
We can run some other tools.
We can click read more down here.
We've got a search function at the top, which is quite useful.
I always look at search functions as a possible way
to target an application.
And we've got the ability to leave some comments here as
well, which also includes plain text and html comments.
So fairly standard functions you might see on the website
So we could leave a comment here.
And I'll put my name, ponies suck.
I'll my put my name-- an evil name,
Luna, You Guys Suck, I Am the Night, or something like that.
And we'll just leave a comment just
as an example preview for instance.
Hit the Preview button.
And if we're now looking at our target module,
we can see we've started to build up a folder structure.
We can actually see some of the included script contents.
We can actually look at some of the JavaScript
that is dependency on this application--
this application makes use of.
And we can start looking through these
for things like cross-site scripting vulnerabilities
by finding user input that is reflected back on the page
or having a read through on how JavaScript interacts with that
function.
We can see here it's using jQuery and various other text
areas.
But what's important is to see that
by browsing the website with the proxy enabled,
we're now building a map of the site.
Well, this could take a long time to do manually.
So what we could do is then enable a spider
to open all of those links that we saw
and access all of the content on that website.
So I've turned the spider on.
And if I was to right-click now on my target and say, well,
I want to spider this host--
include it in my scope.
Turn the spider on.
And now what will happen is the application
will browse through all of the possible contents
and hyperlinks, find all the forms,
find all the areas of the application
that it can, and it will spider through it
and identify all of the areas where we could send some inputs
and all of the kind of program functions or any linked data
that we might see.
And we can see here we've got things like Pony app.
And we can see here we've got Pony app.
We've got some profiles.
We've got a robots.txt file.
If you recall, we can recall robots.txt,
see what was contained in robots.txt.
And inside of robots.txt, we can see
there's some disallow entries, which include Cron
and, interestingly, some install files.
So we can have a look at some of those files,
see what information is in there.
It looks like we've got something like changelog.txt.
So I could go to that server, have
a look at the changelog.txt file at what's installed.
So let's have a look, changelog.txt,
see what that says.
And this is an example of someone
not removing non-production content from a production web
server.
The idea would be to remove these kinds of files
as they are a little bit in excess.
You don't need these kind of install of files
or the changelog files or these README files.
So these have been inadvertently left on.
Also, we've got an XML-RPC endpoint, which
is not supposed to be mapped.
So we could try to communicate with the RPC services
in the web.
But we're going to focus now on mainly application layer
security vulnerabilities.
So looking through here we can see a whole load
of different functions and folders
that have been opened up.
And all of the ones of the cog are
ones that we would be interested in exploring and seeing
whether or not there are vulnerabilities
or sending messages.
Can we cause 500 errors on the server or similar?
So going back to our thing.
We know, it's Drupal.
In fact, we know the version of Drupal
to be 7.21, which is out of date and vulnerable
to known attacks.
And indeed, newer versions of Drupal
are also vulnerable to another second exploit,
which you can find out about by googling for Drupalgeddon2.
It's a very simple command injection vulnerability.
But looking through here we can see we've got some--
this server isn't vulnerable to that.
But we have got some inputs and some things to do.
We could see if we previewed a comment,
it says Luna left a nasty message to the ponies.
She needs to stop stealing the night.
And if we saw here we could maybe do things like search.
We can actually see we could fill in some content here.
So when we see this search box, a search box
is a prime candidate.
And one of the things I would check for something
like cross-site scripting.
And the only way-- the simple way of doing that
is to simply inject some kind of html email content or rendering
content that would get redisplayed to the user.
And if I click search on that and then do right-click search
on page or have a look at the response,
look at what's actually come back from the server when
I do a search.
And then look in the page source search for the string
that I just supplied.
And you should be able to see that the page it uses that word
to generate some of the content, but it
doesn't contain away from me.
You see it's encoded.
It's actually encoded those special characters.
It hasn't made them as just the regular text on the page.
So what we would be hoping for is, instead of a percent 22,
we would see a little speech mark,
and then we would be able to add our own html content here
and disrupt the rendering of the page.
So OK.
So the search box doesn't appear to be vulnerable.
There's a username and password field box there.
But once I've identified a search box,
let's say, OK, well a search box is an area that
would be of interest to me.
So I would want to test it for vulnerabilities,
test it for weaknesses.
And we'll show you an automated way
of doing that once we've looked at some
of these vulnerabilities as well.
So scrolling down here, we can see we've got this victory.
We saw that there was a comments area.
And something about the comments area
struck me as very odd in that you
would be allowed to leave a html comments on a page.
So in this example here, I could put your name.
And I'm going to put Ponies Rule.
Subject, ponies are awesome.
Comment, ponies really are awesome.
And then I'm going to add in here an additional tick.
And then I'm going to do a right angular bracket.
And then I'm going to do a left angular bracket.
And I'm going to add the word--
I'm going to add h1, increase the font size,
and I'm going to add that same-- and in fact, I'll
add h1 like this.
And then if I click--
leaving that as html input formatted, if I
was to click Preview on the--
you can see that my preview of my message
actually shows that it's made my text slightly bigger.
So I could actually try and inject
maybe some JavaScript in here.
So I'll add a script tag and a simple message alert,
which then closes that script tag to try and inject
some JavaScript into this web page when
it is rendered by a user.
And I'm not saving it on the page,
I'm just using the Preview function at the moment.
It's a preview.
And you can see here I've got JavaScript
executing in the context of that web application.
So this is what's known as a cross-site scripting
vulnerability.
And it's a persistent cross-site scripting vulnerability,
because if we can save it to the page,
it means anyone viewing the page can load our JavaScript.
Now many computer hacking courses
will basically demonstrate this to you
and then give you a kind of context of it.
And we're going to do is show you how
to use this to breach systems.
So cross-site scripting vulnerabilities
can be used to actually leverage the brand and the reputation
of a website.
So when we find cross-site scripting vulnerabilities,
we're going to try and use them in some kind of attack.
And I'm just going to disable my spider,
otherwise I'm going to be pestered with pops-ups in Burp.
So once that Burp comes up again,
I'm going to get pestered non-stop by Burp.
Ignore form, see if it's gone away.
OK, I'm going to just kill my Burp session for a second.
OK, so what I want to do is I want to click spider.
I'm going to turn off my spider so I
can get rid of some of these annoying pop-ups
that I've been getting from Burp, and submit that form in,
and that should hopefully go away.
So that's got rid of those pop-ups.
So going back to our application now,
we can see we've got various post requests.
We've found a cross-site scripting vulnerability.
What we're going to go use now is a tool called BeEF.
You'll have to configure BeEF.
And you might need to do that by going to your BeEF XSS
directory.
And in here, you'll find a config.yml file, which
will allow you to enable different things like usernames
and passwords, et cetera for starting and stopping BeEF.
And in newer versions, I had some issues with BeEF XSS,
so you might need to configure this file correctly.
So I've done beef-ssx, and this has then simply
started a web interface panel.
I'm going to show you a little bit about how
you could use JavaScript to perhaps try and breach
someone's network connection.
So we're going to go here and go to the user interface.
And the default was beef.
And in fact, I believe that newer versions
would set a non-standard username and password.
So I can log in as beef beef.
But on slightly newer versions, there's been some changes.
And in fact, I believe it generates a password
automatically for you, and you may
find that you need to copy and paste the password when
you set up BeEF manually.
So in here, we can see we've got an example of BeEF.
I'm going to minimize this now a little bit.
So we've got rid of this.
This is from a previous demo.
I'm just going to get rid of this by clearing it,
delete this zombie so we can see here
and what we've got with BeEF.
And I'm going to click on online browsers.
So BeEF basically gives you a JavaScript agent
which can be asynchronous.
It will do some fingerprinting of any web browser or page
that it's loaded into to determine information
about the connecting client.
And it does get detected by anti-virus,
so you would want to try and customize or obfuscate this.
But it's just showing you what's possible with some kind
of JavaScript or a cross-site scripting vulnerability.
And it allows you to highlight risk much more effectively.
So once you've got your JavaScript agent
into a page, what would happen is any web browser
that loads that page will become available to you in BeEF
to be able to run commands against,
including various exploits and other attacks.
And we're going to show you now how this would look.
So if I'm on this page here, we've
got ponies are awesome, what I'm going to do
is I'm going to put my name.
I'm going to leave my [INAUDIBLE]
I'm going to leave my ponies a cool subject.
Awesome.
And I'm going to put the message, I love your website.
And then I'm going to add the script tags that we saw here
in this example.
Now these script tags will try to load in this hook.js file.
And this hook.js file is simply a JavaScript agent,
which will then communicate with the BeEF interface
to allow us to send commands through JavaScript
and control a browser through cross-site scripting.
So by simply leaving a comment on the page that says,
I love your website, I'll click Save, see if that actually
saves to the page.
And you can see here it says, I love your website.
Doesn't show anything else.
And if we go to BeEF now, what we can see
is we've got an online browser, and this JavaScript is hooked.
So now whenever we go to this page,
whenever anybody browses to the comment page of this website,
they'll have a little piece of JavaScript
loaded into their web browser that allows me to interrogate
their browser and attempt to launch attacks
against that person.
So we can see there, I love your website.
And this has loaded a little piece of JavaScript
in the background, which is now able to communicate
with this BeEF system and allows me to send commands.
I can use this JavaScript to send
some commands, such as try to send exploits from Metasploit.
You're required to set this up, but you could even
try to exploit missing patches in the browser.
And I'm going to try this.
It's a social engineering attack,
which you may have come across on the internet already.
And what I'm going to do is send a fake flash update
to the remote computer.
I could simply add a link to some malware in here.
And then I can send execute.
And if we look at our web browser--
if we go to our web browser on that web page, what you'll
notice is there's a little pop-up box has appeared
that says, you need an update to Flash Player.
And if I was to click this now, it would download malware,
and I would mistakenly believe that that was a Flash Player
instance.
So this is a way in which you could try to target people
who browse specific websites and how you
could reach users of websites.
So cross-site scripting, it can impact
on the users of the websites.
You can use it to steal information.
You can use execute JavaScript.
So you could read things like session cookies.
But most importantly you could also
use it as part of an actual breach as a social engineering
attack.
And I use cross-site scripting combined with phishing attacks
to try and send email links to companies or spoofed emails
to make people trust in a brand.
So let's say I find a cross-site scripting in the company home
page.
I'll say, click this link, and they'll click on that link.
And I'll try to exploit their system that way
or even just send a little pop-up that says you need
and update, things like that.
So cross-site scripting obviously has an impact.
And subsequently, it's one of the most commonly
found vulnerabilities for bug bounty programs.
In fact, I know some hackers who make a great living just
by scanning the web and trying to find cross-site scripting
attacks and new variants of cross-sites scripting
to leverage these kinds of vectors.
Well, that's why it's such an issue.
That's why we can see why cross-site scripting can
be used as part of an attack against the website
or its users.
So not only the things that we see on there,
we can see various other things.
We've got these comments.
So if I was to say, well, how would I
want to find other vulnerabilities like that?
And testing everything manually is going to take some time,
so I'm going to look at doing this in a non-manual way.
So I'm going to go, OK, well, I want to automate this.
I don't want to sit here all day sending stuff into websites.
It sounds painful.
And I also don't want to buy a scanner,
so let's just use some other scanning tools.
So if I was to say, for instance, enable my intercept,
if I click search, we can now see that there's
made a intercept request.
We can see the hooks that are going
back and forth through BeEF.
So we can actually see the BeEF intercept going on.
And here we can see we've made a search request.
We made a POST request to that server
containing all of these http parameters
that we can now manipulate.
So if I was to send these to the repeater,
you can see that I can now experiment with that search
form and just send any kind of inputs that I wanted.
In place, I could change my visitor name
to something like ABC, try and change my session cookies,
maybe remove my BeEF hook.
You know, see what information I can get back from that server,
see if it will accept any pages.
And each time I'm doing this, I'm trying a search request.
And all it's doing is it's just using a 302 redirect
and including that information in the redirect.
So I could try, well, what happens if I do like this?
Does that make it any better?
And you can see that this would then come in off the redirect.
And it's successfully re-encoded it as well.
So it's properly checking for cross-site scripting,
even if I send it directly.
So I could try slash r slash n maybe, see
if I can inject into the header.
Hacked into the header.
And again, that's probably been escaped.
It hasn't allowed me to send slash r slash n,
so I can't add my own headers.
So it doesn't look like I can do much with that.
But what I could do is right-click and send this
to the intruder to try to fuzz it,
to see if there's any ways in which I
could break this application.
So what I could do is I could use the fuzzer,
and instead what I'll do is automatically
change different parameters by selecting it.
So I'll go here.
I'm going to clear everything that I don't want to select.
And I'm only interested in, let's say,
scanning that search parameter.
So I would do clear on here.
And I've got my search parameter.
I click on my payloads.
And I will load into my payloads.
I would add in here.
So in the paid-for version, you can load in from a list.
But in here I would add all of my different strings
that I would think might induce errors in the application.
And building a collection of these
can be done by going to a website,
like owasp.org and finding for access XSS filter evasion.
You could put all of these strings into--
and searching for that, you'll find
there's a proxy in the way.
So it's going to error at the moment.
So I'll just do--
turn this off for a second.
Here to click on Filter Evasion Cheat Sheet,
you'll find various strings that could
be used to trigger cross-site scripting vulnerabilities.
And you could feed all of these strings into that function
and see if any of them responded,
or if you've got the correct parameters back.
So you could load in a big list of payloads
and then you've got your positions.
And all this positions is going to do
is it's going to swap everything in your list
into that positions block and give you
the response from the server.
So simply clicking Start Attack.
And you can now see that it's giving us 302s.
And we're actually being able to monitor the server's responses.
And if we saw a 500 or some other similar error,
we would investigate whether or not
that was a potential vulnerability.
So that's an example of how you could
use a very basic fuzzing or fuzzing-like utility
to just send common strings in, see if the application
behaves in a weird way.
Mostly, http 500 errors are bad news.
But you might find also 200 OKs with your content in there.
And that's when you're looking for kind
of cross-site scripting and other things.
So digging through those, go through your results.
Now obviously the paid version of this tool
has a scanner, which can automate
some of that process for you.
And as I said, we'd look at some open source tools.
So one such tool is a tool called
Skipfish made by a chap at the Google Security team.
And they have their Skipfish web application scanner
which you can use to scan web applications for kind
of common vulnerabilities.
And the way you'd do that is, I think, just
providing the URL on the command line.
Output directory not specified.
So I need to give it an output directory, which
is 0 output dare.
I'm going to put output web app.
And it says, welcome to Skipfish.
And you can set various options.
And what Skipfish will do is it will actually
connect to that website, try to probe all of the different end
points.
It will fuzz through it.
And it will kind of automate that process
of finding areas of the application that accepts input,
feeding in various different inputs,
trying to see if the application will result
in any kind of vulnerabilities.
And it will then produce you a html-formatted report.
So this is a tool developed by Michael Zalewski,
a former CSO at Google.
And it's a very, very capable tool.
It's really interesting.
It's kind of like really nice as a scanner.
And best of all, it's open source and free for your use.
So we can have an experiment around with that.
And that's it.
That makes up for not having the commercial scanner in here.
However, I would recommend that commercial scanner
as it is very, very decent and finds
me all kinds of useful issues.
And often, I like to do both.
I like to do the manual processing--
the manual fuzzing, review things by hand.
And then I like to use these automated tools to just ensure
blanket coverage.
And an important thing to note on automated tools,
do not ever use automated tools in an authenticated state.
And what I mean by that is if you
were able to log into this application
and you had sufficient rights, and you
were able to interact with this page,
and you logged in as a user, and then
you gave these credentials to an automated scanner,
you have no idea of what functionality this website
might have on the back end.
And you could inadvertently scan a function that
says drop database and you could clear the database
hundreds of times and be unaware because your automated tool has
just clicked a very dangerous link because it
got admin rights.
So you want to be careful that you don't give it
too much credentials-- you don't give it too much permissions.
Use automated scanning tools, but from the perspective
of an unauthenticated attacker.
If an unauthenticated user can drop your database, then
you obviously have a very serious problem,
and that shouldn't be blamed on the individuals doing
the assessments.
However, I would recommend that you use automated testings
in an authenticated state sparingly,
and instead revert to manual testing.
And look for the functions which you believe
would link to a database that would
be vulnerable functions-- so username,
password, search queries.
Comments perhaps maybe not as much,
but you would still look there.
Certainly wouldn't look at a function that said delete users
or anything like that.
OK, so we've got some cross-site scripting in here.
We've demonstrated how to use cross-site scripting.
We can also see some other standard infrastructure
attacks.
And just down here we can see that there's
a little blurb about this website
where it says, hello, every pony.
And we can simply click example.xml.
So you have a look at this website, which gives us
some information in XML.
So it looks like there's an XML portion of this website.
So we see XML.
We could have a look for other kind of weaknesses in there.
And we've also got Derpy has been working hard
at making a new Pony app.
So we'll have a look at Derpy's Pony app, which
is a very simplistic count for displaying
a picture on a website when you click a number.
So when you click a number, it will display a picture.
And up here at the top, we can see
the request that's being made to the website
and various options.
So here we will now try to have a look further at those.
So we've got this XML file.
And we've got here some Pony app file.
OK, so we'll start with the Pony app,
and we'll look at the XML at the end.
So for the Pony app, we can see we've
got an ID parameter and a file name in an image argument.
So if I was to click 3, and we can see ID equals 3
and image equals Pinkie Pie, and it says, computers are awesome.
If I was to change this parameter to a 2--
ID equals 2-- we can see that the string at the bottom
here has changed, but the picture is still the same.
So it's quite likely this ID equals
2 is related to a database query in some way.
So we can see here that ID 2 will
return some information from a string, some kind of string.
And we can try here ID equals 4.
There's nothing for ID equals 4, but what
I would try there is perhaps add a little tick, see
if we get a tick.
Nothing happens on the tick.
And then I'll try also space or 1 equals 1
and see if I get anything with that.
And when I've done 4 or 1 equals 1 and some spaces,
you can actually see here that it's output three strings.
And it says Derpy says, hi.
Rainbow Dash and computers are awesome,
which are all three strings related to that.
So to me, that looks like a SQL injection vulnerability.
We're able to cause or induce some error.
And even though it's a slightly different rendering
on the page, that may be all the indication that you've got.
Maybe the behavior of the web page changes slightly.
And then simply adding a statement
which would return as true or 1 equals 1
will give us back some additional information.
So here we've got a SQL injection in this ID parameter.
So I would want to explore that SQL injection
vulnerability further.
And I'm going to do that by sending this to the repeater
so we can explore further how that function works.
So here we can see a request for this Pony application.
It's got a parameter here that says ID,
and then we've got a file named image.
And I'm going to send this to my repeater.
I don't really care about what's happening on the web page now.
And in my repeater, you can see I can
change my parameters around.
And I can see what the responses are
and what responses I get back from the application.
And indeed, you can see this Derpy says hi at the bottom.
Maybe if I try to remove this image
and see whether or not I can still get the response back.
And you can see it says, you need to supply an image.
So I'll just give it an empty image.
And you can see if I give it no empty image,
we've gotten less text to wade through.
And we can see we've now got the output of those strings.
So what I would check for now is whether this is a stack SQL
injection.
If it was a stack SQL injection, I could simply do a semicolon
and then do select at at version to see whether we can
stack our SQL queries together.
And we see that we haven't got any information from that.
We didn't get any data that we wanted.
And that's because I had a whitespace.
Space.
I need to put a plus instead of the whitespace,
see whether we got anything back there.
And you can see that it seems to have run,
but we haven't actually got any information back.
There's nothing at 4, so let's try 2, see what happens with 2.
And you can see here that it doesn't
look like stacked queries are working.
So we'd try a union, see if we can
do a union select at at version, see whether or not
we can actually do a union injection,
and add additional SQL statements into this query.
So here we can see-- now it says I need to supply the image
tag as well.
So I will try--
let's try pinkiepie.png again.
You need to supply the image and ID.
1 plus union select.
The user file of the image and ID.
OK, I'm just going to do it in my browser
here just to ensure that I'm not losing my mind-- at at version.
And you can see in my browser here it's actually returned
back 5.1.73-1.
So it's actually done a union injection
and done union select at at version,
and returned back the version information of MySQL
in the web page.
If I was to unbalance that query by adding an additional column,
such as null, and then we were to conduct it,
we can see that that's now failed
because the number of columns returned from the initial query
is different from the union query.
And then a SQL-related error has returned,
so we have not been able to review a second column.
So we've got a single column union injection
that we can then leverage in this application.
So when we've got a union injection, what we would do
is we could--
when we've got SQL injection we can do everything that we just
did on our database module.
So all of those same attacks getting access
to files, executing commands, we can do all of that
through here.
So we're going to do that now.
So if I was to do--
the first thing I want to do is union select schema name
from information on schema.schemata.
I'm going to return a single column of information
from the database schema table that contains
a list of all the databases.
So here is the same as doing the show database commands.
We can see information schema, Drupal, MySQL, and pony.
So I would then do OK.
Well, I want to know what the tables are,
so I will do union select table underscore
name from information underscore schema.tables where table
underscore schema not equals.
And in fact, MySQL and table underscore schema not
equals information schemata.
So we will now have a look at all of the names of the tables
that exist in the database that aren't in the default
databases.
And we can see we've got all of the Drupal ones.
And also at the bottom here, we've
got a pony picks and pony user.
So if I wanted to look at a specific table,
I could say where tables schema equals
database equals pony maybe.
And you can see in pony--
the pony database, we have two tables, pony picks
and pony user.
So again, there's some reference guides.
And page 12 of your reference guide
has got some helpful references for doing these SQL
injection related attacks.
And indeed we're going to carry on now.
So we've got access, and we can see the tables.
Next thing I want to know, I don't know what kind of columns
they've got.
So I'll do union select column name from information
underscore schemata information schema-- sorry,
.columns where table underscore schema equals.
And I'm interested in the columns in the pony user table.
So let's have a look at those.
So I've got where union select column name
from information schema where.
Table schema perhaps should be column schema.
Nope, from information schema.columns.
And I'll just list all of the columns in the database.
We're looking for the ones in the pony user
and pony picks data table.
So I'll run those.
At the bottom here, we should be able to see somewhere
in here pony user, pony picks.
And we want the actual columns from there from information
schema.columns where table underscore schema not equals
or equals--
does that work like that?
Pony user-- see if we can get it to--
no, it doesn't.
So it's a table schema.
I want where table schema equals pony.
So that would list all of the columns
in the tables of the pony database,
but not specifically which table they relate to.
And in fact, we can see there's a username and a password
column, which username and password
column are likely to be in the pony user table.
So if we wanted to now have a look at the username
and password field, we could do select password from pony user.
From pony users.
Password has two s's.
OK, so union select password from pony user.
We can now see cupcakes, best pony, yee-haw, and AFDSFS.
So we can actually see the passwords that
are specified in that table.
And we could also do select username from pony user.
And we can see Rainbow Dash, Applejack, Derpy, and Pinkie
Pie all have passwords set in that database.
And I'm guessing that you could probably work out
that Applejack is yee-haw.
But anyway, that's an example of a SQL-like injection-- a SQL
injection.
And what you do a SQL injection is the same as you
did in your database module is to enumerate the database
schema to learn information of the database--
profile the database.
And from here now we could do the same kind of attacks
that we saw previously.
We might have to mung the turned responses,
but we do our load file.
We could try to read files from the remote system.
We could actually write files to the remote system.
We can try and misuse this system in some way,
and try to upload and download content, and do other things.
And we could add a user-defined function,
and we could turn this into a code execution attack as well.
So that was a lot of work, right?
Doing all that manual process probing through it.
So I'm now going to introduce you to a tool called SQLmap.
SQLmap is meant to automate the process
of doing that manual step.
So I like to show you this tool after doing the manual steps
because people become very reliant on tools
when they do automated things.
But SQLmap is a tool that was run by a 15-year-old school
child and successfully knocked to several million pound
valuation of a insecure company here in the UK known
as TalkTalk, which consistently seems
to be at the forefront of numerous consumer-related data
breaches, which seems to be very unfortunate for them.
But the way that this happened was because a 15-year-old was
able--
while he was playing Xbox with his friends,
he simply ran this tool and subsequently
was able to steal information from TalkTalk that
cost it several million pounds.
So if I was to do c python sqlmap--
oh, sorry, just sqlmap by itself.
And do then minus h, and you'll get your help output.
And SQLmap that will include various functions
for trying to automate the process of SQL injection
attacks.
I'm going to just clear my previous SQLmap entries,
make sure I've got nothing lingering around.
And this can take a few moments once it's
profiling a vulnerability until it's ascertained
all of the best possible ways.
And it contains checks for all kinds of variations
of SQL injection attacks.
We've shown some very basic ones here,
but there are more advanced ones that make use of timing.
There are more advanced ones like blind SQL injection
and even others that can be used.
So this tool here we will now use
with one argument, which is u.
And we're going to simply give it
a URL that we think is vulnerable to SQL injection.
And we're going to remove evidence of our SQL injection
attack.
And I'm going to make sure that I get a clean one.
And I'm going to use Pinkie Pie.
And the reason I'm going to use Pinkie Pie
is because of an unrelated vulnerability in SQLmap
that if you return a large chunk of data in the web page,
you can actually break the functioning of that tool
just as a pro bono for anyone out there
that's interested in that.
If you try and run SQLmap against this,
you'll actually fail on some of these other images
because the page content is too large
and it causes SQLmap to fail.
So very interesting that you could
break that tool's behavior.
Anyway, you can do SQLmap minus u, supply the URL.
And I'm supplying it with the Pinkie Pie URL.
SQLmap minus u.
Then supplying that in there while effectively
trying to probe these two parameters using heuristics,
which is behavioral analysis.
It will try to ascertain whether or not
that URL is vulnerable to a SQL injection attack.
You can explicitly state that it is once you've confirmed.
But SQLmap is usually good enough
at picking it up that once you've confirmed
the presence of a SQL injection vulnerability,
you could then use SQLmap to try and automate
that process of enumerating the schema
and extracting the information.
It will take all the legwork and the hard work out of it.
But it also increases noise.
So if you were doing this and you're trying to be stealthy,
and you're trying to not get noticed,
you would certainly find that running SQLmap someone
somewhere might notice.
Because they'll be a lot of errors.
They'll be a lot of data in the logs,
and you'll be sending an awful lot of requests.
While it does a lot of probing and weird behavior,
that isn't standard for most normal web users.
So you would definitely not be discreet.
But anyway, it does automate this behavior.
And on a legitimate authorized security test,
it certainly allows you to take advantage of the fact
that it has so much functionality
and is able to detect so many variants
of different kinds of vulnerabilities
and on different databases.
So although this was a MySQL injection vulnerability,
if this was a Postgres injection vulnerability,
you would have to query those tables
and do that information in a different way.
There are different steps based on each different technology
that you come across.
But that's an example of MySQL union injection.
And also on here we saw there's an image equals tag.
And we're going to explore that now
while we let SQLmap run in the background.
SQLmap can take some time to get the heuristics right
for this site.
So I'm going to leave it running while we
explore the other vulnerabilities on that page.
So we'll go back now, and we'll go back to the union.
So we've got our simple get request.
Sending a go request here.
And in fact, if you see it go request--
now we can see there's an image equals and a file name.
When I say image equals and a file name,
if you look at the page, what you see on the page
is that you're getting a file back as part of that web page,
but it's encoded.
It's encoded with something called Base64.
And part of Burp's tooling is there's
a decoder in there that allows you
to decode this Base64 traffic.
You'll be able to decode different kinds of encoding
schemes and compression to see what kind of content
was actually inside of it.
So if I was to see a page like that
where I've got content being loaded
and it's returned in the page, I would try and maybe
see if I can access that content some other way.
And I would try for things like directory traversal attacks
and see what happens then.
So if I give it non-existent file,
we can see that now we've got no Base64-encoded data.
And then the file was never opened.
There was nothing that supplied there.
So if I was to now supply a directory traversal string
and see if I could request the password file,
you can now see that I've got some Base64 encoded data.
And if I was to select that data, if I copy that
and paste it into the decoder, you could do decode as Base64.
What you can see here is, actually, I've
been able to request back the contents of the password file
because this application is also vulnerable to a directory
traversal attack.
We can download files by decoding them out
of the web page based on its behavior.
As an example of a directory traversal attack,
another thing that you could use--
and when you find files like that--
directory traversal attacks-- you're obviously
going to try and get yourself configuration files.
You want to find passwords.
You want other bits of data and other useful things
that will get you into systems.
So we're browsing back through our response.
We know that there are other weaknesses and issues in there.
We saw in the changelog there was some out-of-date things.
And we also saw an XML entity--
or an XML area of the page.
So I'm going to go back to that XML area now.
I want to have a look at what's going on with XML.
And we see here, we've got example XML.
So I'm going to intercept now.
I want to see what this XML page is all about.
And I'm going to send an XML request to this remote web
server.
And you can see it says a get request query equals
XML of slash node.
So I'm going to send that to repeater.
And you can see when I've done that, I'll turn this off now.
I'll go to my repeater, send a request for that node.
And what I get back is I get a back page that looks like XML.
So I've got some XML response.
And if I look at my application type,
I can see it says application XML.
And I've got somewhere on the server that's returning XML.
I don't want to return XML, I want to send XML.
So I'm just going to change out to POST.
I'm going to see what it does.
And when I send a POST request, I get an error that says,
could not find the controller.
OK, so maybe I don't have the controller.
So I'll just try and change these arguments a little bit,
maybe we'll remove the 2 and try again.
And here we can see it says, not acceptable, unsupported request
type.
So I haven't at the right request type
to get it to support that.
So I'm going to do content type add the right request
type of XML.
And now we can see that I've got a response that
says not acceptable.
So whatever I've sent is not acceptable.
I know I've got a response from XML that says here is a result.
And I've got no information further than that.
But it looks like the server has expected
me to provide some kind of XML.
So that's what I'll do.
I'll provide XML that says blah slash blah.
So here we can see the XML preprocessor has now said,
not acceptable.
It doesn't like the request that I've sent.
I'm just going to have a look through here
and see what else I can get it to do.
So Drupal visitor.
Remove that.
Remove the cookie.
Remove accept language.
And I'm just clearing out some of the things,
like except flag, things that we maybe don't need.
OK.
I've unacceptable.
But this time in my unacceptable error,
I just got an empty response.
Now I'm sending a not acceptable,
and this time I've got an error that says line 2
column 1 star tag accepted.
So now I'm getting errors from the remote preprocessor.
I'm actually getting it to accept my XML.
If I added the star tag, you can see that the application is now
attempting to handle my XML.
It's got no errors coming back.
It's just said unacceptable.
So I can try to send XML to this website and get it to--
get to a parse XML, and get it to use it
through an XML preprocessor.
And then we can try to give some directives
through that preprocessor and make it do things that it
shouldn't be able to do.
So we wanted to look at this vulnerability in a real world
situation.
So we used the bug called Synactive that you can
basically download our version of the exploit from
static.hacker.house/stuff.
And we have a Drupal-CVE-2014-3660.
So if we were to copy this link here--
Wget this exploit.
This is an automated exploit for exploiting this vulnerability.
But also we're going to use xs epoch
because I'll need to have a look at this vulnerability manually
as well.
So if we Wget this and paste it.
So here we can see we've XML, it's a proof of concept here.
And you've got this doc type.
And inside of this doc type is using PHP filters,
and then it's encoding Base64.
So actually what you're getting is
you're using a PHP filter to cause
it to parse two pieces of XML.
And you'll get the error from the first parse piece of XML
in the response using this trick.
So if you review the paper by Sysactive,
they explain how this attack works.
But just to show you what I mean,
if I was to take that request from data here,
all this is is actually using two XML external entity
injections combined together with a PHP filter
to try and encode it past the Drupal application.
So if I go to decoder, select this here, paste that in,
you can see we've got a second entity inclusion which was part
of a Base64 encoded string.
So what's happened in here is it's
using PHP filters to encode XML and then
have that XML processed effectively twice, giving us
an error.
So if I take this tag in its entirety,
if I was to now copy this, what we should get
is the files that it's tried to request.
You can see it's trying to request the et cetera password
file.
And it's going to pat those out through tags that say woot.
So if I send that request to the server manually,
you can now see that the server's come back,
and it says failed to load the external entity.
It was unable to load an external entity.
And then it's included the contents of the file instead
of the path to the file.
It's actually been able to read the file,
include it through the PHP filter,
and subsequently display it in an encoded way.
And if I was to put that through a Base64 decoder,
you can see that that will decode back to the password
file on that system.
And if we were to take that Python script that we have
there, this is basically the basics
of exploitation development.
We found a vulnerability there that we could use.
So you write a simple script-- or a Python script
that automates that process, that
allows you to run this attack against that server.
So if I was to do Python Drupal, run that attack
against the server, do minus h, add
the IP address of the remote server,
and then add local or remote.
And I do believe that you need to do Python 3-- it should
be my defaults-- at local, and then I
think the name of the file that you want to download.
It might even take an argument like minus--
take the minus h off.
And it will say it needs choose from local and remote.
Invalid choice, which I've chosen.
So it says there give it the URL, which I've given.
Oh, and then I need to give it the file.
So I'll do http://192.
And then I'll do minus f, and I'll
download the password file.
So all this script does is attempt to use--
I'll try it with Python 3 just on the command line,
make sure it's running the right version.
So it uses that vulnerability that we've just
looked at there.
It sends those requests, and it automates that decoding
process.
So you can just supply a password file
and then read password files off the disk.
So that's the sort of thing that you
would write when you targeting a web application.
When you find a vulnerability, you
could then use a bit of Python, a bit of script
to kind of improve it.
So you don't have to manually do things all the time.
And then you can share that with your team and your colleagues
and be able to access files off that system, et cetera.
So that's how exploiting a vulnerability.
This one is an XML vulnerability-- and XML
preprocessor that's triggered through LID XM-L2,
and is a CVE exploit for it there.
So looking through that, we can see here we've got scanners.
We've got proxies.
So we've had a look at XML entity injection.
We've looked at SQL injection.
And we've looked at cross-site scripting attacks.
And now we're going to look at some of our automated tool
output.
So we can see here we've got heuristics are being performed.
It shows that the back end database could be MySQL.
So SQLmap is still running.
It's finding stuff.
It's seeing get parameter appears to be
and Boolean based blind where or having cause.
So it's still doing this behavioral analysis
of that web page.
Skipfish is still running along.
And eventually Skipfish should output a file here,
which I think was web app.
I'm not sure where I've actually run the Skipfish file.
Slot idle.
And this we've basically produced a report
where any kind of issues that it might have found,
any kind of probes that it has found.
So I'm just seeing if it will actually do it.
And says it saved the report.
As you can see here, we've got this web app file index.
And I've actually put it in the wrong folder,
that's why I couldn't find it.
So I'll do tilde Hacker House.
Just move it out of my BeEF directory, get to Hacker House.
OK, go into the web app, and then I
will just open that file, index.html,
so I could do that in my browser here.
file colon colon root slash hacker slash house web app
slash index.html.
And here you can see the results from Skipfish,
various vulnerabilities that it might have seen.
You can see incorrect caching, directory traversal.
So it was even able to find that directory traversal
vulnerability for us and even give us some information
about exploitation.
And if we'd have left this running for longer,
it may even have detected other things.
But as you can see, it hasn't found everything.
It didn't find cross-site scripting or SQL.
So it may well be that if you left it for longer
it might find them, but it often might overlook things as well.
So don't just become reliant on automated tools.
That can help you, but they shouldn't replace you.
So you've got there these web apps scanning tools,
and if they're really good tools and they
can replace you, please email me and let me know.
You have all these things like directory listings,
you can learn some information about them.
So Skipfish, that's a way of doing an automated web
assessment, just running some things through there.
So we actually found out that it was waiting
for an input for this to be supplied,
and now we can see that now MySQL tool--
SQLmap has completed.
And we've actually got an example of different injections
that you could use.
So it's showing you here you could use a union injection
using this union string.
It's giving you and/or time-based injection,
and also offering a Boolean-based injection
as well.
So, you can use this to test-- they're like a primitive
to see whether values are correct.
It's also worked out that the back end database is MySQL,
and it's giving me some other information about how
that operates, about that database,
and how to interact with it.
So if you were to now run SQLmap on that URL,
you'll just get back an example of how
to exploit that vulnerability.
And if you were to supply minus minus help, what you would find
there is that you could then interact with that database
and try to retrieve its contents.
And if I was to do minus a, it will actually
try to dump out all of the database contents.
And what it will do is it will connect to that database,
use SQL injection vulnerability, store these temporary files,
and try to do some brute force.
And I'll just say, OK, let it do brute force attacks.
And it will actually extract all of the information
from that database as well and allow me to browse it.
So it will make a full data dump of it.
And this is how TalkTalk were able to have
several million pounds knocked off their evaluation
by a child-- a school child, someone
who was experimenting around with SQL injection attacks
and subsequently caused irreversible harm
to that company.
So this is why we show these kinds of tools
because it is very trivial to use.
And it shows you some of the kinds of things to test for.
So directory traversals, XML entity injection,
cross-site scripting.
Again, you can do an entire course just
on web application security.
But we wanted to cover some of the most common basics,
you know, non-production content and seeing
some of the kind of vulnerabilities,
and how that can be leveraged and changed together.
We're going to look now at some other vulnerabilities.
So, for instance, that SQL injection vulnerability
that we saw, if I was to use MSF console--
so I'm going to now search for different exploits that might
relate to the Drupal instance.
And if we recall there, we could look at the changelog,
and we can actually see that this
is an old version of Drupal.
So we're going to look for any kind of vulnerabilities
that might impact it.
And we can see here versions less than 7.32
have unauthenticated SQL injection, and we have 7.21.
There's also a newer exploit which
is a command injection-- an unauthenticated command
injection that is introduced around 7.24, or 7.25 I believe.
So slightly newer versions than the one we're seeing here.
But this unauthenticated SQL injection
could be leveraged for us to try to exploit a SQL injection bug.
And if we were to search for Drupal in Metasploit,
we can actually see here there is a drupalgeddon exploit,
or a drupageddon exploit, that allows us to exploit a SQL
injection vulnerability.
So if I was to use this exploit--
show options-- again, like I said,
you could do everything you could
do in your database module.
And this exploit here is doing exactly that.
It's taking advantage of a SQL vulnerability
to enable code execution to then get
command shell on the server.
So if to do show payloads, we can now do set payload.
And I'll use PHP reverse underscore PHP
or reverse underscore perl.
And I'll do my show options, set my host, set my port,
and then run exploit.
OK, and we can see here it says it's
logged in as a user, created a valid user.
But it suddenly said no response or response body.
And I wonder why it's done that.
So let's have a look here.
56.3 target URI it seems--
show options.
I'll try that exploit once more.
Unknown response or response body.
Let's see if it's been able to create this user,
see if these users are valid on the system.
As what it does is it uses that SQL injection attack
to add a user into the system.
And then it enables that user.
So we can see we can log in with the user.
It successfully exploited the SQL injection.
It says, in fact, too many failed
IP addresses because I failed too many password attempts.
And that's why I'm not able to use this exploit.
I've actually locked out--
as part of my Skipfish utility, I've locked myself out
of that web application.
And that's why that exploit isn't working.
So if I was to just reset that application,
we can see now that that should hopefully
have cleared the block, reset that server back
to its default state.
And it probably will have--
no, it has not because it's doing offline analysis
at the moment.
But what we've got now is we should
have that web server back.
If I was to run it this time, I shouldn't be locked out.
And you can see it's created that user, enabled PHP filter
modules in the back end.
And then it's created some pages that
have allowed it to cause code execution
and gives me sufficient privileges to that server.
And once again then we could begin
doing our privilege escalation phase
and looking for some of those other vulnerabilities,
weak file permissions, various other things
that we might see in a system that
can result in its insecurity.
So here we've got the ability to execute commands.
That's an example of a SQL injection
vulnerability being leveraged to turn into code execution.
So it's important to check for these kinds of things.
And we've gone through many of the findings on this one.
And I just want to check--
if you were to leave this long enough,
you will eventually get back the contents of the database.
And I want to make sure that we've
covered everything of this module
before we move on to the next one.
So I'm just having a quick look at the port scan output.
And we can see there we covered most of things.
As I said, there are other vulnerabilities in here.
And so for the practical element of this module,
I want you to do some of those web application
vulnerabilities.
I want you to try to use a cross-site scripting
vulnerability to inject a social engineering attack
and trying to trick a user into installing malware.
I want you to try and do a SQL injection type attack.
I want you to try that process manually.
Don't just automatically default to SQLmap only
to manually exploit that SQL injection bug,
view the information in the table,
have a look at that XML entity injection.
And again, try to leverage this server.
And as an exercise, you might want to refresh yourself
on some of those web technologies looking
at Cadaver, Weavely, and other things
that we did in our earlier module.
So this is the web application module practical.
It should introduce you to some of the core concepts.
And as I say, if you want further reading or more
information, you could get any number of resources
from the OWASP security group, which
provides very detailed analysis of different kinds
of weaknesses.
So yes, that would be the conclude--
the end of this module.
And I will look forward to seeing you in the next one.
And just as a weird little bonus before we
move onto the next one, if you downloaded
Heartbleed bin in our earlier module,
you would actually find that we've provided you
with a statically linked open SSL Heartbleed exploit that you
could use against servers, including
this one which we found vulnerable to Heartbleed
before.
And if I was to do the server to target, the port number,
and then just write the file to dump.bin,
loop the number of exploit attempts,
and then do type maximum leak.
And what you'd see here is it's now dumping all of the memory
from that server in a loop over and over to the file dump.bin.
And amusingly, this same code was
used against servers in the Large Hadron Collider.
As I saw some Russian researchers using
this same piece of code to analyze the security
of the Large Hadron Collider.
So a very kind of interesting thing.
This is a little bit of C code I wrote to exploit this bug.
And it will just continually loop over and keep
dumping memory from a server.
And it gives you a little bit more control
over that particular vulnerability.
And if you do hex dump minus c dump.bin,
you'll find now that this will dump out
all the memory of the server.
And you can parse through it for interesting things.
And there's a little tool called keyscan.pie,
which if you use keyscan.pie with Python 3,
you can actually extract--
if it's an RSA key, you can use a factorization attack
to basically recover that private key from the server.
Under Metasploit, there's an action
you can set to dump the certificate.
But you can actually do that manually by following
slides I previously released and use this keyscan tool.
But that's how you could use that Heartbleed
binary to just keep dumping information from a server
and parse through it, and see if there's any secrets in there
or email addresses useful kind of fun stuff to grab down.
You'll often only see Heartbleed, generally,
on internal networks today.
There are some instances of it around,
but it's mostly internal.
So that concludes everything on this module we wanted to cover.
You could also try to attack-- the Heartbleed attack
in our earlier modules as well.
But just as an example, we're now done with this module,
and we'll move on, where we're going
to shift our perspective now.
We're going to go back to an internal attacker.
And we're going to look at Windows Enterprise
Architecture, because it's a slightly
different way of thinking compared to other systems.
So thank you very much for your time,
and I'll look forward to seeing you later.