May 152014
 

Important Edit: I have decided to host updates for Windows XP Professional x64 Edition starting now. The updates will be hacked where necessary to work smoothly on XP x64, unmodified updates will also be re-hosted! You can find them all in a page pinned to the weblog on the top right, [here is the link]!

XP Hex hackingOk, so we all know that besides those “Malicious Software Removal” updates and that fancy [Internet Explorer hotfix], XP is and will stay dead in the water, when it comes to Microsofts support for patches, right? That might be true for Windows XP 32-Bit, but what if I told you that there is a real way to keep XP x64 alive and secure all the way until July 2015? Since the newer XP x64 shares a large code base with Windows Server 2003 (which keeps being supported until 2015-07-14), the logical thing would’ve been to just try out those updates where applicable. It ain’t all so easy though…

Install error

Trying to install the update for [KB2926765] succeeds on Server 2003, but fails on XP x64!

This update actually replaces the 32-Bit and 64-Bit versions of shlwapi.dll, which exists on both operating systems in the same version. So what’s going on? We can find the solution by unpacking the update file WindowsServer2003-KB2926765-x64-ENU.exe with 7zip or WinRAR. Inside you’ll find an update/ folder and in it, the file update_SP2QFE.inf.

When opened, the culprit can be found at the very end of the file:

[Prereq.XPAMDInstallBlock.Section]
    PresentOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000
    NotEqualOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000,!=,"WinNT"
    Display_String="%WrongProductMessage%"

When you open the registry editor and check those keys, you’ll find that “WinNT” string. And that means, that the prerequisites of the installer update.exe in the same folder are not met. And that’s the updater launched for the actual installation. So then, just edit the INF and install? Yeah, that’s what I thought. Forget about it right away! Each update comes with a catalog file – KB2926765.CAT in this case – which amongst other files holds cryptographic signatures of the INF files included. Change one of those INF files and it’s this one for you:

INF modification doesn't work

INF modification doesn’t work!

So then I found [this guy right here], who seems to be some serious Windows hacker. Like SERIOUS serious. I thought that hacking update.exe would be the next step, so I fired up the IDA disassembler and tried my luck together with my trusted old XVI32 hex editor to try and duplicate this guys hack to cancel out the INF file verification code:

So the assembly patch would generate hexadecimal binary opcodes (the instructions mov eax, 1 and retn 4 were added), which I then tried to enter into the file at the proper offset with a hex editor. Now I am no software reverse engineer and my x86 assembly is rusty, x86_64 non-existant. In the end, this failed miserably. The x86_64 code differs greatly from the x86_32 one shown at the blog post linked to above, so I was unable to port the solution over. It’s definitely possible, but it’s also a bit over my head.

And then I found a guy called 5eraph, who [assembles updates for Windows XP Pro x64 Edition] on RyanVMs forums, and his collection is still being maintained. In more recent times he had decided to include updates that were blocked on XP x64, especially since the end of Windows XP support. According to him, some of the updates showed clear signs of having been targetted at XP x64 just as well (you can find the signs if looking through all the INFs), if it wasn’t for the added crap in the update_SP2QFE.inf file and its siblings found in other Windows updates.

But he found a way. And again, the way was to patch update.exe. [See here]! Now I don’t know how this hack was developed, but basically you just need to edit a few strings with a hex editor. Here is the table with offsets as well as old values and new values in hexadecimal:

00016A90: 50 44 
00016A91: 72 75 
00016A92: 65 6D 
00016A93: 52 6D 
00016A94: 65 79 
00016A95: 71 53 
00016A96: 75 65 
00016A97: 69 63 
00016A98: 73 74 
00016A9A: 74 6F 
00016A9B: 65 6E 
00016AA0: 50 44 
00016AA2: 72 75 
00016AA4: 65 6D 
00016AA6: 52 6D 
00016AA8: 65 79 
00016AAA: 71 53 
00016AAC: 75 65 
00016AAE: 69 63 
00016AB0: 73 74 
00016AB4: 74 6F 
00016AB6: 65 6E

And what’s it look like when viewed in a hex editor? Let’s check it out in XVI32, stock version and modified version, the fields from the list have been marked in red to make it more clear. Just jump to offset 0x00016A90 and start editing:

So all you need to do is to change the data to some bogus crap, that exists nowhere else. You need to be very careful though, touch one wrong byte and the file will be damaged and will crash or behave erratically when launched. If everything has been done right, just launch the new, modified update.exe and something like this should greet you:

And just to verify that it actually did what it should, a quick version compare of the patched file shlwapi.dll in %WINDIR%\system32\ before installation and after installation & reboot is enough:

So, as I had hoped, it is indeed possible to refactor Server 2003 x64 updates for XP x64, even now where Microsoft is actively trying to block out the operating system from its updates. Now, not all updates will require this, as [reported by Sjaak Trekhaak] and confirmed by me. But those which do can be fixed!

Unless Microsoft finds some new way to harass what few XP x64 users remain, this is the way to go. It would be necessary to filter the updates though, as real Windows Server 2003 systems do feature components that XP x64 does not have, like an Active Directory LDAP server for instance. So a user would need to check this out on his own, or just rely on 5eraphs update pack of course. While I do prefer do pull this off myself, using 5eraphs stuff is much easier of course, no hex editing on your own, so you might wanna go with that instead.

And I do have bad news too after all. I can’t prove it, but due to the code base itself, it is highly likely that none of this works with Windows XP Pro x86 / 32-Bit…

In any case, Windows XP Professional x64 Edition lives on! The final battle ain’t over yet!

Thanks and greets fly out to 5eraph for his great XP x64 support, to RyanVM for hosting that cool forum and to [Remko Weijnen] for his elite hacking skills!

May 302013
 

Hack logoTonight at around 10:30PM, XIN.at came under attack by what I assume to be a larger bot network. As a result, all CPU-intensive web applications on my server, including this weblog, forums, CMS’ etc. went offline because of the attacks causing excessive PHP CPU cycle usage and timeouts of all scripts. It seems the primary target of the attacks was this weblogs login page, but the largely inactive forum was also a target obviously. Log file analysis suggests, that this was a distributed brute force attack to break into XIN.at web services (and probably a few thousand other web services on other servers). The attacking hosts were many machines spread across multiple IP pools, so I have to assume that this is some major attack to break into multiple web services at once, for purposes currently not known to me.

Amusingly, the attack failed on this server while remaining in its infancy. As a security measure, runtime of PHP scripts is limited on this server. The attack was so massively parallelized, that it simply overloaded everything, causing all scripts to return HTTP 503 errors to almost all attacking hosts. In laymans terms: This server was simply too SLOW to allow the attackers scripts to ever succeed. I can only laugh about that simple fact. This server was just too old and crappy for this shit. ;)

Well, still, for that reason, this weblog and most of XIN.at’s web services went offline for around 2½ hours. For now, it is back online, and hopefully the brute force attacks have ceased by now, as my monitoring would suggest. We’ll see.

Feb 012012
 

Tux is dying. Sometimes.There has been a recent [security advisory] about a certain exploit, that affects most Linux Kernels v2.6.39-rc1 and newer, if they contained the upstream patch [198214a7]. The flaw came with a re-enabled mem_write() function and enhancements made to the handling of the /proc/pid/mem permission checks when writing to running programs memory via the facility. It is possible to use this to escalate a users privileges, supposedly all the way up to root. Now that alone is bad enough, but the enhancement has been back-ported by some distributors like RedHat, and hence has also hit CentOS and Scientific Linux even though their kernel versions are <2.6.39-rc1. By now there are kernel updates available to get the problem fixed. In the meantime, there is some sample code available to show wether your specific machine is vulnerable to this kind of /proc/pid/mem hijacking or not. See the source code:

expand/collapse source code
  1. /*
  2.   simple reproducer that tests whether we have commit 198214a7ee50375fa71a65e518341980cfd4b2f0 or not
  3.  */
  4.  
  5. #define _LARGEFILE64_SOURCE
  6. #include &lt;stdio.h&gt;
  7. #include &lt;stdlib.h&gt;
  8. #include &lt;sys/types.h&gt;
  9. #include &lt;sys/stat.h&gt;
  10. #include &lt;fcntl.h&gt;
  11. #include &lt;unistd.h&gt;
  12.  
  13. char *s = "not vulnerable";
  14. char *s2 = "vulnerable";
  15.  
  16. int main(int argc, char **argv)
  17. {
  18.  
  19.   int fd;
  20.   loff_t r;
  21.  
  22.   fd = open("/proc/self/mem", O_RDWR);
  23.   if(fd &lt; 0) {
  24.     perror("open: ");
  25.     goto end;
  26.   }
  27.  
  28.   if(lseek64(fd, (off64_t) &amp;s, SEEK_SET) &lt; 0) {
  29.     perror("lsee64: ");
  30.     goto end;
  31.   }
  32.  
  33.   if(write(fd, &amp;s2, sizeof(s2)) &lt; 0) {
  34.     perror("write: ");
  35.   }
  36.  
  37. end:
  38.   close(fd);
  39.   printf("%s\n", s);
  40. }

You can compile and test the code with GCC:

$ gcc test.c -o test
$ ./test

In case your system is vulnerable, the code will just output “vulnerable”, otherwise it will say “write: : Invalid argument” and “not vulnerable”. In that case your kernel is either too old to have the enhancement or has been fixed already. If your system is vulnerable, updating your Kernel to a fixed version or even downgrading in case there is none available for your distribution is highly recommended.