Lately I have been doing some reverse engineering, and I decided to try to test a wide range of portuguese software and write a few posts about it. So for the first batch I picked up some software, that I got to known through a google advertisement.
I got interested about the company because they dealt with payments, and I thought their software would be a nice candidate for the first post. I downloaded almost every application on their website, and on the Play Store and I started to tinker with them.
Some were interesting others not so much…
Asynchronous payment solutions
After the disassembly of the first application, I noticed that the process used was far simpler than I had imagined. These applications generate references offline based on the client IDs and they only have to check if the payment shows up on the parent company.
This one wasn’t fun… ;)
SMS Application
So I moved to the next application, a bulk SMS sending application, I started by firing up some monitoring tools and then opened the app, and started by trying a dummy login after receiving the error message I checked the network activity and spotted something strange, the data had a non standard cryptography implementation. I notice this because there were 2 pieces of encrypted data encoded with base64 with about the same size separated by this “|!|123|$|”, it was very odd and it peaked my interest.
I then tried a couple more things to generate more data and I noticed that the number of encrypted blocks was very low on logins so i did a few more tests, and arrived to the conclusion that the first chunk of encrypted data didn’t seem to have a random IV or counter and the second chunk of encrypted data was in CBC mode and it had a fixed key and iv.
I disassembled the EXE and started looking for encryption functions, after a few minutes I spotted that the PRP used, was AES 128 bits in CBC mode and then I saw a very odd function… the pseudo code would like something like this…
function pre_encrypt ( plaintext, password, salt) {
string payload = plaintext+”||”+password+”||”+salt;
//the arguments for this function would be plaintext,password,salt,IV,hashalgorithm,iterations,keysize
return encrypt(payload,password,salt,”FIXEDIV”,”SHA1”,2,128) + ”|!|123|$|” + encrypt(payload,”fixedpassword”,”fixedsalt”,”FIXEDIV”,”MD5”,2,100);
}
This pre encryption function grabs the plaintext, password and salt passed, concatenates them into a long string to be encrypted. The string is then encrypted twice, each one on each side of the previously mention separator. There are a lot of problems here, from the key generation functions (an obsolete and faulty Microsoft version of PBKF1) used further along the execution path, to the biggest problem which is the password and salt which are hardcoded on the binary and it can be recovered by a simple string extraction.
So this may not be a critical product for the company but I think these problems are big enough to expect even more flaws to be on the server side, and those might be critical enough.