Nokia Bug Bounty - Hacking Internet Radio Stations

Nokia Internet Radio software was released years ago for Symbian platform of Nokia mobile phones. If you’d Symbian smartphone, you might be familiar with this software. Or at least you’ve probably seen it on the menu because it was pre-installed on some models.

The software is used to listen different radio stations which are provided by broadcasters. The radio stations can be browsed by genre, language and country. To make it possible for the broadcasters to edit their stations, there is a website located in irbcast.nokia.com for that purpose.

Source

After a quick look into the website, I noticed I’m able to remove any station from the service just by changing the id of the radio station in the request. This kind of vulnerability where authorization of the user to the requested object isn’t ensured is resulting in ”Insecure Direct Object Reference” flaw and by that to privilege escalation.

Also it was possible to change details like description and genre of any radio station. At this point it was quite clear that there is probably no authorization check implemented on the edit functions at all.

I was interested in to see if an account could be captured by using this flaw. This means that the id of the broadcaster (victim) is needed, so we can make changes to the right account. The search function on the site was very helpful. After finding the target with the search function and opening source code of the search result, the needed id was found to proceed.

Next victim’s technical email address was changed to our own one by changing the victim's id to the request and ”forgot password” function was used for the victim’s account. The password reset link was received to our own email address and the password was reseted. On the login screen I realized I haven’t got the username of the victim and it isn’t mentioned anywhere on the site. So the only way would be to guess it (like the name of the radio station as an example). Meh.

Even though a full account capture wasn’t possible, technically I had very wide access to the victim’s account. And well, deleting all of the radio stations from the whole service wouldn’t had been a big task.

Exploiting insecure direct object references is very easy and the results can be very bad.

Timeline:

1.7.2013 – The issue was reported to Nokia security
1.7.2013 – I got a human response in a one minute that the report is being forwarded
1-2.7.2013 – Edit functions were disabled on the website
9.7.2013 – Comrade Sintsov from Here dropped a message that the issue has been fixed and I’ll get Lumia 820 as a reward.

Tupaksen ohitus salasanaa palauttaessa

Tutustuin jokin aika sitten Tupas-palvelun toimintaperiaatteeseen. Kyseessä on varmasti monille tuttu palvelu, jossa verkkopankkitunnuksien avulla luodaan luotettava tunnistuminen. Alla kuvaus palvelun toiminnasta (Linkki):

Kuva 1. Palvelun kuvaus.

Käytännön esimerkkinä salasanan palautus:

1. Asiakas surffaa palveluntarjoajan salasanan palautussivustolle.
2. Palveluntarjoaja palauttaa asiakkaalle sivun, josta valitaan käytettävä pankki.
3. Asiakas valitsee käytettävän pankin ja pankki tarkistaa pyynnön.
4. Jos edellä mainittu pyyntö oli ok, pankki palauttaa kirjautumissivun asiakkaalle.
5. Asiakas tekee tunnistuksen pankkiinsa.
6. Onnistuneen tunnistuksen jälkeen pankki muodostaa asiakkaalle Tupas-tunnisteen.
7. Asiakas tarkistaa tiedot ja hyväksyy niiden välittämisen palveluntarjoajalle.
8. Palveluntarjoaja tarkistaa Tupas-tunnisteen ja se liitetään asiakkaan palvelutapahtumaan.

Vahva tunnistus on tehty. Asiakas pääsee vaihtamaan salasanansa.

Kävin muutaman sivun läpi, joissa Tupas-palvelu on käytössä. Yksi niistä oli Soneran Omat Sivut, missä on mahdollista luoda uudet tunnukset tai muokata olemassa olevia tunnuksia Tupas-tunnistusta hyödyntäen. Kuvassa kaksi on esitetty palvelun kuvauksen 2. vaihe.

Kuva 2. Verkkopankin valinta.

Seuraavaksi hypätään aivan loppumetreille, missä Tupas-tunniste tarkistetaan vielä palveluntarjoajan toimesta. Onnistuneen tarkastuksen jälkeen palveluntarjoaja luo salasanan vaihtosivun asiakkaan tiedoilla, joka on esillä kuvassa 3.

Kuva 3. Tunnuksen muokkaus.

Mutta kuinka tuo sivu sitten muodostetaan? Kuvassa 4 on esillä HTTP-pyyntö, josta evästeet ja referer on karsittu pois.

Kuva 4. HTTP-pyyntö.

Useita parametreja on käytetty, mutta suurin osa niistä on tarpeettomia. Jäljelle jätetään vain tarpeelliset ”bank” ja ”custCode” (hetu). Myös evästeet voidaan jättää pois kokonaisuudessaan, koska Tupas-tunnistuksen istuntoa ei sidota tähän pyyntöön mitenkään.

Lopputuloksena saadaan kasattua yksinkertainen salasanan palautuslomake:

Kuva 5. Salasanan palautuslomake.

Pelkän hetun avulla olisi siis ollut mahdollista kaapata toisen henkilön tunnukset sähköpostilaatikoineen.

17.1.2014 – Bugista mailattu Soneralle.

20.1.2014 – Ilmoitus Soneralta, että välitetty palvelun kehittäjille.

6.2.2014 – Testasin bugia, ei toimi enää. Mailia Soneralle.

7.2.2014 – Vastaus Soneralta, että korjaustoimenpiteet tehty.

Korjaustoimenpiteiden jälkeen kuvan 4 kaikki parametrit ovat muutettu pakollisiksi, vaikkakin arvoa ne eivät tarvitse. Asiakkaan tiedot palautetaan nyt Tupas-tunnistuksen istunnosta, ei parametreista.

Uusien tunnuksien luontia en pystynyt ymmärrettävistä syistä kokeilemaan Tupas-tunnistuksen avulla, joten en osaa sanoa, olisiko niiden väärentäminen onnistunut järjestelmään. Vinkkasin kyllä tarkistamaan, kuinka se on toteutettu.