Re: Client Side Exploits

[Daniel Crowley <dcrowley () coresecurity com>]

> Can anyone of you pen-testers give me some basic advice on client side
> exploits and what potential impact they can have on server-side
> infrastructure, and are these included in pen-tests. In my less than expert
> opinion when it comes to client side exploits, that spells out to me stuff
> like adobe reader, whereby to exploit an un-patched version of adobe,
> requires a hacker to somehow trick a user into opening a malicious PDF which
> in turn I assume lets the hacker run some sort of code under the privilege
> of that user. 

Pen tests may or may not include client side exploitation. Anyone
looking for a serious evaluation of how their organization stands up
against attacks should include these as a part of their test. Client
side attacks might include Trojans, or exploits against third party
applications or the OS as you mentioned, but may simply be an attempt to
social engineer a user into giving up passwords or other sensitive data.

> I have read hackers typically target users and unpatched vulns on user’s
> workstations in the network/domain that have access to specific servers as
> opposed to targeting unpatched vulns on the server itself, is that true? Are
> unpatched vulns on servers and server apps never targeted from the outside,
> i.e. via dodgey email, malicious websites etc?

People tend to patch their Internet facing assets, but it doesn't always
happen. Web application attacks are typically the most effective from
the outside. SQL injection attacks, for instance, have been used in a
lot of recent high-profile hacks like Heartland Payment Systems and
HBGary Federal. Client side attacks don't generally get you access to
servers directly, but through the use of credentials or privileges held
by users.

> Does this mean then that if you had an un-patched version of adobe reader on
> say a windows 2003 file server, there’s no real risk? Admins don’t use the
> server to browse the net, open email etc, so how can you trick an admin into
> opening a dodgey PDF on a server? 

In the same way that you probably won't run an FTP server on a
workstation, you probably won't be checking email or browsing the Web
from a server. Attacks must be geared towards the target. However...

If an admin uses their workstation to authenticate to anything while you
have control over it, or if their credentials are saved, as an attacker
you can gain access to it. If they have credentials which are used in
multiple places (which is incredibly common and if you don't believe me
consider that the CEO of HBGary did this too), you gain access to
multiple systems. Imagine that you compromise an admin who is using his
workstation (or someone else's) as a domain administrator. Gets scary
real fast, doesn't it?

Once you're inside the network, there is an inherent level of trust
which can be abused by an attacker to compromise additional hosts.

> Back to the running of malicious code once you have tricked a user into
> opening your malicious PDF, what kind of code is it? What language? And how
> can this code attack the server to get to whatever sensitive data you were
> after? If the server has been hardened with strong passwords, ACL’s, patches
> etc is it going to stand up to this malicious code execution? The thing that
> worries me is if malware can execute code that can bypass windows security
> features, so technically could a malicious insider if they had that code. I
> just wondered what type of things the code will try and attack if its sole
> focus is getting a copy of sensitive data on a file server.

The code run via malicious PDF (or any other type of file, for that
matter) is generally going to be machine-level code, often referred to
as "shellcode". It depends on the vulnerability, but this is the case
with memory corruption flaws, which if exploited correctly get you code
execution. Frequently, this code will establish a communication channel
with the attacker and allow them to take control of the machine with the
privileges of the process which was compromised. Insider attacks are
generally more effective because they don't have to figure out a way to
get into the internal network, where security is in many cases more lax.

> And last but not least, another thing that baffles me, is if this dodgy PDF
> gets onto a workstation, it then executes its malicious code and gets onto
> an admin share on a windows server, and finds 20 word documents full of
> sensitive restricted data, how does it get these word documents out and into
> the hands of the hacker? I just cant see how that stage works.

There are many ways to exfiltrate data from a compromised network. When
developing firewall rules, most people don't write rules to restrict
outbound traffic. When they do, they generally allow outbound traffic to
ports 80 and 443. Some people might additionally inspect outbound
traffic to see if sensitive data is being transmitted to the Internet.
However, if you're using HTTPS, you have to start doing
man-in-the-middle attacks against your users' Web traffic to recognize
potential "evil" data exfiltration and this gets politically ugly.

What I prefer to do when simulating an attack is to exfiltrate data by
setting up an HTTPS server and instructing the machine to take the
documents, save them locally, then transmit them via HTTPS to my waiting
Web server. Then, your documents are mine.

There are other ways, too. Research "Covert TCP" or "Loki" for some
devious examples.

> And is this the kind of thing you include in your pen-tests, i.e. send a
> shed load of dodgey PDF to corporate users via email and see what kind of
> access and data it gets you access too?

If I can, I will include this as part of my testing. With a solid ruse
and enough targets, you are almost guaranteed to get some sort of
foothold on the network. Unless you've sectioned off your network and
hardened it on the inside, it becomes a playground for me.

--
Daniel Crowley

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------