https://bitcointalk.org/index.php?topic=935898.msg10259625#msg10259625
Without more familiarity with the code, my reading of this code is that it would, at most, have allowed the hacker to push the contents of some file (ONLY if said file/directory is set readable by the username executing the irc server and/or infected client program!) back to the person (and others) who put it in place. In short, it would explain how an attacker could pull a wallet.dat file off of an infected machine (which, assuming the wallet was password protected/hashed, would make the brute-force much MUCH easier). But it doesn't explain why the IRC server or wallet client progrm was running on a server which also had the filled wallet.dat files!!!! And it sure as hell wouldn't explain the stupidity of running an irc server or infected client as root or however else we're expected to believe this happened.
Furthermore, it wouldn't grant more access to the user running the irc server or infected client than he had been given by root. And if the wallets were not owned and not readable at the OS level by the user account running the irc server or infected client, then this little exploit would NOT be able to read the wallet.dat file!! The OS itself would have blocked it!! Each and every coin's client, as well as the irc server itself, should have been running under its own separate username account that ONLY had, at most, access to an empty wallet file owned (so far as the OS is concerned) by that same username account. User Bitcoin (or something appropriate) should have been running the bitcoin client, with another user like user Litecoin running the Litecoin client, etc., etc. This would have limited the reach of any infected clients. A separate or virtual machine for each coin would have been even better!
Are we really expected to believe that Cryptsy had a wallet.dat file with pub/priv keys that controlled $4mil or so on the same physical machine as one running an infected Lucky7coin client? Sorry. That's gross negligence if true. And I for one do not believe it for a second.
Without more familiarity with the code, my reading of this code is that it would, at most, have allowed the hacker to push the contents of some file (ONLY if said file/directory is set readable by the username executing the irc server and/or infected client program!) back to the person (and others) who put it in place. In short, it would explain how an attacker could pull a wallet.dat file off of an infected machine (which, assuming the wallet was password protected/hashed, would make the brute-force much MUCH easier). But it doesn't explain why the IRC server or wallet client progrm was running on a server which also had the filled wallet.dat files!!!! And it sure as hell wouldn't explain the stupidity of running an irc server or infected client as root or however else we're expected to believe this happened.
Furthermore, it wouldn't grant more access to the user running the irc server or infected client than he had been given by root. And if the wallets were not owned and not readable at the OS level by the user account running the irc server or infected client, then this little exploit would NOT be able to read the wallet.dat file!! The OS itself would have blocked it!! Each and every coin's client, as well as the irc server itself, should have been running under its own separate username account that ONLY had, at most, access to an empty wallet file owned (so far as the OS is concerned) by that same username account. User Bitcoin (or something appropriate) should have been running the bitcoin client, with another user like user Litecoin running the Litecoin client, etc., etc. This would have limited the reach of any infected clients. A separate or virtual machine for each coin would have been even better!
Are we really expected to believe that Cryptsy had a wallet.dat file with pub/priv keys that controlled $4mil or so on the same physical machine as one running an infected Lucky7coin client? Sorry. That's gross negligence if true. And I for one do not believe it for a second.