-1

I have no idea if this question is suitable for SO, but I posted it anyway because I'm curious to see if there are any concrete solutions to this.

I am using the MySQL Connector with my game, in order to provide a reliable and persistent connection to store, and retrieve server listings for gameservers within the game. I have to use the MySQL DLLs, thus it is quite obvious that I use MySQL for the connection.

This would be fine, however, a hacker friend of mine last week offered to test my encryption (MySQL password is stored in an encrypted form, and decrypted at runtime), and he succeeded in obtaining all the password, with only a single character missing.

He told me that he had searched for the mysql_connect() function in one of the MySQL DLLs, and intercepted the code when run.

I looked at this, but no answers cover my situation (where the password string is being extracted), and I'm starting to get worried whether it was a mistake to use MySQL for my usage situation, but however I believe that the same thing could happen in any program.

Can I protect against this type of exploit? Should my decrypt function return something other than a string, or can anything from a function be intercepted?

One of the answers to the linked questions says this:

The simplest way is to encrypt them with something trivial like xor or rot-13, and then decrypt them on the fly when they're used. That will eliminate casual viewing of them, but it won't stop anyone with much experience at reversing.

I'm making the assumption that the hacker managed to reverse the encryption, to reveal the password.

Roughly the code:

string server = "crysiswars2.communication.zyboxinternational.com";
mysql_connect(server, decrypt("randomuser1"), decrypt("randompassword2"), decrypt("myport"));`
Community
  • 1
  • 1
AStopher
  • 4,207
  • 11
  • 50
  • 75
  • No. The hacker in your case (your friend) simply slurped the data from the call-stack. Decrypt is already finished at that point. Regarding this exploit, he's effectively debugging code **on the box**. You can't stop that once he's there. its an end-point attack (and apparently the end-point isn't protected sufficiently. – WhozCraig May 19 '14 at 08:13

2 Answers2

4

Encryption protects data in flight, between source and destination. It does not protect against compromised end points.

What you need is end point security. How did your hacker friend even gain access to the running code? That should be on a server. You didn't accidentally put the MySQL code in the locally executing client code, did you?

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • The MySQL code is required in the client, since it needs to retrieve the server listings. I don't know what else to use, apart from MySQL.. – AStopher May 19 '14 at 08:14
  • 3
    Wrap the MySQL code in a HTTP API. The client now executes a simple HTTP GET. Your webserver has the password, but your hacker cannot modify the server. And modifying the HTTP client won't get him the password. – MSalters May 19 '14 at 08:36
1

Well, basically, DLL injection + mysql_connect hook = that is how attacker gets password already decrypted from your own function. What about checking a first byte of mysql_connect function, if it is hooked or no? If first byte == JMP or anything else it shouldn't be, then simply don't call that function.

  • 1
    This deters just the most naive of hackers. What do you think will happen to your checking code? Right, the first instruction will be patched to a `RET`. This kind of protection was regularly defeated in 1970, you have to be pretty naive to use in in 2014. – MSalters May 19 '14 at 08:34
  • Ah, well, that is true too, just NOP verification code if it is inline. –  May 19 '14 at 08:36
  • Well, connecting DataBase directly from client is worst idea to do ever. –  May 19 '14 at 08:37
  • @jakubinf I didn't see you warn me about it when I told you about using MySQL >.<. – AStopher May 19 '14 at 08:52