MD5 does not match password

dtm · Post by **dtm** » Tue Jun 16, 2009 2:13 am

If you do an MD5 hash of your ProxyUserPassword it does not match the MD5 hash that is being sent to register as captured with WireShark.

What we think is the password, may not be. Or it is being manipulated before it is hashed.

srvctek · Post by **srvctek** » Tue Jun 16, 2009 2:25 am

Thats what my thoughts were also

kp · Post by kp » Tue Jun 16, 2009 9:01 am

there might be a salt with it.

smartripper77 · Post by **smartripper77** » Tue Jun 16, 2009 9:52 am

And salt might be a value that's comes down when the first request is failed

ATAuser · Post by **ATAuser** » Tue Jun 16, 2009 10:11 am

Heres what I did
1) ran stroths tool to get my SIP information. (great tool btw, dude)
2) wrote that password to a file called dictionary.txt
3) started up cain and able (http://www.oxid.it/cain.html), and started a capture.
4) Started magicJack
5) I then sent the captured SIP packets to the cracker, and used the dictionary file that contained the password from stoths tool.

Then it came back telling me "Attack stopped! 0 of 1 hashes cracked"

I figure either stroths tool is broken (which I doubt, based on the # of people posting here with similar problems), OR mj changed the authentication.

This post tends for me the believe that they somehow did add a salt as kp stated. Or changed their implementation of md5?

That would explain the wrong md5s sniffed from the network.

Anyone else got something to add??!?!

I want my ATA BACK!

dtm · Post by **dtm** » Tue Jun 16, 2009 11:57 am

I get a different MD5 hash every time I capture it with WireShark. I also notice that after the first attempt to register fails, they go to another site and do something. It showed up as "scrambler" in one capture.

What I think is that they have implemented something to change to password hash on every register. This should FU all the ATAs that are doing a plain MD5 hash on a fixed password. In effect the internal password changes every time MJ registers. Is the third party site communicating with both the dongle and the MJ server to salt the password before each login?

Somebody more advanced than I will have to solve this one!

srvctek · Post by **srvctek** » Tue Jun 16, 2009 8:19 pm

Maybe the hash is no longer MD5

kp · Post by kp » Tue Jun 16, 2009 10:45 pm

Heres my thoughts, I have not yet be able to test it. There is some web traffic with https://prov1.magicjack.com, but its all encrypted. If you do a plain HTTP GET request it returns "No records returned!". It got me thinking, what records would the softphone be needing to look up. I think there might be a time based salt that is goten via that request (kinda like how an RSA token works). Again, just my 2 cents.

izzyoo7 · Post by **izzyoo7** » Tue Jun 16, 2009 10:48 pm

I have noticed the same thing when analysing the packet with wireshark.

The first register attemp always fail, follow by 3 more successfull register

Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eeb0270be562290;rport fail
Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eeb42431a90bf31;rport success
Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eebf186a695a292;rport success
Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eec25835e260283;rport success

the same thing happen when requesting to invite the first attemp always fail anf then follow by a success

Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eecef07cae35ec4;rport fail
Via: SIP/2.0/UDP 192.168.0.108:56856;branch=z9hG4bKc0a8006c12eecf2c36d362a95;rport success

From looking at the data, it looks as if on the first register fail, the server sends and encryption key to the usb device, it then encode the password and send a 2nd registration attempt. which then become successful. it is repeated 2 more time. before proceeding with the request to invite

izzy

netdata · Post by **netdata** » Wed Jun 17, 2009 12:54 am

I can almost guarantee you its tokenized

Im working on a fix, although I don't see any feasible way of getting
a ATA device without some heavily modified firmware to work again

All the auths are being done server-side

My goal is to get my smartphone back to working again

Using sipcracker and a few other tools

kp · Post by kp » Wed Jun 17, 2009 8:25 am

netdata -
idk what kinda hardware you have, but depending on what kind of video card you have you could try using a cracker that uses CUDA. I know rainbowcrack gets about 62233 million keys/sec while using the GPU. also please letme know if you find anything out, i.e. if its pass + nonce or nonce + pass, etc. thanks.

kp · Post by kp » Wed Jun 17, 2009 8:39 am

Something else i noticed. in the first register that fails there is this info:
WWW-Authenticate: Digest nonce="1606a36e3_09553",realm="stratus.com",algorithm=MD5

But after that the next register has this, and it succeeds in registering
username="EXXXXXXXXXX01",realm="stratus.com",nonce="1606a36e3_09553",uri="sip:talk4free.com",response="mypasswordhashhere",algorithm=MD5

so i am noticing that the nonce is used there in the next registration, which happens to be successful. So i believe that nonce is somehow used in the hash.

cd550 · Post by **cd550** » Wed Jun 17, 2009 3:59 pm

Per SIP specifications in RFC2617, the Digest Authentication Response is calculated as

MD5( MD5(Username : Realm : Password) : Nonce : MD5(Method : URI))

The colons must be included with unquoted parameters. I added the colon before the Nonce. I believe this is a typo in RFC2617on page 13.
I have verified that this is the formula used by my ATA with parameters from Wireshark. I bridged my two ethernet connections on my PC to get my ATA to communicate thru my PC. I can not get th MJ parameters to verify with this formula.

Have a good day.

dtm · Post by **dtm** » Wed Jun 17, 2009 5:46 pm

Good work cd550! I had considered doing that but was too lazy to run the ATA through the PC to sniff it.

If I am understanding correctly then you are saying that there is something non-standard going on in the MJ software when it comes to generating the hash to register.

Now think about this. If you put zero in the "Register Expires" box on the ATA then it will in fact register however one cannot make or receive calls. Do you suppose this value is somehow tied into the password hash?

Just curious: When the dongle is running, what "Register Expires" value does it use?

mjsbz · Post by **mjsbz** » Wed Jun 17, 2009 5:53 pm

dtm wrote: Just curious: When the dongle is running, what "Register Expires" value does it use?

When I took a look at my PMDump, my register expires was set at 600. This is something that has changed, because I recall it previously being set at another value.

mampostial · Post by **mampostial** » Wed Jun 17, 2009 8:42 pm

I don't think that Register expires has changed since I have it set to default "3600" and I can receive but not make calls. I tried to set it to "600" but never worked, no incoming or outgoing. But with the 3600 I'm able to receive.

My configuration:

Cisco 7960 with SIP 8.7 image

cd550 · Post by **cd550** » Wed Jun 17, 2009 9:47 pm

When reset, my ATA SPA2102 shows 3 attempts at Registering with all failures. I have the Expires set at 180. Then, the ATA seems to try to register every 1200 seconds. Before when it was working it was registering every 180 seconds. My dongle does the initial 4 registerings(takes about 2.5 seconds to complete)and then usually every 30 minutes but some times it does it sooner. Like at 23 minutes or as short as 13 minutes. The ATA completes the 3 registration in about 0.3 second.
The ATA uses the parameters entering into the ATA such as the proxy. The dongle shows a shortened proxy in the authenication digest. For the dongle the nonce value and the digest auth response don't seem to change for subsequent registrations even with intervening Invite messages unless the dongle resets. Subsequent registrations are also single registrations not the "401 unauth" then "200 OK"just "200 OK". The Invite messages use different nonce and digest auth response values. As others have suggested, I think it's totally unfeasible to try to break the password or other changes in the authenication. Best bet is to try to debug/dissemble the MJ software.

kp · Post by kp » Thu Jun 18, 2009 8:37 am

cd550 wrote:Per SIP specifications in RFC2617, the Digest Authentication Response is calculated as

MD5( MD5(Username : Realm : Password) : Nonce : MD5(Method : URI))

The colons must be included with unquoted parameters. I added the colon before the Nonce. I believe this is a typo in RFC2617on page 13.
I have verified that this is the formula used by my ATA with parameters from Wireshark. I bridged my two ethernet connections on my PC to get my ATA to communicate thru my PC. I can not get th MJ parameters to verify with this formula.

Have a good day.

What did you use for the Method vaule ?

kp · Post by kp » Thu Jun 18, 2009 9:05 am

cd550, thats exactly what we gota do. The only other method I was thinking of was cracking the hash inorder to try to find what structure they are using, but given the large keyspace, 80+ characters it would take some real cpu power and time.

cd550 · Post by **cd550** » Thu Jun 18, 2009 1:52 pm

For Method I used "REGISTER" for registering without the quotes.

SL5 · Post by **SL5** » Sun Dec 06, 2009 11:02 am

I don't think anyone has mentioned this, but if you look in the Windows registry under the MagicJack application (I forget exactly where it is), there is a debug flag that you can set to "1" to cause a popup debug window to appear. This debug window contains all SIP network requests and responses so it will eliminate the need to use other network tools.

magicJack and magicJack Plus Support, Reviews, FAQs and Tricks

MD5 does not match password

MD5 does not match password

Cain & Able

sip

Debuggging flag for MagicJack in the Windows registry