Metasploit Meterpreter Registry OpenKey and VNC PW Module

As you probably already know I've been doing some work with Metasploit post modules. This recent work has focused heavily on Registry functions. While doing this work I noticed a disturbing behavior. When Meterpreter checks to see if a key exists it was calling RegCreateKey instead of RegOpenKey.  RegCreateKey will attempt to create any and all keys in the supplied path that do not already exist. RegOpenKey, however, will not create the key if it doesn't already exist.

In Metasploit the registry.rb 'client-side' function is set up as a wrapper to the create_key function. Similarly the registry.c code for Meterpreter itself is set up this way. Calls to the OpenKey function were just passed on to the create_key function. I have now submitted a patch to correct this behaviour. The registry.rb function now sends a call via the meterpreter stdapi to the request_registry_open_key function. The request_registry_open_key function will appropriately call RegOpenKey instead. If/when this patch is accepted by the Metasploit team, it will make the Registry functions of Meterpreter much less invasive/noisy.


I have also gone ahead and submitted a patch for the enum_vnc_pw Post Module. The module as it currently stands will check the HKEY_Current_User keys for user-mode vnc passwords. However, this will only work if meterpreter is running udner the permissions of the user who is running the vnc server. I have added behaviour that will try to enumerate all userswith SIDs in HKEY_Users and then check each one that it can access, to see if it has stored VNC passwords. The get_reg function also had to be re-written to deal with possibile permissions issues if meterpreter does not have rights to access each users' registry. The best way to run this module will, of course be under SYSTEM priveleges as it will have access to every user. This will hopefully make the enum_vnc_pw module more effective at gathering it's data.

Sony PSN Hack: Leave GeoHot out of it

So I wandered by Geohot's latest place of residence today. I thought his posting was very well written and very nicely defined his stance. His work on opening up homebrew software on the PS3 was not aimed at enabling piracy, and he does not support or condone the PSN hack in any way. Despite this, he is flooded by comments blaming him either directly or indirectly for the hack. The level of ignorance in this matter is astounding. After two decades on the internet, you'd think I would not be surprised at this point, but I still am. I suppose i just can't shake this pesky hope in humanity.

I want to lay this out in terms that, hopefully, even the dumbest internet denizen can understand:

1. George Hotz , Fail0verflow and any other Homebrewers did not support this attack. Their work was aimed to restore functionality that was stripped away from devices that they had bought specifically for that functionality. I wonder how many people would have bought a 360 instead of a PS3 if Sony hadn't advertised the OtherOS functionality. It was certainly one of the reasons I bought my first PS3. George hotz and these others did not perpetrate this attack
2. There is no evidence that this attack even had anything to do with the homebrew console debate. Consider the following. 

• If this was about revenge or embarrassing Sony, the attack would need to be public as quickly as possible to try and prevent Sony from sweeping it under the rug. 
• Nobody has come forward to take responsibility for the breach. Instead the information leaked out from Sony inevitably as they shut down their own service to get a handle on the Incident.
• The breach targeted customer data including PII(Personally Identifiable Information) and potentially Credit Card Data. These are high value targets monetarily
• The above mentioned lack of disclosure/credit taking is more indicative of someone looking to steal this data and sell it for profit
• Some will try to argue that the attacker could have expected Sony to disclose the breach but that has two huge gaping holes. First, if Sony's security was poor enough to let the breach happen in the first place, why should there be any expectation that they have proper safeguards in place to alert them to the breach. They obviously believed they had no reason to ever expect an attack like this. Secondly, why assume Sony would even admit to the breach. Plenty of companies suffer these kinds of breaches and do not report them. It happens a lot more than you might think.

The point is, that there is no evidence to support the idea that this has anything to do with the home brew console debate. In fact the little bit of evidence we have so far points to a common data theft. To all of you people who are jumping on anonymous or any other media buzz right now, do some reading. these sorts of breaches happen all the time. This breach was essentially inevitable as long as Sony failed to correct the security flaws in their system. If you want somebody to blame you have two parties to go after: Sony, and the people who actually stole your data. Plenty of blame to go around, you can leave GeoHot out of it.

Stealing WinSCP Saved passwords

WinSCP is a popular SCP and SFTP client for Windows. Users of this tool have the option of storing 'sessions' along with saved passwords. There is an option within WinSCP to encrypt these password with a 'Master password'. This means the stored passwords will be AES256 encrypted. However, this option is NOT turned on by default. There are two ways these sessions will be stored by WinSCP.  The default behavior is to save them in the registry. They will be stored under HKEY_Current_User\Software\Martin Prikryl\WinSCP 2\Sessions.  The other option is to store them in an INI file, which will be located in the WinSCP install path.

When no master password is set, it is trivial to reverse the 'encryption' used on the stored passwords. It is a simple series of bitwise operations, using the username concatenated with the host name as sort of pseudo-key. To simplify the process of stealing these passwords I have created a Metasploit Post module /modules/post/windows/gather/enum-winscp_pwds.rb which was committed in the latest revision.

Once again, I am pleased to be contributing to the Metasploit project. I want to take a moment to especially thank egyp7, hdm, and jduck for their help and support. they put up with a lot of dumb questions while I was working on this module. it is only the third one I have created and the second to get committed. The Metasploit team is an amazing group of people to work with. They freely share their knowledge and experience and make Metasploit truly a community driven project, instead of just another piece of OSS. I look forward to continuing to contribute to the Metasploit project.

Updated Metasploit wishlist

A little while ago i posted my Metasploit Wishlist. i have pulled a new updated copy of this list, and added a Category field to help sort through it a little easier. I'll be spending some of my spare time going through this list and picking out things to port over. My first go around was a success and my first ported module:
http://metasploit.com/modules/auxiliary/dos/dhcp/isc_dhcpd_clientid

was committed. It may have been a little sloppy but i look forward to getting better as I go on. Mark my words, I'm going to get my name on that front page list.

Here's the new list

Of Hacks, Leaks, and Legal Battles : Is anyone really winning?

In recent days we have seen what seems like an escalation in the battle for the Information Age.  These events are far from new, however they have taken on a more fevered pitch. I suppose it probably started with the whole WikiLeaks-Bradley Manning thing. This started quite a fierce fight both off and on the internet.  A fierce debate with highly polarized sides sprang up around the issue of WikiLeaks.

Into that fray jumped Anonymous. They took their own unique sense of purpose and went after anyone whom they felt had wronged WikiLeaks. This included attacks on Paypal,MasterCard and others. They took time off from their busy schedule of attacking PirateBay opponents around the world. These sorts of things are not all too uncommon, especially when dealing with Anon. They have made the news in the past. What was different this time was that there was already a frenzy around the wikiLeaks issue.

Soon a new subset appeared. This group would have us believe that they are independently operating patriotic hackers, such as th3j35t3r. I have my doubts as to how independent these folks really are. These people went after anonymous, wikileaks and anyone else supporting them. A sort of mini-cyberwar started. What I would like to note is interesting is that the US Department of Justice launched an immediate investigation into Anonymous to try and make arrests over their DoS attacks. However the sophisticated DoS attack that was carried out against wikileaks was just as illegal and yet the government remains silent on the subject.

The fighting and debating raged on around wikileaks. Many things occurred during the next several months that i don't feel the need to recap. Fast forwarding to the past few weeks. Aaron Barr, CEO of HBGary Federal made an announcement that he had 'infiltrated' Anonymous and discerned the true identities of the Anon leadership. (This statement alone seems to show a misunderstanding of the true nature of Anonymous, but look at some of my earlier posts for some of my theories on this subject). Aaron Barr apparently sought to use this information to leverage himself and his company into a bit of the spotlight. Allegedly, Barr was going to sell this information to the FBI.

In response a few members of anonymous launched an assault on HBGary federal during the super bowl. In short order they ahd compromised systems inside HBGary Federal, took control of rootkit.com, seized Aaron Barr;'s twitter account and the social networking accounts of several other folks at HBGary. They stole a large number of emails from the company, and allegedly wiped out HBGary's backups.

The initial assault left HBgary reeling and embarrassed like a kid who gets pants-ed at the bus stop. It got worse from there though. Amongst the stolen emails was a document supposedly composed by HBGary Federal and Palantir. The target audience was allegedly Bank of America. The subject matter? How to destroy wikileaks. The document details disinformation campings, smear attacks against pro-wikileaks journalists, Denial of Service attacks against wikileaks infrastructure, and attempts to infiltrate the group to discover the identities of document submitters. You can see a copy of the document here. BofA and Palantir began moving quickly to conduct damage control disavowing any knowledge of the document or its creation. Additional documentation has surfaced to cast doubts on some of these claims.

The lesson here so far? Even a security firm like HB Gary can get thoroughly spanked on the internet by not taking threats seriously. The damage to their company by these leaks is yet to be seen, but other companies are already cutting ties to try and protect themselves. In this case the Leak has already proven to be an effective weapon against a powerful company.



Meanwhile, another little drama was unfolding. The Gregory Evans/ Ligatt Security drama. Gregory Evans has been accused of being a charlatan for a while. He made claims of being the 'world's no 1 Hacker'. A ridiculous, and pompous proclamation if ever I've heard one. He released a book on how to become the world's no 1 hacker. A book which was quickly accused of large scale plagarism. Evans denied these accusations, and at one point claimed that he paid any third part content writers for their material. I do not know about the vast majority of this claim. However, Chris Gates, aka carna0wnage was one of the authors whose material appeared in the book. Gates denied ever receiving any payment or giving permission to Evans to use his material in the book. The material is so obviously ripped off, Evans even sued the same screenshots which include Chris Gates' name in the login prompts.

Enough about the gory details though. Suffice it to say, the Evans/Ligatt drama continued on. Evans fought back in the only way he seems to know how. He filed lawsuits. He filed quite a few lawsuits actually. He tried suing anyone and everyone he could that has ever said anything bad about him on the internet. Most of these lawsuits have failed completely, but that didn't stop Evans. Recently, on Gregory Evans' birthday, his email and twitter accounts were hacked. All of his email was leaked into a torrent on the internet and distributed. Since the leak of his email, one embarrassing piece of evidence after another surfaces from the spool.  Many of these documents were reposted to the LigattLeaks blog, which was originally hosted on WordPress.  Evans and Ligatt sent take-down demands to wordpress and the registrar for LiogattLeaks.org. Wordpress capitulated in the face of any possible legal ramifications, whether there was solid legal basis or not.

LigattLeaks has since moved on to a site at http://ligattleaks.blogs.ru and continues to post with impunity. Since LigattLeaks themselves claim they do not possess the mailspool and are only reposting things found on pastebin, they seems to be under no legal liability. The actual consequences of these leaks for Evans or Ligatt? Aside from a lot of embarassment, and a local news story , there has yet to be any serious consequence seen from this. however, Evan's litigious assaults on the infosec community seemed to have had no real effect either. So right now I'm calling this one a draw at the moment.

Now let's move on to the Sony PS3 case. The folks over at Fail0verflow got their hands on the keys used to sign software for the ps3. Well known hardware hacker GeoHot then built on this and created a modkit to allow home brew software to run on the ps3. Sony claims that this will only serve to enable piracy on their game consoles. they file suit against Geo Hot, subpoena all of his computer equipment and issue orders for his instructional videos to be stripped from the internet. In response the instructions, examples, and encryption keys are spread across the internet. Before the case against Geohot has even begun, sony is now trying to use the legal system to gain information on every person who viewed or commented on GeoHot's video on youtube. They are also seeking legal action against anyone who posts the encryption keys. This drama is still under way but I'm going to go ahead and call it now: Sony will lose, no matter what the trial outcome.

There is already a huge public outcry against Sony over this action. They may have already caused themselves irreparable brand damage. They have increased the actual awareness of these hacks. And there is no way that they can successfully suppress the information once it has begun disseminating through the internet. They are trying to stuff the proverbial Geenie back in the bottle. One has to wonder why they are doing this. They will not be able to recoup any significant losses. they won't be able to suppress the information. They are trying to lay down intimidation tactics. These intimidation tactics are of course having the opposite effect. One has to wonder if anonymous or another group won't turn it's attention towards the Sony mega-corporation. It would be very itneresting to see a battle between Anonymous and such a  huge company.


There are three examples of folks in the Corporate world trying to control and shape the Internet for their own benefit. All of them are failing miserably, and they are all starting to pay a heavy price for it.

PCI-DSS : You gotta Keep Em Separated!

I turn to the Offspring for a bit of lyrical wisdom in terms of my latest PCI-DSS ramblings. All humour aside, please pay attention to what I am about to tell you. I cannot stress this enough:

The number one thing you should focus on for PCI-DSS is Network Segmentation. If you do not employ proper network segmentation, your PCI compliance efforts will be painful at the best, and a disaster at the worst.

Maybe your company already handles HIPPA/HITECH  or SOX. Maybe you have had some other security initiatives running for a while. That's great. PCI-DSS is a very different game, and if you don't segment your network, you will drown in work. 

You may have other confidentiality requirements in place. You may be tempted to place HIPPA Data or sensitive financial data in the same network segments as your PCI data. I am telling you now, resist that temptation. It may seem like a perfectly reasonable approach, but it should be avoided if possible.

With proper segmentation of your networks, you give yourself the opportunity to approach your goals in a phased risk-based approach. This will help maximize your efficiency when try to achieves these goals, and will also ensure that you are adding the most possible security benefit at each step of the process.

Completion of this Network Segmentation depends upon some sort of systems Inventory Process. You need to be aware of exactly what is in your environment, how they interact, and what their roles are. Without this, you will fail to segment your network properly and will never be able to truly add meaningful security as a whole.

Let's say that you have three primary Information Security concerns. PCI,HIPPA, and SOX. This means you are concerned with 4 primary data classifications:

1.PCI Data (Credit Card #s , Expiration Dates, CCVs etc)

2.PII/HIPPA Data ( Any personally identifieable information and healthcare data)

3.Financial Reporting Data

4.Everything Else

Let's talk about a perfect scenario where you are a fairly sizable company, and you have a solid budget for this security initiative you are undertaking. That being said, we will go ahead and break down #4 into some additional categories that will help with your overall security posture

1.Critical Infrastructure (Servers and Network Devices that are responsible for core business applications and services. i.e. Email, Telephony, Primary Line of business applications etc)

2.Desktop Ranges (where all of your users should be sitting)

3.QA/DEV Environments (Even if you are not doing any in-house development, you should have some QA environments to test things like configuration changes. Keeping these separate is important for a number of reasons we will get into later)

4.Non-Critical systems (everything else)

So now we essentially have 7 distinct areas mapped out. Let's talk a bit more about each of these areas.

PCI Data – This area will include any device that Stores, Processes, or Transmits Credit Card data as defined by the PCI-Council. In our scenario, this is the area that is going to be subject to some of the most stringent security requirements. This area should be strongly separated from all of the other regions, permitting as little contact between these networks and any others as possible. The rule of thumb should be Deny by Default. These hosts will all be subjected to regular vulnerability scanning and penetration testing efforts. Any applications hosted in this environment should be subject to source code review and Application Security Assessments.

Within the PCI environment, the hosts should be further separated where possible. Any external(Internet) facing Presentation layer should be strongly segmented away from the Application and Data layers. This is to try and mitigate the chances that your presentation layer will be sued as an entry vector deeper into the environment.

PII/HIPPA Data – This area is going to be a concern from a regulatory standpoint as well. However, HIPPA's guidelines on security requirements are nowhere near as stringent as those set forth by PCI. Your company should create a set of standards and ensure that they are applied against all hosts in this environment. These standards should include topics like Access Control, Encryption (transport and at rest), approved applications, approved services etc. The environment should be audited regularly to ensure that these standards are being upheld. Regular vulnerability scans should be a priority in this environment as well. Code Reviews, Application Security Assessments and penetration tests should be a goal, but should take a lower priority to completing these same tasks within the PCI environment.

It is possibly even more important that the External facing Presentation Layer be segmented off from the rest of the environment here. This is because any Internet facing hosts are in-scope for PCI external vulnerability scanning and penetration testing. If you do not segment the rest of the PII zone off, you can quickly find this entire zone considered in scope for PCI as well. This will mean that you will now be required to enforce the same standards on this environment that you do in the PCI Zone. This may not seem like a bad thing, but the work load can get out of hand quickly.

Financial Reporting Data – This is the zone where your SOX standards come into play. SOX is, in my experience, one of the most vague sets of standards out there. It mandates that Financial reporting data be secured to maintain accuracy and integrity. The big concern in this Zone can be summed up in a word : Accountability. If we apply the CIA model(Confidentiality, Integrity, Availability) to this Zone, we will see that Integrity is our number one concern, followed by Integrity, and Availability come in a very distant third.

What you should focus on:

·         User Account Management

·         Access Control

·         Auditing/Activity Monitoring

The focus here is going to be a lot more process oriented than technical. Ensure that user accounts are set up properly on all systems, with only the access they need. Make sure there is no sharing of accounts, or use of generic accounts. Make sure that activity on all Financial Reporting systems is logged for auditing to maintain maximum accountability.

Regular audits should be done on this zone to ensure all standards and policies are being properly observed within the zone.  Regular vulnerability scanning in this Zone may be a good idea, but is not a must. If time and resources allow Source Code Review, Application security Assessments, and Penetration Tests should be performed to help validate the security mechanisms in place.

Like the other zones, any Internet facing Presentation Layer should be segmented from the rest of the zone as much as possible. Remember, all Internet facing hosts are subject to PCI.

Critical Infrastructure – The separation of this Zone is probably going to be less dramatic than with the ones we’ve just discussed. It is still a good idea to tightly control the flow of data in and out of this zone though. Regular Vulnerability scans should be performed in this Zone, but only after the above Zones have reached a point in their maturity where the Vulnerability Management efforts are running smoothly. That will allow you to have time for working with System Admins on remediating any findings. Availability may be a much larger concern in this Zone than in some of the others. This zone represents the core of your operations and should be treated carefully. In addition to the Vulnerability Scans, Penetration Testing efforts are a very good idea in this zone.

Do I need to say it again? Any Presentation Layer facing the Internet needs to be additionally segmented. I think you’ve probably got this idea down pat by now.

Desktop Ranges – Desktop networks are a tricky subject. They should be segregated out as much as possible for a couple reasons. One is that you don’t want a compromise of the outer systems to be able to get into the Desktop networks and run amok. Secondly, you don’t want the opposite to happen. Desktop ranges are honestly going to be the most likely entry vector into your network. A lot of attacks on companies start by tricking users into going to web page, or opening a file that they shouldn’t.  If your desktop users have unfettered access, then it is game over.

I cannot stress the importance of applying standards here. Some chief things to think about when looking at standards for your Desktop networks:

1.       Approved Software – Make sure you know what software is safe to run on machines, and don’t allow any other software to be installed without authorization.

2.       Update management – Make sure that all approved software can be updated in a controlled and uniform manner.

3.       File Shares – In my experience as Penetration Tester, this is where you see the most heinous failures. Users often open up shares on their computers to trade files back in forth. The problem is that they do not necessarily know how to secure those shares properly

4.       Running Services – If your desktops are all running Windows Messenger or Chargen, you better have a good reason for it. Aside from these obvious concerns, also think about things like Remote Registry. Remote Registry allows for a lot of troubleshooting and remote administration, but it also opens potential security risks. Weigh the benefits and risks accordingly for your environment.

5.       Anti-virus – I don’t think I need to explain this.

6.       Account Policies – Password complexity, expiration, and lockout policies. Also policies on shared or generic accounts. This also applies to the Local Administrator account. If all of your Desktops run with the same local Admin password, it will only take one Desktop being compromised for this entire Zone to be in danger.

Vulnerability scanning on Desktop ranges is not an easy decision point. There are benefits and risks associated with this activity. As previously stated, the Desktops are going to be one of your most likely entry vectors for an attack. However Vulnerability scans can be potential disruptive, and if you are doing Authenticated scans, you may return a lot more results than you are going to want to look at. If you decide to do Authenticated Vulnerability scans, it will be very important that you have items 1 and 2 from above firmly in place first.

There really shouldn’t be anything to do in terms of Sources Code Review, or AppSec Assessments here.  Penetration Test efforts will almost certainly have a field day in this zone. If there is anything directly Internet facing in this Zone you have done something horribly horribly wrong!

Non-Critical infrastructure – Let’s jump to the ‘Everything Else’ group for a second. This is going to be all of your non-critical systems. These are the things that don’t handle sensitive data, and are not required for day-to-day operations to succeed. The separation of this zone should be defined by the separation and controls placed around all of the other zones. No additional work should be required for separating these hosts out. All of your security activities such as Vulnerasbility Scanning, Penetration Testing, AppSec  Assessments, and Code Reviews should all be  long term goals. Start working on these only after everything is running smoothly in all of these other zones. This is the point at which you’re just cleaning up the rest of the garbage in your Enterprise. If you get to the point where you are cleaning up this Zone you are well on your way to the sustainment phase of your overall Security Initiative.

QA/DEV Systems – QA and DEV environments are a quagmire. The best advice I can give you is as follows.

·         Separate QA and DEV out from the rest of your environment as much as possible.

·         Try to avoid any contact between QA/DEV and the internet.

·         Do not ever allow real production data to reside within a QA or Development Zone.

·         Do NOT Vulnerability Scan your QA and Dev environments. These zones will be extremely volatile, and will be in a  constant state of flux. You will be bogged down chasing vulnerabilities that disappear and reappear at random. If you have segregated these zones appropriately, there is nothing to be gained from Penetration Testing or Vulnerability Scanning in this Zone. Save yourself the headache.

Below is a crude diagram to try and help illustrate this concept. Please note that this does not reflect actual firewall or network placement. It merely tries to illustrate the segmentation.

Metasploit Framework Wishlist

Hello World!

I thought I would share something I have put together. I cross-referenced data about vulns inside http://www.exploit-db.com/ with data on whether those same vulnerabilities had a known exploit module inside the Metasploit Framework. Some of these vulnerabilities are probably quite old, and some of them not very relevant. That being said, if you are looking for some modules to contribute to the Metasploit project, this might be a good place to start.

A couple of caveats:

1. I, in no way, represent Rapid 7 and the development team for Metasploit. I created this list for my own use to try and contribute, and am sharing the list in that spirit.
2. The links from exploit-db create PoCs/Exploits that somebody worked hard on. If you port it to metasploit please remember to give credit to the original exploit author. They did all the hard work.

The List is Here