[OUTDATED] Be wary of AIM Phoenix!


#1

I posted this onto the AIM Phoenix forum (which has since been removed by Wildman. I call damage control!), so best I regurgitate what the heck I’m talking about.

So basically, while I was digging inside the AIM Phoenix program in dotPeek out of boredom, mainly to see how the internals worked, I had noticed that the program feeds the authentication module the password in cleartext, and that the module itself does not hash the password when sending the packet to authenticate, as per normal authentication procedures, which is portrayed in the following two images:

With my new suspicions in hand, I decided to packet sniff what AIM Phoenix (the client) sends during the authentication process to see if the password was sent in cleartext, and I was basically proven correct:

For anyone who doesn’t know what the password is supposed to be under normal procedures, it is supposed to be an MD5 hash, which at least obscures the password from TCP packet sniffing. Here’s an example of such a packet sent out by the official AIM client to the AIM Phoenix server:

But note that this isn’t just tied to the AIM Phoenix client only. It makes you think about how @Wildman_Fujiami stores the password for each registered user in the database. Is it MD5 hashed? Is it cleartext?! The former is insecure, while the latter is an extreme security risk.

Either way, be cautious of using AIM Phoenix, both the client and the underlying service, and stay safe! :slight_smile:


Escargot History 2017-2018
#2

I’ve always been a little afraid, I use a disposable password on AIM Phoenix. :stuck_out_tongue:


#3

Same here.


#4

i use a 100% random password to aim phoenix , also it is unstable as h!@# ( at least in windows 10 and aim 5.9 )


#5

welp, this article has notified me to lose the use of AIM Phoenix. see you all on AIM Phoenix when this is changed.


#6

Maybe we should be more wary of you and your reverse engineering other peoples source code on a whim, you like pissing in my cereal an awful lot don’t you? what’s next, are you going to download all the software i’ve developed for wildman productions, tear that apart, and criticize all that code as well? The Phoenix client is marked “for testing purposes only” and “Alpha” for a reason. I can see i’m going to have to start obfuscating my built binaries again.


#7

fuckin

both of us know theguy wouldnt do that shit. its just it seems you’re storing passwords insecurely.

right, but it’s still used by a few dozen people afaik.


#8

Honestly, I was sifting through the code because I wanted to see how the internals worked, out of curiosity. And no, I’m not trying to rain on your parade. I just feel that it is necessary to tell others that their security is at risk. Not to scare them out of your service, but really, kind of a little wake-up call.

LOL no. I’m not dedicated.

IMO, that’s not really an excuse to have poor authentication security implemented inside.

Also to add on, this isn’t regarding the AIM Phoenix client ONLY, as I stated in the thread. It also branches out to the server itself and how it might store user credentials.


#9

It wasn’t the preferred method nor was it intended to stay that way long, however RealLife™ and other unrelated or unexpected projects have delayed proper development of things that were hacked together to make the program usable quickly, and matching the password hashing was one of those things, as is it’s not much more worse off than if anyone were to be using the older AIM clients since the “encryption” there is just simple XOR


#10

I think it’s best you should’ve waited until you had enough free time to get things properly set up. Rushing things does lead to less than stellar results most of the time, alongside being a bad work ethic. :stuck_out_tongue:

At least it obscures the password from plain view. It’s bad and lazy obfuscation, yes, but at least it’s SOMETHING.


#11

the client now uses the same salted MD5 hash with a random token that the 5.x AIM client uses, so you can send home the fire crews and police.


#12

Well, at least the client-side stuff has now been dealt with. :slight_smile: