[ad]
PuttyHijack is a POC tool that injects a dll into the PuTTY process to hijack an existing, or soon to be created, connection.
This can be useful during penetration tests when a windows box that has been compromised is used to SSH/Telnet into other servers. The injected DLL installs some hooks and creates a socket for a
callback connection that is then used for input/output redirection.
It does not kill the current connection, and will cleanly uninject if the socket or process is stopped.
Details
1) Start a nc listener
2) Run PuttyHijack specify the listener ip and port
3) Watch the echoing of everything including passwords
Some basic commands in this version include;
!disco – disconnect the real putty from the display
!reco – reconnect it
!exit – just another way to exit the injected shell
You can download PuttyHijack V1.0 here:
Or read more here.
Morgan Storey says
I use putty all the time, I just gave this a burl, damn that is scary. So does anyone know if there is a putty update coming or some way to mitigate this, I can’t think of any aside from not using the goodness that is putty; aside the obvious don’t get your box pwned.
Pantagruel says
With Morgan Storey
Scary indeed, given the relative ease with which a Windows box can be compromised (be it XP or Vista).
Will give it a try when at home and see if what it’ll do when using a key file/token auth in combination with a password (why people persist in using ssh access based on password only is still a mystery to me)
Finity says
From the Putty website (http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html):
—————————————————-
A.9.9 Can you sign an agreement indemnifying us against security problems in PuTTY?
No!
A vendor of physical security products (e.g. locks) might plausibly be willing to accept financial liability for a product that failed to perform as advertised and resulted in damage (e.g. valuables being stolen). The reason they can afford to do this is because they sell a lot of units, and only a small proportion of them will fail; so they can meet their financial liability out of the income from all the rest of their sales, and still have enough left over to make a profit. Financial liability is intrinsically linked to selling your product for money.
There are two reasons why PuTTY is not analogous to a physical lock in this context. One is that software products don’t exhibit random variation: if PuTTY has a security hole (which does happen, although we do our utmost to prevent it and to respond quickly when it does), every copy of PuTTY will have the same hole, so it’s likely to affect all the users at the same time. So even if our users were all paying us to use PuTTY, we wouldn’t be able to simultaneously pay every affected user compensation in excess of the amount they had paid us in the first place. It just wouldn’t work.
The second, much more important, reason is that PuTTY users don’t pay us. The PuTTY team does not have an income; it’s a volunteer effort composed of people spending their spare time to try to write useful software. We aren’t even a company or any kind of legally recognised organisation. We’re just a bunch of people who happen to do some stuff in our spare time.
Therefore, to ask us to assume financial liability is to ask us to assume a risk of having to pay it out of our own personal pockets: out of the same budget from which we buy food and clothes and pay our rent. That’s more than we’re willing to give. We’re already giving a lot of our spare time to developing software for free; if we had to pay our own money to do it as well, we’d start to wonder why we were bothering.
Free software fundamentally does not work on the basis of financial guarantees. Your guarantee of the software functioning correctly is simply that you have the source code and can check it before you use it. If you want to be sure there aren’t any security holes, do a security audit of the PuTTY code, or hire a security engineer if you don’t have the necessary skills yourself: instead of trying to ensure you can get compensation in the event of a disaster, try to ensure there isn’t a disaster in the first place.
If you really want financial security, see if you can find a security engineer who will take financial responsibility for the correctness of their review. (This might be less likely to suffer from the everything-failing-at-once problem mentioned above, because such an engineer would probably be reviewing a lot of different products which would tend to fail independently.) Failing that, see if you can persuade an insurance company to insure you against security incidents, and if the insurer demands it as a condition then get our code reviewed by a security engineer they’re happy with.
—————————————————-
Obviously they will work to find a fix and release it sometime soon (we hope)! However for those who aren’t aware of it, I doubt they go out on a regular basis to see if there are any putty updates available! lol
Morgan Storey says
@Pantagruel: I was thinking a key would be an effective fix, but surely if an attacker has the ability to get this dll in they could monitor where you are grabbing your key from and just grab it as well.
@Finity: Yeah I know it is OSS, I don’t expect the dev to fix it instantly.
I guess you could somehow try and sandbox putty, run it as another user that doesn’t have access to any other files/folders, this would mean unless the attacker has access to the security on file system they can’t change the permissions on their dll so that putty will be able to access it.
Other options, verify the md5sum of putty post running it, or run dependency walker ( http://www.dependencywalker.com/ ) and make sure it is not linked to any odd dll’s
Pantagruel says
@Morgan storey
Tried it, worked like a charm.
The initial login doesn’t show where the auth key is stored (or I missed it in the blurp of data netcat received).
First thing in the process of compromising will be gaining total access to every nook and cranny. A remote shell to search for the auth key/download it, a local keylogger to obtain the auth key password and the injected dll will get the the root password shortly.
lyz says
Really creepy. I too use Putty in my everyday work here. I can say I am not a newbie to linux but my knowledge is limited. I would love to see a followup post or comment as to how I can battle with this kind of vulnerability.
Thanks!
Brill says
Altough I am not using Putty since some time ago, as I only works on linux at home or use SecureCRT when working with my Windows Laptop (due to my company restrictions). I agreed that Putty is highly popular so, yeah it can have a wide impact.
Nowadays I have my doubts about the severity of that impact, It would be usefull to have more details (about the socket, etc.)
@Pantagruel when you finish with your tests with key files, certificates, etc. please keep us on the loop, that sounds really interesting.
Morgan Storey says
@CG: correct, but it say you do a DNS exploit and re-direct the putty page to get a compromised version that is just a self-extracting zip with hijack dll and putty.exe inside. Then you get everyone who gets that site.
Or you could say compromise an admin’s laptop or desktop and install the putty hijack on the off chance they use it. You don’t have to be on the box, you could be rdp/vnc/dameware or any other remote trojan compromise.
By the way, great blog carnal, I am subscribed.
Pantagruel says
@Brill
The findings of a 5 minute trial session:
On Listening machine (OpenSuSe Linux 11)
net cat
lyz says
That is really nice of you Pantagruel. Thanks for sharing the details with us. We can make it a basis also here in our tests.
eM3rC says
Yay Pantagruel!
Thanks for the log and thank you Darknet for the post!
Det says
It’s not a vulnerability, it’s not going to be ‘fixed’. It’s a feature.