Megaphone is in no hurry to close the old security holes

Not so long ago, netAn published an interesting article describing the security problems of the Megafon system - Service Guide.

As time passed, we decided to check how much Megafon cares about the security of personal data of its customers, and conducted a little testing of authorization products in a “service guide”. The result was not successful, Megaphone really corrected the mistake that the habro community threw at them, but for some reason they did not dare to go further and check the entire system.

I will not repeat what can be done with the subscriber’s account having access to the “service guide” (see the article ) will go straight to sweets.
')
As the analysis showed, in Megaphone, there is an internal gate with which messages.megafon.ru , moscowsg.megafon.ru and many other subscriber authorization applications will be connected. Using mobile applications "UMS" and "Megaphone Disk" you can select passwords with high speed due to the absence of the need for a full authentication procedure.

A letter was sent to Megafon’s technical support service a few weeks ago about this issue, but strangely enough it didn’t respond to our email. At the time of December 11, nothing is fixed.

To analyze the traffic of a mobile application, we use evil mitmproxy
And now more about each.

"UMS"

An example of an HTTP request and authorization responses

Request: POST https://auth.messages.megafon.ru:15020/tellin/login.do Host: auth.messages.megafon.ru:15020 x-UserAgent: iPhone|iPhone0.0|iPhone OS 0.0.0|0.0.0.0|aVBob25lIDRT|aVBob25l Accept-Encoding: gzip Content-Type: text/xml;UTF-8 Accept-Language: zh-CN,en,* Cookie: JSESSIONID=000000000000000000000000 Content-Length: 344 Connection: close Proxy-Connection: close User-Agent: UMS 0.0.0.0 (iPhone; iPhone OS 0.0.0; ru_RU) XML-like data <?xml version='1.0' encoding='UTF-8'?> <root> <user>+7926000000</user> <random>HUAWEI RCS0000-00-00</random> <secinfo></secinfo> <version>0.0.0.0</version> <clienttype>2010000</clienttype> <pintype>0</pintype> <requestip>653.289.953.846</requestip> <usertype>0</usertype> <deviceID>NvQPSFL3nclMuRJbc8KjjgIBn6CVg49mpzNZoJ4LK0n2OQDpcEENuly9FVK5</deviceID> </root> 1)   Response: Raw [ base64  3680  ] 2)   Response: <root><return>200050401</return><desc>The user information is incorrect.</desc></root> 

"MegaDisk"

An example of an HTTP request and authorization responses

 Request: POST https://oauth.megafon.ru/login?oauth_token=92cd604414ba74ff7a3e Host: oauth.megafon.ru Accept-Language: ru User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 0_0_0 like Mac OS X) AppleWebKit/0.0.0 (KHTML, like Gecko) Mobile/0B Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: https://oauth.megafon.ru/login Content-Type: application/x-www-form-urlencoded Connection: keep-alive Proxy-Connection: keep-alive Cookie: ID=IGmYDY6caHVX\nsFELs55iR7wPyhSMvQHc Content-Length: 141 Origin: https://oauth.megafon.ru Accept-Encoding: gzip, deflate URLEncoded form version: 1 token: HkyOryj8L0nAsL7AMgd2JjqjaO language: ru validateform: QR3g4qMeSF0tPHT9COXCKD4guGeYdwHGFBgrPi1eHr msisdn: 7926000000 p:  login: LoginRU 1)   Response: HTTP  302 2)   HTTP   302 

There are two problems in these applications:

1. Receiving information about the successful verification of a pair of phone number and password, we do not continue further authorization and thus does not send SMS informing the subscriber about authorization in UMS
2. By default, SMS informing when authorizing via a mobile device is disabled in UMS

Solution options:

1. Use encryption at the first stage of authorization
2. Show captcha
3. Send SMS notification when trying to authorize
4. Using alphabetic passwords

Checks carried out using as a goal your own phone number.