fgdump News Archive
Sorry that the site was down last night - we had a hardware failure on our poor little web server. All should be well again, however.
I added a link to some usage examples - that's probably about as close as I will get to formal documentation at this point. :) I also put links to the standalone fgdump executables on the downloads page. Not only does this remove a bunch of cruft for folks who want to just use the thing, but it also makes it less likely to be noticed by AV when downloading.
Last but not least, happy birthday to my Keith Richards-impersonating brother-from-another-mother! A fine, fine excuse to spend a nice afternoon outside celebrating your 45th birthday. ;)
A few updates today. First, I'm in the process of reorganizing the site a bit as I continue to add more content to it - you'll note the Downloads link on the left side nav bar. Deep links to the files themselves should still work, though I can't guarantee that those won't move at some point. :)
Second, several folks have asked for additional documentation on using fgdump. I am working on that right now, and should have some stuff posted in the next few days. One gentleman asked for some pictures on using it, which I can't say I understand the need for given that it's a command line utility, but I will at least get some clear examples and explanations on how to use it.
Lastly, about Vista. I have to give Vista some credit - its new and improved LSASS sports some improved security definitely. On one hand, I can confirm that I can still dump passwords on the host (though it requires the Administrator account, Remote Registry enabled and file sharing turned on, all of which are disabled by default). So I suppose that's bad from their perspective, but on the plus side, the way they are dealing with cached credentials is tighter. So much so, in fact, that cachedump (which is used by fgdump) will not work on Vista. I spent some time recently doing some digging as to why, and found that the process itself is significantly different than in previous versions, and as such, the method currently used by cachedump to do its dirty work will not work.
Making it work goes quite beyond what I've done thus far, and will require time. My hope is that someone smarter than me will discover how LSA secrets are managed in Vista, which will open the door to restoring this functionality. :) Maybe I'll be lucky enough to figure it out on my own, but until one or the other happens, I'm afraid you won't be seeing cache dumps from Vista too soon. Sorry.
I'm researching this a lot right now, but I can't read everything on the Intertubes I suppose. As such, if you come across specific articles on reading LSA secrets in Vista, I'd love to hear about them. I'd rather hear about it 100 times than miss an important article or something.
Incorporates the new pwdump6 version (also 1.5.0) which is more evasive of antivirus. It should make a lot of peoples' lives much easier. Additionally, I've received some feedback both about Vista and 64-bit architectures. First of all, some of you have actually seen real Vista deployments outside of M$? :) Seriously, the reason I haven't put much effort into these realms is that we just haven't seen it yet, and my plate is full with many other projects. At some point, I'll have to bite the bullet I suppose, but for right now, I haven't put much time into verifying either of those two situations.
If, however, any of you folks have patches or anything that you've been using, I'd be more than happy to put them in and give you the appropriate credit.
The changes in this version were primarily driven by requests from the user community. Thanks for the feedback folks!
1.3.4 fixes a bunch of issues that have been out there for awhile, but tend to only manifest themselves when you're doing a bunch of hosts. The most important fix is that it incorporates version 1.4.2 of pwdump6, which fixes a problem where data would every once in awhile be returned corrupted. The total fix list is:
Version 1.3.3 of fgdump gets rid of the BETA tag (it seems to be pretty stable), and also incorporates the latest version of pwdump6 into it (version 1.4.1). It should be far more stable and less likely to leave a "stuck" LSAEXT.DLL file on a target.
My apologies - the ZIP archive for 1.3.2 was incomplete. Stupid -r flag. It should be correct now.
Defcon 14 was very fun, and foofus's presentation was well-received. Thanks to everyone there, especially the folks that make it happen (DT, the Goons, Priest, Winn, the whole lot of you). We may have gotten our asses kicked at Hacker Jeopardy, but in all fairness, we wouldn't have participated if we knew the beer rules had changed. We had expected to win by mass consumption of alcohol. Ah well, Bunnies For Priest shall live on, and we've got ears and shirts to show for it.
I also have to apologize for the liver damage I may have inflicted on others at DC14. Between Warp Cores and old fashioneds, I think I was at least in part responsible for dishing out a fair number of hangovers. I assure you, however, that both drinks will be making another appearance next year at the Party Pad.
I've been exceedingly busy and haven't been making many changes, since things seem to largely be working well. I will be releasing a non-beta version "soon" with any luck, but there should not be anything other than bug fixes in it.
I will be announcing shortly my new endeavor, which is essentially the next generation of fgdump, but with a LOT more power and features. I will announce this as I get a bit further along in the design process, but with being so busy, I haven't had much time to work on this soon.
Also, I've noted that pwdump6 downloads greatly outnumber fgdump ones (though both numbers are VERY respectable). This perplexes me, since fgdump does everything pwdump does and more. If you're using pwdump, might I humbly suggest stopping? :) Seriously, I think fgdump will work much better for you, and it really will do the exact same thing. Heck, fgdump *uses* pwdump6 under the hood! Tell your friends to stop using old stuff. :)
Greetings fellow Defcon enthusiasts. As hoped, I hereby announce...
A word to the wise - if your host machine (where you are launching fgdump from)
has a copy of pwdump and lsaext.dll on it already, DELETE THESE. There is an incompatibility
between the version in the new fgdump and these old versions. If, for some reason,
it decides to use the old DLL, it may cause target systems to crash. Note that this
implies pwdump6 has changed, which it has. I haven't had time to get the standalone
version up to the site yet. Soon, I promise.
Version 1.3.0 is in the internal beta testing phases right now, and I'm pleased
to report that the multithreaded stuff seems to be working well. There were some
major changes, particularly to the logging mechanism, as well as isolating per-server
activities in their own class and of course creating the whole thread pool thing.
I anticipate testing will be done in a week or so, and the beta version will be
available around that timeframe. Between then and Defcon 14,
I hope to work out any major bugs and get a stable release out there.
I've been quiet for a bit here, primarily because I haven't had a whole heck of
a lot to do! :) Folks who are using fgdump seem to be having few problems with it,
which is awesome. I've started work on getting multithreadedness worked in, with
a goal of having this done in time for a DefCon 14 release, but as soon as I say
something like that, I start getting slammed with other work and have no free time
to do so. :) Hopefully that doesn't happen this time.
I'm working on an isolated incident that seems to be affecting certain Windows 2003 SP1 servers. Thus far, I've only personally seen the issue when those servers are running within VMWare GSX. The problem is that either the pwdump or cachedump phases hang, and even if they don't, neither one returns any data. The target does not crash, and I haven't found any useful data that indicates what the problem might be. If anyone has seen this or happens to be a VMWare expert and can shed some light on the situation, I'd be grateful, and can begin looking for a resolution.
I thought I would give everyone a quick heads-up on current fgdump development,
and what you can hope to see in the near future. Since I'm updating the pwdump home
page, this seemed like a good time to work on my l33t HTML sk1llz0rz.
Just because I love you all so much, I'm providing a new version of fgdump, version
Note also that, while I thought this would all work on NT 4, it in fact does not. I have pondered whether to fix this or not, and right now it seems to be a pretty arduous task for a relatively few number of hosts. If you are absolutely dying for NT 4 support, drop me an email and I'll see what I can do. It will, however, find NT 4 hosts and report back their version, prior to complaining about the remote registry not running. Sorry about the inconvenience, but suggest to your customer, etc. that they upgrade to an OS created in this millenium. :)
The beta version of fgdump has one major new feature, and a couple of minor fixes/enhancements. Check the README file for full details. I will get a web page set up for pstgdump ASAP as well as getting a separate link up here, but thus far I have not had time. Hopefully I will have this done early next week.
I made a minor enhancement to the error reporting when fgdump cannot log on to the system. Now, instead of reporting things like error 1326, it should actually tell you something like "Unknown user name or bad password". FYI if any Microsoft people are reading this...could one of you PLEASE make the error number to message API less painful to use? It sucks that I have to write a function to wrap what should be a trivial call. Then again, I suppose you'll get on that about as quickly as the WMF exploit patch... :)
After some more testing and soul-searching, I've decided to slap a 1.0.0 tag on
fgdump (and pwdump6) and call them official releases - just in time for Christmas!
The source archive was missing a few files that caused compilation problems (the
Subversion repository was out of date, sorry). It has to do with LSADump functionality,
which I have started on but not yet finished. The archive should now appropriately
contain the files needed to build this.
Unbeknownst to me, I still had pwdump6 beta 2 linked into fgdump 0.7.1. This causes
a couple of problems, the most notable of which is that the password history stuff
is broken in beta 2. 0.7.2 correctly links against beta 3 of pwdump6, which allows
password histories to work.
I've received word from several folks who have used the new version, and the results
have been good! Apparently, machines that crashed with old versions of pwdump DO
NOT CRASH with pwdump6! Of course, that's no guarantee that the problem is 100%
fixed, but I'm very encouraged by that news. Long story short: if you had problems
with old versions of pwdump, I highly recommend trying fgdump (which has pwdump6)
or pwdump6 on its own. Very big thanks to folks who have sent me notes about how
this is working for them, I really appreciate it!
We did some testing with fgdump 0.7.0, which contains pwdump6. As expected, there were a number of bugs, many of which I hopefully have resolved now. It does not appear we've gotten to the root of the LSASS crash problem, however. Machines that were vulnerable with the old pwdump still appear to be vulnerable with pwdump6. /sigh I made one recent change which *might* help, but I have not yet tested it against a known bad machine.
Thus, I am releasing fgdump 0.7.1 for folks, but be aware it is likely to still be unstable. It should not crash any more hosts than the previous version, but I make no guarantees. :) Please send me any feedback on your use of this.
** If you have a VMWare machine that crashes LSASS and don't mind me getting a copy of it, that will go a LONG way toward an eventual (hopefully) permanent fix. Our efforts right now have been hampered by the fact that we have not been able to reproduce the crash in-house, only at customer sites. **
I finally got around to rewriting pwdump, which I have named pwdump6. This version
gets rid of the dependency on the CryptoAPI and uses a named pipe instead of the
registry to do its IPC. So far, it seems to be working fine, but I'm going to turn
it loose on some of our internal assessments to test its stability before releasing
it to the world. I also want to see if it corrects the problem where some XP-SP2
boxen were crashing LSASS (someone emailed me and noted that he had some problems
on a 2003 server as well). This testing should occur next week, and if all is well,
I will upload it the following week for folks to use.
After some testing at a site where we could reliably chain-crash lsass.exe, I think
we're getting closer to the answer. I do not have a fix yet, but I hope to work
on this some in the next couple of weeks. Based on some of our findings, it seems
the problem may lie in a CryptoAPI call that's failing because we're running as
SYSTEM (this is within the LsaExt.dll DLL that gets mapped into LSASS. The CryptoAPI
is used, it seems, to encrypt data stored in a registry key that pwdump.exe then
extracts the resulting data from. Probably a good idea, but this method of interprocess
communication seems a little shaky to me, not to mention that the CAPI calls may
be having a problem. I'm looking at rewriting major portions of pwdump to address
some of these issues, and eliminate the CryptoAPI altogether. Should this be successful
and useful to the public, I will ultimately release it as pwdump5 (since 4 is already
taken). Stay tuned.
Copyright© 2008 fizzgig and foofus.net