Re: Client Side Exploits

[Todd Haverkos <infosec () haverkos com>]

cribbar <crib.bar () hotmail co uk> writes:

> 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. 

Correct.  

> 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?

I'd agree. 

> Are unpatched vulns on servers and server apps never targeted from
> the outside, i.e. via dodgey email, malicious websites etc?

Oh, I wouldn't say never... but the easiest way in these days by far
is either to pwn an employee workstation via client side of a phish,
then work from there, or to go after a web app.    Direct network
based server attack in the traditional sense is harder and therefore
less common.  

> 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? 

I'd agree with underlining the assumption that no one will ever surf
the net from that machine.  That said, I've seen admins do some
surprisingly ill advised things.  As such, the advice I'd give would
be to remove that reader from teh machine, or integrate its patch and
upkeep into enterprise vuln management. 

> 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 answers to these questions vary by vulnerability and exploit.  If
it's an unchecked buffer issue, a buffer overflow injects shell code
that grabs control of program execution and does the attacker's
bidding after that point.  Whether the server configuration of
presence of ASLR and/or DEP thwarts success varies.  That said there
are an awful lot of sploits out there that can do just that, and break
out of limited user roles too.


> 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.

One possibility -- the exploit gives the attacker a remote shell or a
remote meterpreter on the server. I f the server can talk to the
internet, that's all that payload needs -- be it tcp or http, or even
DNS control is possible.  Once in control of the server, exfiltrating
the data out can be done a number of ways.  If the web server can talk
http out to the internet, the data can be sent out that way. Or in a
more manual sense, a simple netcat of the file can go out unless
egress filtering blocks such direct access to the net.  If there's a
proxy involved, the attacker could proxy the request out.  it varies. 


> 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?

Frightenly few companies include this in standard pen test offerings,
and that's a major criticism of a lot of pen tests.  It's hard to get
companies to sign up for such client-side inclusion too... because
it's going to virtually guarantee penetration success and show a lot
of findings.   Some companies only want pentests because of audit
drivers rather than being truly interested in improving security, and
for those companies, such "real" penetrtation tests become a harder
sell. 

So, you are correct to note that there is a disparity between the easy
ways most attackers will attempt to penetrate vs the way the
traditional penetration testing firms will approach the test.  

PTES is looking to change that though... 
http://www.zdnet.com.au/white-hat-standard-to-out-lazy-testers-339311763.htm

Best Regards, 
--
Todd Haverkos, LPT MsCompE
http://haverkos.com/

------------------------------------------------------------------------
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
------------------------------------------------------------------------