2010-09-14 - the slides from my recent (re-)presentation (with lots of extra bits) at SEC-T 2010, will soon be online! exploit code [...]

2009-12-18 - The slides from my recent presentation at CRESTCon 2009, the 'replacement' for CHECKCon, are now online! exploit code for the demonstrations [...]

:.home.other stuff.unSafeCentral3.141..

“security made [irrelevant]”

"SafeCentral STOPS Online Fraud"


SafeCentral™ is a software product for the Microsoft Windows Operating System that attempts to provide "[a] secure desktop, a secure connection, [for] certified and authenticated participants; SafeCentral™ is the closest thing to a physical transaction possible in the digital realm" [  http://www.safecentral.com/whatisit/online_identity_theft_software_features.html ]. I am sure you will agree, such audacious claims bare a heavy burden of proof!

Going further, to quote Authentium, Inc, "SafeCentral IS...

  • The secure companion to everyday web browsing, providing end-to-end security against Identity Theft by locking out desktop malware and establishing trusted web connections.
  • Patent-pending TSX technology to block key-loggers, screen-scrapers and other malware agents, even on an already infested PC.
  • SecureDNS to ensure a connection to the actual site, eliminating man-in-the-middle attacks.
  • Automated "launch anywhere" protection for seamless integration into your existing browsing habits.
  • Peace of mind when transacting online.


The purpose of looking at SafeCentral™ is fairly self-explanatory when you consider the nature of the claims Authentium, Inc are all too happy to make! At every available opportunity. Indeed, the claims are stated so often, and clearly, so as to make it uncontrovertial to claim they border on outright self-adjulation. As such, I challenge any open-minded individual to take a walk around safecentral.com and not immediately arrive at a conclusion of Snake Oil.

The immediate question to the claim of self-adjulation and the inevitable comparison to Snake Oil is, do you have any proof of your claims?

As a matter of fact, Authentium, Inc does have proof! Indeed, the claims made by Authentium, Inc in relation to SafeCentral™ were proven by Information Risk Management Plc (IRM). In the words of Corey O'Donnell of Authentium, Inc; Authentium, Inc "commissioned IRM's world-renowned security testing team to evaluate SafeCentral", furthermore, he goes on to say that Authentium, Inc "were ecstatic to see that SafeCentral met or exceeded every claim, and indeed is 'certified' to provide true privacy when transacting online." [  http://blog.safecentral.com/2008/06/testing-confirms-safecentral-security.html ]

Well, as an open-minded reader, you might wish to question the 'claims' Authentium, Inc made prior to the test conducted by the "world-renowned security testing team" of IRM, which according to their own admission, "SafeCentral met or exceeded every claim" and as such can be considered "certified"?

Of course, assuming you are indeed an open-minded reader, you may have already come to the obvious conclusion that any such "certifi[cation]" is completely irrelevant by simply considering the conditions under which SafeCentral™ may fail the tests. That is to say SafeCentral™ may only fail the tests conducted by the "world-renowned security testing team" of IRM if and only if SafeCentral™ does not conform to Authentium, Inc's own claims. As such, assuming the individuals at Authentium, Inc who devised the claims to be "certified" by IRM were anything but completely incompetant morons with absolutely no knowledge of SafeCentral™, you instantly arrive at the conclusion that any such test is simply a side-show performed to give credence to the public relations claims of Authentium, Inc. (Leaving the whole sounding like nothing but a bunch of braindead cheerleaders at best and Edward Bernaysian manipulation at worst)

Public Relations (a synonym for 'Propaganda') aside, how do we counter such "claims"? Well, the answer to that is pretty simple, we break SafeCentral™!


In a break from ordinary convention, I will actually give a somewhat detailed example of what it takes to locate a bug in SafeCentral™. You should bare in mind that I am not a "world-renowned security testing team", so all queries/clarification requests regarding this should be forwarded to info@irmplc.com who I am sure can provide you with far more detailed information than myself.

A good place to start would be kernel drivers distributed with SafeCentral™, well, starting with shdrv.sys, from the listing below we know that the driver provides an IOCTL interface to, presumably, user-land applications via the device name "\\Device\\ShDev".

.text:00403AED push offset aDeviceShdev ; "\\Device\\ShDev" .text:00403AF2 lea eax, [ebp+DestinationString] .text:00403AF5 push eax ; DestinationString .text:00403AF6 mov edi, ds:RtlInitUnicodeString .text:00403AFC call edi ; RtlInitUnicodeString .text:00403AFE push offset DeviceObject ; DeviceObject .text:00403B03 push ebx ; Exclusive .text:00403B04 push ebx ; DeviceCharacteristics .text:00403B05 push 22h ; DeviceType .text:00403B07 lea ecx, [ebp+DestinationString] .text:00403B0A push ecx ; DeviceName .text:00403B0B push ebx ; DeviceExtensionSize .text:00403B0C push esi ; DriverObject .text:00403B0D call ds:IoCreateDevice .text:00403B13 mov [ebp+var_1C], eax .text:00403B16 cmp eax, ebx .text:00403B18 jl loc_403C0C .text:00403B1E push offset aDosdevicesShde ; "\\DosDevices\\ShDev" .text:00403B23 lea edx, [ebp+SymbolicLinkName] .text:00403B26 push edx ; DestinationString .text:00403B27 call edi ; RtlInitUnicodeString .text:00403B29 lea eax, [ebp+DestinationString] .text:00403B2C push eax ; DeviceName .text:00403B2D lea ecx, [ebp+SymbolicLinkName] .text:00403B30 push ecx ; SymbolicLinkName .text:00403B31 call ds:IoCreateSymbolicLink .text:00403B37 mov [ebp+var_1C], eax .text:00403B3A cmp eax, ebx .text:00403B3C jl loc_403C0C .text:00403B42 mov eax, offset sub_4038E0 .text:00403B47 mov [esi+38h], eax .text:00403B4A mov [esi+40h], eax .text:00403B4D mov dword ptr [esi+70h], offset ioctl_handler

The last line of the listing shows shdrv.sys defining the handler function for IRP_MJ_DEVICE_CONTROL requests to the "\\Device\\ShDev" device. If we take a look at the ioctl_handler function (renamed in this example, found at offset 0x0040397 in shdrv.sys version we are presented with a function that obviously handles IOCTL requests. The basic block graph for this function is given in the following figure...

Figure 1. ioctl_handler graph
Figure 1. ioctl_handler graph

Well, continuing on in standard english fashion, namely left-from-right, the obvious starting point being the basic block on the far left.

Figure 2. left most basic block
Figure 2. ioctl_handler left most basic block

Following the path of code execution we immediately arrive at sub_004139D0, note that at address 0x004139DA, the ecx register contains a user supplied pointer. As such, the user controls the values of the registers eax, edx, and esi at addresses 0x004139DA, 0x004139DC, and 0x004139E0 respectively.

Figure 3. sub_004139D0
Figure 3. sub_004139D0

At this point it is only necessary to observe the instruction at address 0x00413A3F,

00413A3F mov [esi], edx : esi = user controlled

As you can see, using simple uncontrovertial assumptions, it should take a semi-competent individual at most 5 minutes and approximately 20 clicks of a mouse in order to locate an arbitrary pointer write! Kernel mode code execution quickly follows..


Do you really need me to explain the obvious? just because someone says something, sorry, 'certifies' something, does not imply that it is actually any good! Especially when the people doing the 'certifying' produce code like this.

"You also acknowledge and understand that, with respect to any dispute with Authentium, its officers, directors, employees, agents or affiliates, arising out of or relating to your use of the Service or these terms and conditions: (i) YOU ARE GIVING UP YOUR RIGHT TO HAVE A TRIAL BY JURY;"
- Authentium, Inc, denying civil rights since 2000 [ https://secure.safecentral.com/view_terms.php ]