Day 13: ITSM Vulnerability Assessment techniques

Lesson 13: Just this week, in lessons 12 and 13, we've covered -- at
least partially -- how to significantly reduce risk and vulnerability to
system and network infrastructure. We touched on protecting
applications, but we weren't able to go into specific detail about how
to handle the path of execution to the attacks, only levels of defenses
through functionality.

At the system or OS level, there are functional defenses such as
hardware stack protection and ASLR. Not every operating system includes
these sorts of protections, and not all do them correctly. Sometimes
they can even be subverted. I hear comments all the time about people
trying to subvert GRSecurity or Vista ASLR. We know it's possible, it's
just a matter of time and resources.

Today, we're going to cover how to decrease the footprint that malware
or shellcode/exploit has access to the systems, and therefore underlying
applications.

Back in another place, another time -- firewalls did not exist and
everyone logged into machines using Berkeley r-services. This led to
complications such as the AIX "rlogin -froot" fiasco (which, just over a
year ago now was found in the latest Solaris telnet, but I digress), and
add to the fact that nearly everyone was on a public IP.

Everyone on a public IP with every service running -- all unencrypted.
We have come a long way, and maybe we should even pat ourselves on the
backs. However, success in security is measured in the number and
criticality of breaches -- and if you compare where we were at now to
where we were back then: we're failing!

In the mid 1990's, Cisco Systems purchased a company claiming to have
the first Network Address Translation (NAT) device -- the PIX (or
Private Internet Exchange). That company's name was Network Translation,
Inc. and you can read about it all on the Wikipedia article about the
Cisco PIX. Thus began the era where Cisco would coin RFC 1918 as a
"security feature".

Unfortunately, Cisco was too late in my mind. SSH was also released that
year, and any security professional in the know built their own NAT
solutions where the only external services were SSH and maybe ftp and
HTTP. It's funny that over the years, the only
application/network-service that I've been owned through was SSH -- and
it's doubly ironic that I used OPIE (one-time passwords) to access my
account through SSH, as well as to su to root.

However, the reason why I was owned, and the reason that many people get
owned is not because of a technical vulnerability (although at one point
there had to be at least one software weakness exposed), but instead a
simple concept of trust. While I was using SSH and OPIE to access my
machine that I shared with another trusted administrator (who also used
OPIE to access his account and su to root), it turns out that this other
admistrator had made a special exception for a certain female friend of
his. That person logged in from a terminal that was located at a certain
commune that was built and occupied by a reputable hacking group. The
ssh binary she used contained a backdoor, and the rest was history. Or,
well, our machines were history.

In the late-90's (when this sort of thing went down regularly), the
attacks were focused on system access to the server, and the exposure
was mostly to attack the server. In the case above, it was the client
that was backdoored -- but this wasn't the primary focus.

Today, client-side exploits are the primary focus, especially along with
backdoors and botnets. The trust models become worse as we keep adding
file and protocol handlers to our browsers and IM clients. AV software
adds more file and protocol handlers to detect exploits in file and
protocol handlers, making them more vulnerable to attacks as well. The
attack surface and trust relationships built in modern software is at a
peak of risk and exposure.

First of all, protection at the local area network (LAN) must come in
the form of SSL VPN (with both client and server side certificates
correctly configured). You get your DHCP, you get your DNS locally. The
DNS server should only have an entry for the DNS server, the DHCP
server, and the SSL VPN server. I prefer open-source software that is
code reviewed before deployment. Again, Pyramid Linux or Vyatta on
embedded hardware are logical starting-points. For an SSL VPN server, I
recommend checking out
SSL-Explorer.

Once connected via SSL VPN, clients should be on another LAN that has
another DHCP and DNS server on it, and two proxy servers (preferably
something open-source such as Squid proxy). None of these DNS servers
have full Internet access, only the DNS names and reverse for the local
servers. For the two proxy servers, one can connect to Intranet, or
local services -- while another can connect to external sources such as
partners and the Internet.

Each Squid server can have access to the full Intranet or Internet DNS.
This way the clients must set their web browser proxy (or pick it up
automatically). Yes, this requires setting your proxy differently if you
plan on access Intranet or Internet websites. I consider this a bonus.

Jay Beale gave talks on ClientVA at Toorcon
and Shmoocon that involved setting up RSnake's Mr. T (Master Recon
Tool) to check browsers for versions and
plugin versions. Additionally, the Squid proxies can have every URL (or
even POST operation) whitelisted using an open-source package such as
Whitetrash.

Additionally, users on WiFi will benefit from the SSL VPN immediately,
but they could be at risk if their drivers are vulnerable to a kernel
based attack. Using assessment software such as
WiFiDEnum
will check for these types of known vulnerabilities in local drivers.

File inclusion only affects PHP, but the concepts can easily be extended
to remote script execution in JSP or ASP pages, both HTML based as well
as driven by their scripting languages. There is quite a bit of
information about file inclusion and remote scripting attacks available
in the Web Application Hacker's Handbook, from Portswigger.

Portswigger also recently posted about CSRF and threat
ratings
on his blog, and he'll be teaching (from his book?) at BlackHat Eurpoe
next week.