Identifying Mobile Network Users

WAP (Wireless Application Protocol) was quite cool thing back in the day. It isn’t much used anymore and service providers are dropping it off. One interesting thing with WAP was billing. You could buy content from WAP sites and it was charged to your mobile phone bill. There was no need for registration.

To make the charging possible, your mobile service provider was injecting some special headers like WAP gateway address to your traffic on route, but the most important header was your mobile phone number for sure. Within the traffic, 3rd party was able to get your mobile phone number and knew who to charge.

Picture 1. Header injection.

According to the old comments found from Google, the service providers Elisa and Saunalahti (Saunalahti was already part of Elisa) were injecting your mobile phone number into every request when WAP gateway was used. This happened years ago. The bad guys were also trying to get benefit here and did spread an interesting page via text messages which led non-wanted charges if the page was opened on your mobile device.

In 2012 there was a case in UK where a local service provider O2 was leaking customers’ phone numbers to every website that was visited. The reason for this was technical changes during a routine maintenance.

I created a test page to show all request headers and I accessed the page with my mobile phone using three different mobile subscriptions from the service providers Sonera, Saunalahti and DNA. Only basic headers were seen, nothing was added on route. This was expected outcome.

Picture 2. Service providers.

Testing was done with all working APNs listed by the service providers. Only DNA has a working WAP gateway anymore as far as I know and it wasn’t injecting my phone number, but some other irrelevant information.

Later I found out that Sonera has its own MSISDN entrichment service. There was a short document describing some technical details of the service.

When you make a deal about MSISDN entrichment service with Sonera, you need to provide them the domain name of your website and it must be listening on the HTTP default port (TCP 80). The domain name will be added to Sonera's system and after that a header called "X-UP-CALLING-LINE-ID" is injected into the HTTP requests of the users with the value of the phone number.

Sonera is also giving the ip address ranges where the traffic with the custom header is coming from. It looks like those ranges are used for mobile clients according to their reverses.

There is a test page for troubleshooting. The page shows your phone number if these things are met:

• Mobile subscription from Sonera or Telefinland (Telefinland is part of Sonera)
• Correct APN is used – Either "SONERA", "TELE FINLAND" or "internet"

We know that none of these service providers are revealing your phone number to every web page around the internet, but maybe we could create something with Sonera's test page.

The test page is hosted on the domain "m.tele.fi". There is only some basic information, not much resources. I couldn’t find any XSS vulnerabilities from the domain, but there was a cross-domain policy used with the “basic” configuration.

Picture 3. Cross-domain policy.

If you aren’t familiar with the configuration seen in the picture 3, it’s used for Flash objects to handle data across different domains. As the ”allow-access-from domain” is marked with an asteriks (*), it means that any other domain can access to the site content.

So we just need to create Flash object (SWF), HTML page to load our Flash object and a script for logging. This cross-domain “issue” is very well know for years. From Github you can find a nice POC done by Gursev Singh Kalra which I used here.

The exploiting goes like this (see the picture 4): First the crafted HTML page called "steal.html" is opened and a browser loads the embedded SWF file "XDomainXploit.swf". Both of these files are hosted on the attacker's web server. Flash checks the crossdomain.xml file seeing that it has permission to proceed. Then Flash sends a HTTP request to the test site "whatis.php" and got a response which contains victim's phone number. The last request with victim’s phone number goes to the attacker’s server.

Picture 4. Exploiting.

You might know that Flash isn’t working on mobile phones. At least Android, iPhone and Lumia devices aren’t supporting Flash.

However, mobile broadbands for computers are popular here in Finland and the mobile broadband subscription number (just like a phone number because a sim card is used) is also injected to traffic when visited at the Sonera's test page. So this Flash technique could be used for real.

For Saunalahti and DNA I couldn’t find any reasonable way to make their services to forward phone numbers to a 3rd party. Of course there might be other ways to do that like exploiting browser vulnerabilities. As an example Android users could be targeted by using the recently found SOP bypass in the default browser (CVE-2014-6041).

In addition to the phone number stealing and with help of the information gathered along my investigations, I was able to form a request to view balance and validity of any prepaid subscription by phone number on a specific service provider. Well, that's a minor issue.

Also a backend Perl script containing sensitive information and functions of the prepaid service was found.

Picture 5. Backend script.

Cross-domain policy issue and Perl script disclosure were reported responsibly and both of these issues have been fixed. I never received any reply from DNA abuse team even after an another email to them. My first and the last report to them...

It’s obvious that a phone number can be resolved easily compared to an ip address and this gives a good possibility to identify the user.

I can just recommend you to use a VPN tunnel also in mobile networks to make sure your service provider can’t touch your traffic. Your identity information might be sent out to wrong hands even with properly configured service provider equipment as seen in this blog post. And of course there are +100 other reasons to use a VPN tunnel.

If you’re familiar with the modern MSISDN entrichment and have good knowledge or ideas to share for me, please ping me on Twitter. I would like to learn more.

XSS-haavoittuvuudet sähköpostipalvelussa

Elisa on tarjonnut asiakkailleen jo pitkään ilmaista sähköpostipalvelua, Kotipostia. Palvelu löytyy osoitteesta https://webmail.kolumbus.fi. Reilu kuukausi sitten Elisa otti käyttöön uuden sähköpostipalvelun, joka yhdistää sekä Elisan Kotipostin että Saunalahden sähköpostipalvelun.

Noin kahdeksan kuukautta sitten satuin huomaamaan, että Kotiposti-palvelu on haavoittuvainen useille XSS-haavoittuvuuksille. Tämä tarkoittaa, että käyttäjän on mahdollista injektoida javascript-koodia käyttöliittymään, joka suoritetaan selaimessa. Samaa ongelmaa ilmenee myös Saunalahden sähköpostipalvelussa. Myös muita tietoturvaan liittyviä ongelmia palveluista löytyi.

XSS-haavoittuvuus yleensä todennetaan suorittamalla koodia, joka näyttää käyttäjälle pienen ikkunan selaimessa (kuva 1). XSS-haavoittuvuuksia saadaan ehkäistyä sanitoimalla kaikki web-sivulla näkyvä sisältö, mihin käyttäjä pystyy vaikuttamaan. Selain kun suorittaa aina vain sisällön, mitä sille tarjotaan. Alla karkea esimerkki:

Kuva 1. Sanitointi.

Kuvassa 1 olevan esimerkin lähdekoodiin on määritelty kaksi erillistä muuttujaa:

•    muuttuja 1 = <script>alert(1)</script>
•    muuttuja 2 = <script>alert(2)</script>

Muuttujat tulostetaan sivulle, mutta vain ensimmäiselle suoritetaan sanitointi. Kuten kuvasta 1 on nähtävissä, muuttuja 2 ponnauttaa ikkunan. Muuttuja 1 ei sitä tehnyt. Kun toisesta välilehdestä tarkastellaan lähdekoodia, on huomattavissa, että muuttujan 1 sisältö on sanitoitu ja täten selain ymmärtää, ettei sitä tule suorittaa. Koska muuttujaa 2 ei ole sanitoitu, suorittaa selain sen normaalisti, eikä se näy tekstinä sivulla.

Ilmoitin havainnoistani suoraan Elisan CERTille. Hälyttävin mainitsemistani tiedoista oli, että javascript-koodia voidaan suorittaa automaattisesti, kun käyttäjä avaa vastaanottamansa sähköpostiviestin. Korjaustoimenpiteitä tulisi suorittaa mahdollisimman pian.

Valitettavasti korjaustoimenpiteitä ei ole tehty kuukausienkaan jälkeen. Tämän vuoksi tarkemmat, tekniset yksityiskohdat kuten testauksessa käytetyt lähdekoodit on jätetty pois.

XSS-haavoittuvuuksia on aina silloin tällöin ollut eri sähköpostipalveluissa. Viime vuonna bongasin kuvassa 2 olevan Venäläisen Yandexin sähköpostista pysyvän XSS-haavoittuvuuden.

Kuva 2. Yandex.Mail XSS.

Myös GMailissa on ollut hyvin vakava XSS-haavoittuvuus viime vuonna. XSS-haavoittuvuus esiintyi käyttäjän avatessa saapuneen sähköpostiviestin. Google korjasi ongelman tuntien sisään. Haavoittuvuuden huomasi hetki sitten otsikoissa olleen Rosetta Flashin tekijä Michele Spagnuolo (@mikispag).

Ajattelin esittää kaksi tapausta, joissa hyödynnetään XSS-haavoittuvuutta.

Demonstroitu hyökkäys käynnistetään lähettämällä kiinnostava sähköpostiviesti (kuva 3) kohteena olevalle käyttäjälle molemmissa esimerkeissä. Tässä tapauksessa siis omalle Kotipostin tililleni. Käyttäjän avatessa viestin, suoritetaan hyökkääjän haluama javascript-koodi automaattisesti.

Kuva 3. Kiinnostava sähköpostiviesti käyttäjälle.

Ensimmäisessä demonstraatiossa hyödynnetään apuna phishingiä, jonka avulla hyökkääjä pyrkii saamaan kohteena olevan käyttäjän tunnukset haltuunsa. Käyttäjän avattua saamansa sähköpostiviestin, hänet siirretään suoraan takaisin Kotipostin näköiselle kirjautumissivulle.

Kun käyttäjä avasi sähköpostiviestin, hyökkääjän muodostama koodi latasi sivulle täysikokoisen iframen. Kyseessä on kehys, joita voi luoda web-sivuille. Kehyksen sisältö on ladattu hyökkääjän palvelimelta ja se näyttää vastaavalta kuin aito Kotipostin etusivu. Myös osoitepalkissa näkyvä URL-osoite on Kotiposti-palvelun oma osoite.

Havainnollistamisen vuoksi muokkasin iframen kokoa paljon pienemmäksi, joka on nähtävissä kuvassa 4. Vihreällä värillä reunustettu alue on alkuperäinen sivu ja sen päälle on tehty hyökkääjän sivulta iframe, joka on ympäröity punaisella värillä. Taustalla näkyy selkeästi alkuperäinen istunto, joka on vain piilossa iframen alla. Hyökkäystilanteessa iframe peittäisi siis koko alkuperäisen sivun.

Kuva 4. Iframe luotuna sivustolle.

Kuvassa 4 esiintyvä ”sertifikaattiherja” johtuu siitä, että hyökkääjän sivulla ei ole käytössä HTTPS-protokollaa. Sisältö siis ladataan sekä HTTPS- että HTTP-protokollan yli (mixed content) ja selain ilmaisee asian.

Käyttäjän kirjautuessa takaisin sähköpostiin, ei "kirjautumisprosessi" poikkea mitenkään normaalista käyttäjän näkökulmasta. Sekä sähköpostiosoite että salasana kuitenkin lähetetään taustalla hyökkääjän palvelimelle ja kirjoitetaan tekstitiedostoon (kuva 5).

Kuva 5.  Kerätyt tunnukset hyökkääjän palvelimella.

Käyttäjän istunto Kotipostiin ei ole siis katkennut missään vaiheessa ja hänet ohjataan vain takaisin sähköpostilistaukseen ”kirjautumisen” jälkeen.

On mahdollista, että käyttäjä avaa hyökkääjän lähettämän sähköpostiviestin uudelleen. Kun käyttäjä ohjautuu uudelleen hyökkääjän muodostamaan kirjautumisnäkymään, voi tämä olla jo hieman epäilyttävää. Tämän välttämiseksi käyttäjälle asetetaan eväste siinä vaiheessa, kun sähköpostiviesti ensimmäistä kertaa aukaistaan. Kun sähköpostiviesti avataan toistamiseen, havaitaan evästeen olemassa olo ja viestin sisältö näytetään normaalisti eikä uudelleenohjausta enää tehdä.

Toisessa demonstraatiossa XSS-haavoittuvuutta hyödynnetään kahdesti. Kun käyttäjä aukaisee hyökkääjän muodostaman viestin, aukeaa viesti normaalisti. Taustalla suoritetaan hyökkääjän muodostamaan koodia, joka tallentaa käyttäjän osoitekirjaan uuden käyttäjän, joka on nähtävissä kuvassa 6. Lisäksi myös aiemmin mainittu eväste lisätään, jotta uutta käyttäjää ei yritetä lisätä, jos viesti avataan toistamiseen. Käyttäjälle nämä toimenpiteet eivät näy.

Kuva 6. Osoitekirjan haavoittuvuus.

Vaikkakin osoitekirjan merkintä näyttää normaalilta, on sen yhteyteen lisätty javascript-koodia. Kyseessä on siis myös pysyvä XSS-haavoittuvuus. Eli aina kun käyttäjä käy osoitekirjassa, suoritetaan hyökkääjän haluamaa koodia.

Hyökkääjä voi estää käyttäjää poistamasta kyseistä osoitekirjamerkintää esimerkiksi lisäämällä merkinnän yhteyteen koodia, joka ottaa ”poista”-napin pois käytöstä. Nappi näkyy tällöin harmaana. Käyttäjä pystyy ottamaan napin takaisin käyttöönsä, mutta se vaatii jonkin verran jo osaamista selaimen käytöstä ja HTML:stä.

XSS-haavoittuvuus mahdollistaa käyttäjän istunnon kaappaamisen.

Kun käyttäjä kirjautuu Kotipostiin, hänelle luodaan istuntokohtainen eväste selaimeen. Aina kun käyttäjä navigoi sivustolla, hänelle selaimeen luotu eväste tarkistetaan palvelimen päässä. Kun käyttäjä kirjautuu palvelusta ulos, palvelin kuolettaa käyttäjän istunnon. Vaikka käyttäjällä olisi vielä tällöin istunnon eväste selaimessaan tallessa, ei se enää toimi.

Hyökkääjä siis haluaa käyttäjän istuntokohtaisen evästeen. Kun eväste lisätään hyökkääjän selaimeen, on hänellä sama istunto käytössä kuin käyttäjällä.

Istunnon pituus voi kuitenkin koitua hyökkääjälle ongelmaksi, koska käyttäjä saattaa kirjautua ulos palvelusta. Tällöin katkeaa myös hyökkääjän istunto.

Jos hyökkääjä kokee tarvetta hallita istunnon pituutta, voidaan javascript-koodiin lisätä toiminto, joka näpelöi käyttäjän istuntokohtaista evästettä. Evästeen arvoa muutetaan ja käyttäjä joutuu kirjautua uudelleen sisään. Koska uloskirjautumista ei ole suoritettu, on vanha istunto edelleen aktiivinen ja hyökkääjän hyödynnettävissä.

Testasin vielä myöhemmin istunnon käyttäytymistä pollaamalla Kotipostin saapuneet viestit –näkymää 24 tunnin ajan. Istunto pystyi aktiivisena siis ainakin 24 tuntia, kun sitä aktiivisesti käytettiin. Istunto saadaan siis pidettyä hengissä hyvinkin pitkään.

Suosittelen käyttämään Elisan vastikään luomaa sähköpostipalvelua osoitteessa https://webmail.elisa.fi tai erillistä sähköpostiohjelmistoa. Jos käytät sähköpostia joko osoitteessa https://webmail.kolumbus.fi tai https://webmail.saunalahti.fi, älä avaa yhtäkään saapunutta sähköpostiviestiä.

Käytettävät palvelimet löytyvät Elisan osalta täältä http://asiakastuki.elisa.fi/ohje/22 ja Saunalahden käyttäjille täältä http://asiakastuki.saunalahti.fi/ohje/289.

Vielä ohjevideot ulkoisten sähköpostisovellusten käyttöönottoon: http://asiakastuki.elisa.fi/aihe/sahkoposti_ja_kotisivut/107/

Tämän blogipostauksen sisällön oli tarkoitus antaa osviittaa, kuinka motivoitunut hyökkääjä voi toimia hyödyntäen palvelussa esiintyviä ongelmia apunaan ja miksi XSS-haavoittuvuuksiin tulisi suhtautua myös vakavasti - varsinkin, kun kyseessä on sähköpostipalvelu.

Testaukset suoritettiin vain henkilökohtaisilla tunnuksilla.

Warbiking in Helsinki

Biking is fun and especially when it comes to exploring new places. One day while driving around I got an idea to warbike with my Raspberry Pi. As Raspberry Pi consumes a very little amount of power and fit in a backpack with all other devices, it would be an easy and a light load to carry.

In case you aren’t familiar with the term ”wardriving”, here is a short explanation from Wikipedia:

”Wardriving is the act of searching for Wi-Fi wireless networks by a person in a moving vehicle, using a portable computer, smartphone or personal digital assistant (PDA).”

I didn’t try to access or hack into any networks. The data gathered in this project won't be given to anyone.

I had to decide the area I was going to cover. Usually wardriving is done by driving just bigger streets, but I wasn’t happy doing it that way. So, I defined a little bit smaller area, but I was going to cover it more carefully than usually is done.

By ”more carefully” I mean that almost every part of the every street seen in the map below were covered. Exceptions were like restricted areas and courtyards.

Picture 1. Covered area.

Here is a full list of the devices that were used:

- Raspberry Pi model B (256MB)
- Alfa AWUSO36H WLAN USB adapter (2.4Ghz, 802.11b/g)
- GlobalSat BU-353 GPS receiver
- Anker Astro E4 13000mAh power pack

Picture 2. Devices.

Raspberry Pi was using Raspbian OS. Alfa wlan adapter was grabbing wlan signals and GPS receiver to pinpoint found access points to a map. Note that the Alfa wlan adapter is 2.4Ghz and 802.11b/g.

All this stuff was powered by 13000 mAh power bank. I haven’t done any real capacity tests, but it was enough to power this combination for hours.

I ordered also a wlan adapter to be able to establish a management connection between Raspberry Pi and my mobile phone. However, I never got the wlan adapter.

The equipment was very stable, so I thought It’s okay to warbike without management connection. On my last run Raspberry Pi probably overheated and got stuck. Some access points were missed for sure, but luckily I had already covered the area quite well.

Before the warbiking sessions, I always planned the route with Google Maps. Even though the driving sessions were sometimes very twisting, I had no really issues to stay on the planned route. You just had to remember some reference points in the areas.

The needed processes (Kismet and GPS) were started on Raspberry Pi before closing my backpack and leaving outside. GPS usually got fix in a couple of minutes after going outside. Sometimes it took more than five minutes.

Picture 3. Bike.

Next lets see some (biking) statistics.

Distance (by bike): 106.16 km

Distance (by foot): 9.09 km

Total distance: 115.25 km

Total time: 10.75 hours

Total sessions: 11

There were some places I prefered to walk so that’s why 9.09 kilometers of the total distance was performed by foot. Rest of the kilometers, 106.16 km, was warbiked.

Now the most interesting part. There were 26309 unique access points (BSSIDs) which were broadcasting ESSIDs.

The ESSID which was broadcasted by the biggest amount of access points was ”eduroam”. The total number of access points was 348. Eduroam is some kind of project to allow university students to do network roaming in Europe and all over the world.

The next place goes to ”Univ Helsinki HUPnet” network with 309 BSSIDs. It’s unprotected network owned by University of Helsinki. The network can be accessed with university credentials.

The third one was ”Private WLAN2” with 219 BSSIDs. I couldn’t link this one to any company etc, so I believe this is some default ESSID value assigned by a manufacturer.

There was also a hotel with a big amount of access points. You know, all the areas inside need to be covered for roaming. It’s the same thing with many companies.

Some other much used ESSIDs: ”Private Wlan”, ”WLAN-AP”, ”ASUS”, ”AndroidAP” (hotspot), ”ZyXEL” and ”dlink”.

The two very often seen ESSIDs in Finland are ”ElisaKotiXXX” or similar and ”SoneraGatewayXX-XX-XX-XX-XX-XX”. With these default ESSIDs, Elisa had 670 and Sonera 715 unique access points.

Some years ago the situation wasn’t too good with the used encryption. Now for a long time access points have come with WPA2 as a default encryption setting and you can see it from the results.

Picture 4. Encryption.

WPA(2) is the preferred encryption and it should be used with a strong password. 22621 (86%) of all access points were using WPA(2). WPA and WPA2 were combined because the log doesn’t indicate clearly which one is used.

WEP is totally broken and it can be cracked very easily. 557 (2%) access points had it.

3131 (12%) access points weren’t using encryption at all. Many of these were companies' guest networks according to the ESSIDs.

141 access points with no encryption had ESSID like ”HP-Print-xx-xxxxx”. As far as I know some HP’s printers have access points which allow devices to connect and deliver a print job wirelessly.

In overall the whole project was successful. However, I had forgotten the whole WPS feature and Kismet doesn’t have WPS detection by default, so unfortunately WPS data (enabled/disabled) isn’t available.

In the end I just want to say that I hate these piece of shit stones under my tires. I really do.

Picture 5. Much love for bikers.

Blackshades-käyttäjän jäljitystä

Tuossa jo jokin aika sitten tuli vastaan tapaus, jossa erään ympäristön käyttäjille alettiin tuputtaa linkkiä jar-päätteiseen tiedostoon. Jar-tiedosto (Java ARchive) on siis Java-ohjelmointikielestä tuttu tiedostotyyppi, johon voidaan pakata tarvittavat resurssit ohjelman suorittamiseksi.

Epäilykset heräsivät saman tien kuultuani tiedostosta, sillä kohdeyleisö ja tiedostotyyppi eivät osuneet oikein yksi yhteen. Taas toisaalta kohdeyleisö saattoi olla sopiva tällaiselle kokeilulle. Lähdettiin oletuksesta, että jaettu tiedosto voisi olla haitallinen.

Aloin tutkailla jar-tiedostoa hieman tarkemmin. Yllätyksenä ei tullut, että sen sisältä ei löytynyt mitään kivaa. Tai no, miten sen nyt ottaa.

Puretusta jar-tiedostosta kävi ilmi, että sen tarkoitus oli ladata toinen tiedosto (exe-tiedosto) ja suorittaa se automaattisesti. Exe-tiedoston suoritus ei näy käyttäjälle. Kuvasta 1 on huomattavissa, että vain kaksi virustorjuntaohjelmistoa havaitsi jar-tiedoston haitalliseksi.

Kuva 1. Jar-tiedoston skannaus.

Syynä tähän oli se, että mm. osa merkkijonoista muodostettiin kokonaisiksi vasta jar-tiedoston suorituksen aikana (kuva 2). Haittaohjelmien tekijät luonnollisesti pyrkivät käyttämään erilaisia kikkoja, jotta virustorjuntaohjelmistot eivät tunnistaisi haitallisia tiedostoja.

Kuva 2. Merkkijonojen muodostamista.

Jar-tiedoston lataama exe-tiedosto tunnistui haitalliseksi paremmalla prosentilla (kuva 3):

Kuva 3. Exe-tiedoston skannaus.

Kun haittaohjelma oli asentunut tietokoneelle, otti se yhteyttä C&C-palvelimelle. Suurena yllätyksenä tuli, että kohde-ip-osoite oli suomalainen. On tyypillistä, että C&C-palvelin sijaitsee ulkomailla tai liikenne kierrätetään ulkomaiden kautta, jotta jälkiä saadaan häivytettyä ja C&C-palvelimen alasajo olisi vaikeampaa.

Haittaohjelman levittäjä siis mahdollisesti ajoi C&C-palvelinta kotoaan tai saastuneen, Suomessa sijaitsevan tietokoneen kautta.

Exe-tiedosto oli koodattu Visual Basic 6 –ohjelmointikielellä ja sitä tutkiessa kävi pian selväksi, että kyseessä oli Blackshades commander -haittaohjelma. Kyseessä on ns. RAT (Remote Administration Tool), joita markkinoidaan yleensä ”etäkäyttöohjelmistoina”. Tämän version kohdalla mainostettuja ominaisuuksia on mm. Bitcoin-lompakon "palautustoiminto" ja mahdollisuus haittaohjelman jakamiseen Facebookin kautta.

Haittaohjelman levittäjälle oli kuitenkin käynyt paha moka. Exe-tiedostoon oli jäänyt hänen tietokoneeltaan tietoja, joiden perusteella epäillyn henkilön jäljittäminen voisi olla mahdollista.

Muutamien hakutuloksien jälkeen, kasassa oli jo melkoinen määrä tietoa epäillystä henkilöstä. Löydetyn tiedon perusteella pystyi jo vetämään osittain johtopäätöksiä levittäjän henkilöllisyydestä.

Kuvassa 4 on Blackshades commander -haittaohjelman hallintapaneeli, jossa on esiteltynä saastuneiden koneiden satoa.

Kuva 4. Hallintapaneeli (haittaohjelman levittäjän kuvankaappaus).

Henkilö harrasti myös kaupankäyntiä. Tarjolla olisi ollut parilla kympillä useampia botteja eli valmiiksi saastuneita tietokoneita. Erikoisuutena kaupassa oli se, että saastuneiden tietokoneiden käyttäjät olivat kaikki naispuolisia, suomalaisia henkilöitä ja osalla heistä oli myös web-kamera (kuva 5).

Kuva 5. Myyntikohteita (haittaohjelman levittäjän kuvankaappaus).

Tarjonta ei loppunut tähän. Pelitilejä oli myynnissä kymmenittäin eri alustoille hyvin edullisesti. Pelitilien myyminen taitaa yleensäkin olevan käyttöehtojen vastaista esim. Steamissa ja suuri volyymi sekä todella halvat hinnat eivät anna kovin rehellistä kuvaa kaupanteosta. Myyjä mainitsi itsekin, että ei ota vastuuta siitä, mitä hänen myymilleen pelitileille tapahtuu kaupanteon jälkeen.

Ilmeisesti myös palvelunestohyökkäykset olivat välillä tarpeen. Henkilöllä oli jäsenyys ns. ”stresser”-sivustolle, josta pystyi maksua vastaan tilaamaan palvelunestohyökkäyksen haluamalleen sivustolle. Mitä enemmän jäsenyydestä maksat, sitä pidemmän ja tehokkaamman palvelunestohyökkäyksen saat tilattua. Kuvassa 6 on esitelty erään stresser-palvelun tarjontaa. Kyseinen sivusto ei liity tapaukseen.

Kuva 6. Stresser-palvelun tarjontaa.

Stresser-sivustolta saaduista tiedoista kävi ilmi henkilön aikaisemmin käytössä ollut IP-osoite. Kyseinen IP-osoite antoi viitteen samaan maantieteelliseen sijaintiin kuin haittaohjelman käyttämä C&C-palvelimen IP-osoite ja henkilön asuinpaikkakunta.

Henkilö oli käyttänyt samaa sähköpostiosoitetta useassa paikassa, jonka perusteella asiaan saatiin lisävarmistusta. Myös muita todentavia yksityiskohtia löytyi, joiden perusteella henkilöllisyys varmistui.

Kyseinen henkilö ei näytä olleen kohteena viimeaikaisessa Blackshades-ratsiassa.

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.