c:\program
By default, at least on WinXP and WinServer 2003, you'd need to be an
admin to drop program.[exe|cmd|com] into the root dir.
Of course, if you have FAT, or a weak ACLs on the root, then yeah.
[Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard
[On-line Security Training]
http://mste/training/offerings.asp?TrainingID=53074
-----Original Message-----
From: Marc Maiffret [mailto:mmaiffret@eeye.com]
Sent: Tuesday, January 18, 2005 12:59 AM
To: Dan Rogers; pen-test@securityfocus.com
Subject: RE: priviledge escalation techniques
If your looking to do a quick privilege escalation with a system where
you already have a login then I would suggest using the c:\program trick
in which any service that fails to put quotes around its "Path to
executable" argument and points to a file in c:\program files can lead
to local SYSTEM ... As windows will execute c:\program before the real
file. There are a lot of third party applications installed in most of
corporate America that can lead to this attack working. Products by
companies like Scriptlogic for example or any software that used one of
the buggy versions of Microsoft's MSI to create their installer package.
Even this new "biometric" authentication keyboard I am playing with from
MS has the flaw... They reference, C:\Program
Files\DigitalPersona\Bin\DpHost.exe, which means if I put a trojan as
c:\program than the next time that service starts (most likely a reboot)
my trojan (c:\program.exe) will execute as SYSTEM. Good thing my
biometric keyboard made me more secure :-) p.s. don't forget to make it
a service file.
As for the rest of your internal security... Your probably better off
understanding your patching processes, how you've locked down your
client apps (outlook, IE, etc...) and what you've done to lock down the
file system, which can prevent attacks like the one mentioned above.
Obviously once you have asked everyone how they think they have locked
down the security of your internal network you should then double check
that by doing your "hacking" stuff. If you cant yourself or don't have
anyone that can *already* answer questions like this for your company,
than the answer is your internal security is non-existent.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
Important Notice: This email is confidential, may be legally privileged,
and is for the intended recipient only. Access, disclosure, copying,
distribution, or reliance on any of it by anyone else is prohibited and
may be a criminal offense. Please delete if obtained in error and email
confirmation to the sender.
| -----Original Message-----
| From: Dan Rogers [mailto:pentestguy@gmail.com]
| Sent: Sunday, January 16, 2005 7:59 AM
| To: pen-test@securityfocus.com
| Subject: priviledge escalation techniques
|
| Hi List,
|
| I have been asked to test the network security of my
| organisation from an internal perspective. My boss has not
| been particularly specific in his requirements (other than
| asking that I don't break any operational
| infrastructure) so I can approach the problem from whichever
| way I deem most appropriate.
|
| I suspect the first thing I will attempt is privilege
| escalation techniques from a workstation with a domain user
| account to see if I can install my own software/toolset. Can
| anyone suggest any good whitepapers or tools that I can use
| to get a head start?
|
| I intend to follow this up by scanning/targeting critical
| parts of our infrastructure - domain controllers, mail
| servers, routers etc.
| However, I am interested to know what other people would do
| when given free reign to identify internal weaknesses - so
| how should I approach this? This is not an 'audit' exercise,
| as I will not be given access to server/infrastructure configurations.
|
| Any advise on this appreciated.
|
| Dan
|
