Switch to ArdorForum

All users were tips.nxtex.net returned funds from internal accounts. Transactions: 13899270028266019164, 1690823300272364765, 10189066652119471259, 8256565597418971099, 6883549286649452039, 5910164018423016701, 11970454658174868413, 646263189511555032, 10313231332282855407, 10863568029570054317, 14080439766592936036, 9678405528271572912, 7221039002063577511. Recovered the stolen money, the transaction: 1703526922393187434, 13289921332883233931, 17124052872197985977 (4th account belongs to me, so compensation is not required).
Currently the service is audited security, therefore temporarily not available. Thank you for your understanding and patience.

I hope you can fix this, because I really liked this service. I guess I tipped already 150 NXT and had still 450 NXT on my tip account which you have just returned as I see.
I don't get why anybody hacks tips account for some NXT but better now than when many people start using this service.

Started yesterday to tip with your service. Good work hope it returns soon.

Quote from: jones on December 03, 2014, 06:19:35 am

Yeah, I noticed my tips funds were stolen, all good, it was only like a dollar and a half, if you need help figuring out how they got in feel free to bounce ideas off of me, I enjoy breaking stuff 

Thank you for your suggestion in finding vulnerabilities. If you wish, I can reveal to you the access to the site (need your ip address), then you can hack it ... or is there another method? ))

Most likely (80%) I already know what was the reason and why only 4 flowed account, but unfortunately, I can not prove.

I looked through your js and everything looks fine there, no vulnerabilities that I could find, I think the problem was in how you generated the passphrases for the accounts, I would make sure that the passphrase key generation is secure and they are stored in a place that no one can get to, I've found that storing one level of a hash and generating the passphrase from some 1000 round of sha256 on top of the stored passphrase data. I wish you luck on updating it.

We open in the next couple of days...

It would be recommended to check for sql injection(also login, signup etc...). Its not coincidence that only 4 accounts are cleaned out. Is some value(checked) in the database thats distinguish them from the rest. Probably they were waiting for a cronjob to be send?

It would be recommended to check for sql injection(also login, signup etc...). ...

..  the method for password generation.

- that was much, much simpler. I'm sure, scor2k will explain it to public, like he had showed to me, including that attacker's AM. Note: the server was not compromised (and attacker admitted that in his AM), for example p2p exchange nxtex.net still working without any issues.

Quote from: jones on December 03, 2014, 06:43:22 pm

I looked through your js and everything looks fine there, no vulnerabilities that I could find, I think the problem was in how you generated the passphrases for the accounts, I would make sure that the passphrase key generation is secure and they are stored in a place that no one can get to, I've found that storing one level of a hash and generating the passphrase from some 1000 round of sha256 on top of the stored passphrase data. I wish you luck on updating it.

Thanks for audit Passphrase is 80 random chars from string below:
 

Code: [Select]

$chars="qazxswedcvfrtgbnhyujmkiolp1234567890QAZXSWEDCVFRTGBNHYUJMKIOLP#_-^&!@()";After that, the passphrase is encrypted public key (2048 bits) and stored in the database.


The private key for decryption is not stored on the server in the clear. Just I developed defense mechanisms that block decoding data in the presence of any suspicious events on the server (for example, a ssh connection from an unknown address, though it is blocked on the iptables).

how do you generate your random number?
SHA256 on the 80 char password would make it more effective, especially if the random number generator is not random.
still I am confused at how 4 different accts could have been compromised...

Please post the method for password generation. If it cannot withstand being known (eg. it is security via obscurity) it is not secure.

There are usually ways to make it cryptographically secure, so that even with full disclosure of the method, the attacker would need to crack something pretty difficult, eg. SHA256 collision, reverse curve25519, etc.

James

I posted my method in the previous post.

I does not make sense to encrypt passphrase irreversible encryption methods as required to confirm the transfer of donations constantly, so I use 2048 bit public and private key. The private key is encrypted with the PGP and my fits in server memory manually after entering the personal code (more than 16 chars) from keyboard.

Quote from: scor2k on December 04, 2014, 03:04:07 am

Quote from: jones on December 03, 2014, 06:43:22 pm

I looked through your js and everything looks fine there, no vulnerabilities that I could find, I think the problem was in how you generated the passphrases for the accounts, I would make sure that the passphrase key generation is secure and they are stored in a place that no one can get to, I've found that storing one level of a hash and generating the passphrase from some 1000 round of sha256 on top of the stored passphrase data. I wish you luck on updating it.

Thanks for audit Passphrase is 80 random chars from string below:
 

Code: [Select]

$chars="qazxswedcvfrtgbnhyujmkiolp1234567890QAZXSWEDCVFRTGBNHYUJMKIOLP#_-^&!@()";After that, the passphrase is encrypted public key (2048 bits) and stored in the database.


The private key for decryption is not stored on the server in the clear. Just I developed defense mechanisms that block decoding data in the presence of any suspicious events on the server (for example, a ssh connection from an unknown address, though it is blocked on the iptables).

there was an AM send to my tip address that stated that the funds were stolen due to the fact that the secretphrase showed up on his public node due to TCP listening during a request to start forging.

why would someone use a public node to start forging?
this tipservice is really cool, so I want to make sure it is secure

why would someone use a public node to start forging?
this tipservice is really cool, so I want to make sure it is secure

almost all tx are ok to send publicly (as long as they are signed locally), but start forging is one of the exceptions

It was my fault, as I wrote above I do not run forging, I made the transaction and did not sign them locally, as it was necessary. Now I have corrected the situation, now uses only the local node!

PS. I'll planed to use this code:
$pwd2 = '';
for ( $i=0; $i<rand(4)+4; $i++ ) { $pwd2 .= substr(str_replace('+', '.', base64_encode(pack('N4', mt_rand(), mt_rand(), mt_rand(),mt_rand()))), 0, 22); }
$hash2 = hash('sha512', $pwd2);
tips@tips:~$ for i in `seq 1 5`; do php -f 1.php; done
password: O831bHr.Z5xGZ2m3XG5g0gZMV7sleIVadXqzxhFdiQZgXEf77kCHcKBTjfd2bsskBwDu/KnRol8DU6knGWGEy1qQZ31Nmw9xttY5J9fzOviBAQ
after hash512: e4fc583fb1f911211af32c07e698f4f5a254481787214a53e848149dfa916d9010a4dab143e02c05c757cbc1f1d3e5e57773bbfe89e7c6bb836b39a4df606b57


password: SGuQZnkQVMtYRDlsciXIcgPRAfEQCpu8NDpHfKT1qrUQUIFWm3ePBIkjGqm/ZUCDNAcj03NjmbaflNqK4SAXbiSAdAE5Q2YOkYJ86kWQEuBoPwE477sGXMY8BvuXcfaKqX5A
after hash512: bd3d4180e0312be88d90a4b40aab87385a6f001e10f0f392dc481f0cf8e6ab53e41fe7a48f151930856e9e38d7d022661262611c09a065c69126ccb75db2b637


password: Z11tTSWZIfQ6S6AnZn1BHgBBoBM2NFpbhLfv1XBWzTpwcyWCnF3gXedcn31aSkgqXwYqwgR3ZtUjhAATN/d9Jr9gKTDD0V2nOFsmu8I5GeLjMAPR6WbT7hvmER5i4yV17EBQ
after hash512: 2a0496db6d3146ebd20be710e2431512f7640305c939991489c7d2dada4a4104325ad20cbade8fd438f367f35cf1beca0dacf4019d8adafa3b18125a6179c983


password: ZbdmpBkQcHJnF5FgCtBqiAecyBuxFM/2AGYDMPW/YpRQcUb83xUG0UYJgSjYYzgDJADP7iix2hdgNrM9uvNEZ/eAd5Xlblw/cYMeQYJlFvNZjw
after hash512: 2154ea5da26314d6c54456abd5bb2626c508d36240f5588f65c6ce4259e170656e6879f1ed24e59fa4164d2767dabeb7ef5e78be9d5431b9fa19c269b64a0282


password: S.ImJghF1IYS0xHlZYnELAVmdF4wwq96ALrDDdePJRRQMWmDHFs87KpKcKA8c0lYXwOucVz2caxzYPADJvLD.FPQO/VQmHdvj58357bvL3bkCw
after hash512: f1123197873e7fe9b131993ea4033fd46f2e1cef58d3ec92cc2108523740e13438357565ad71fd7a85fc4e53fe8c36f202a7e6957566cc6ffa83ca18635b200b