Tämän avoimen kirjeen on tarkoitus tavoittaa yliopistojen, ammattikorkeakoulujen, lukioiden ja ammattikoulujen tietoturvasta päättävät henkilöt. Team ROT tarjoaa yhdelle Suomalaiselle koululle ilmaisen teknisen tietoturvatestauksen.
Olemme Team ROT, meitä on kuusi henkilöä ja tietoturva on intohimomme. Teemme teknisiä tietoturvatestauksia järjestelmiin ja laitteistoihin, sekä vapaa-ajallamme, että päivätyöksemme. Olemme osallistuneet lukuisiin haavoittuvuuspalkinto-ohjelmiin (engl. “Bug Bounty program”) maailmanlaajuisesti ja tiimimme jäsenet ovatkin tunnettuja myös kansainvälisesti. Nyt haluamme parantaa Suomen koulujen tietoturvallisuutta ja haluamme tarjota yhdelle Suomen koululle ilmaisen työpanoksemme, jotta Suomi ja suomalaisten koulujen järjestelmät saadaan turvallisemmaksi.
Team ROT järjesti vuonna 2017 #kuntahaaste -kampanjan, jossa tekemällämme työpanoksella paransimme Suomalaisten kuntien tietoturvallisuutta. Vuonna 2018 osallistuimme Visman järjestämään Visma Hackday -tapahtumaan, jossa testattiin useiden koulujen käyttämän Wilma-järjestelmän tietoturvallisuutta (https://www.visma.fi/blog/visma-hackday-suomi-ruotsi-maaottelu/). Nyt haluammekin jatkaa tällä Suomalaisten koulujen tietojärjestelmien tietoturvallisuutta edistävällä tiellä, ja olemmekin päättäneet lanseerata #kouluhaaste -kampanjan.
Pyydämme halukkaita kouluja ilmoittautumaan mukaan #kouluhaaste -kampanjaan huhtikuun 2019 loppuun mennessä lähettämällä vapaamuotoisen ilmoittautumisen sähköpostiosoitteeseen team@rot.fi. Team ROT valitsee halukkaiden koulujen joukosta yhden koulun, johon tietoturvatestaus suoritetaan. Testaus sisältää teknisen tietoturvatestauksen, joka suoritetaan Team ROT -jäsenten toimesta valitun koulun järjestelmiin yhden, vielä määrittelemättömän viikonlopun aikana. Team ROT kontaktoi valittua koulua toukokuun 2019 alkupuolella.
Tietoa testausprosessista
Jotta tietoturvatestaus olisi mahdollisimman sujuva ja reilu molemmille osapuolille, koulu voi määritellä itse halutun kohteen tai kohteet sekä halutessa rajata tietyt testitapaukset pois testauksesta. Team ROT kuitenkin suosittelee, että testauksen kohteena olisi mukana mahdollisimman laaja osa koulun järjestelmiä. Näin ollen koulu hyötyy Team ROT:in tekemästä työstä mahdollisimman laajasti.
Testausaikana Team ROT pyrkii olemaan aiheuttamatta ongelmia kohdejärjestelmien saatavuuden, eheyden ja luottamuksellisuuden kanssa, mutta kuten kaikessa testauksessa, odottamattomia ongelmia voi esiintyä. Täten Team ROT ei ota vastuuta mahdollisista ongelmista, jotka testaus suorasti tai epäsuorasti voi aiheuttaa. Team ROT suosittelee, että testaus suoritetaan sellaisena ajankohtana jolloin mahdollisista esiintyvistä ongelmista aiheutuu mahdollisimman vähän haittaa koulun normaalille toiminnalle, esim. testaus suoritetaan viikonloppuna koulun loma-aikana.
Testauksen lopputuotoksena kirjoitetaan raportti, jossa raportoidaan kaikki testauksen aikana havaitut tietoturvaongelmat. Raportti toimitetaan koulun tietoturvatestaukseen valitulle yhteyshenkilölle, yleensä koulun tietoturvavastaavalle. Jos havainto koskee koulun ulkopuolista organisaatiota tai kolmannen osapuolen toimittajan sovellusta, Team ROT ilmoittaa havainnoista myös Traficomin kyberturvallisuuskeskukselle, CERT-FI:lle. Tämä sen takia, että haavoittuvuuskoordinointi kolmansien osapuolten kanssa onnistuisi mahdollisimman sujuvasti. Kun raportoidut havainnot ovat korjattu, Team ROT julkaisee niistä yhteenvedon. Yhteenveto käydään lävitse ennen sen julkaisemista yhdessä koulun kanssa ja sisällöstä poistetaan osapuolten halujen mukaisesti luottamuksellinen ja/tai yksilöivä tieto.
Team ROT pidättää oikeuden julkaista tiedon haavoittuvuuksien kokonaismäärästä jo ennen tietoturvahaavoittuvuuksien korjaamista, mutta tarkempia tietoja haavoittuvuuksista tai osallistuvaa koulun nimeä ei julkaista ennen tietoturvahaavoittuvuuksien korjaamista tai erillistä testattavan koulun antamaa kirjallista lupaa.
Terveisin,
Team ROT
Team ROTia #kouluhaaste’eessa tukemassa:

Nowadays, wireless 4G connections are fairly popular way of connecting to internet. Most of the internet service providers provide at least some form of 4G-package and usually they also include a free 4G-modem along with the 4G-package. These free devices are usually just re-branded versions of other vendor’s devices. This blog post examines various vulnerabilities of a re-branded ZTE MF910 4G modem.
The research was started by connecting the ZTE-device to a computer normally and a connection was initiated in a way the manual instructed. A moment later, the administrative web-interface revealed itself with a default password of ‘1234’.

WAN-to-LAN-attack: Send SMS-messages by chaining CSRF, XSS, weak default credentials and another CSRF

The features provided by the web interface were examined and it was discovered that goform_set_cmd_process-functionality is used to send various commands to the modem. This functionality uses a single http-request in which various values are supplied with GET-parameters.
The available commands were then examined and one of the most interesting commands was possibility to send SMS messages to given phone numbers. This command however requires that the user is authenticated to the web interface. It also requires that the “Referrer”-header of the http-request matches IP-address of the modem, thus making CSRF-attacks which originate from third-party domain impossible.

Easiest way to bypass the previously mentioned protections would be finding XSS-vulnerabilities which allow sending requests with proper “Referrer”-value. Thus began the search for a XSS-vulnerability.
None were found in the goform_set_cmd_process, however a single reflected XSS was found in goform_get_cmd_process-functionality that is used to fetch data from the modem. The web interface uses GET-parameter named “cmd” to specify which command the functionality should execute. By inserting a malicious javascript-payload to this GET-parameter, the server places this payload to the http-response thus triggering an XSS on the web interface.
This XSS on the goform_get_cmd_process-functionality did not require any authentication and had no CSRF-protection, which made it a great initial attack point for further attacks.

Next by crafting a special javascript payload for the XSS, it could be instructed to send http-request towards the SMS-functionality. As the request was sent from a page hosted by the modem via XSS, the “Referrer”-header value is now set to modem’s IP-address thus allowing access to the command.
The SMS-functionality however still required that the user is authenticated. As the modem does not force users to change the default password and uses same password for every device, this was bypassed simply by using the XSS to send a login-request with default password.
However a new problem was encountered during the exploitation attempt. The XSS allowed only a short payload which did not have enough space for sending the login-request and the SMS-message. This was bypassed fairly easily by splitting the payload in half. A second-stage payload contains the javascript that sends the login-command and the SMS-command. This second-stage payload is hosted on an external domain. A very simple first-stage payload was then supplied to the initial XSS and its only purpose is to load the second-stage payload script.

First-stage payload

Second-stage payload

Finally, the exploitation succeeded and by executing a CSRF-attack from a page hosted in internet, the full exploit chain was executed and the SMS-messages were sent to phone numbers specified by the adversary. Exploitation of this kind of attack is fairly severe as it requires nearly no user interaction and the initial attack can begin from WAN-side.
https://youtu.be/BLIWNBp-u34
An example attack scenario would be for example, when the user clicks on a link on e.g Facebook, the payload will trigger and the exploit will login to the system and send tons of SMS messages to whichever number that adversary defined in the payload. This will then lead to a situation where monetary consequences are caused to the owner of the modem and the targeted phone number will be filled with spam-messages.

Modem Takeover

In practice, a hacker will be able to change any settings from the MF910 device via the previously introduced CSRF-based exploit chain. For example, an adversary can hijack the web interface and take over the modem by using the exploit chain and the functionality which the modem uses for changing passwords.

Stored XSS

When creating new contacts, a “groupchoose”-parameter can be used to store malicious JavaScript payload in a contact that will be run each time contact page is opened.

This vulnerability is also exploitable via WAN-to-LAN-attack by using the previously introduced exploit chain.

Persistent denial-of-service

The goform_set_cmd_process-functionality contains a command “SET_WEB_LANGUAGE”, which is used to specify language of the web interface. By setting value of this command to fi”, brick, the modem will be bricked and the user can’t access the web interface anymore. Only way to recover from this denial-of-service condition is to do a factory reset on the modem.

The vulnerability can be exploited through a simple CSRF, however it requires that the “Referrer”-header matches IP-address of the modem. Thus, the previously introduced exploit chain can be used to exploit also this in a WAN-to-LAN-attack.

Conclusion

Current state of security in IoT-devices seems miserable (“The S in IoT stands for security”). This product did not prove otherwise. However when these vulnerabilities were reported to the manufacturer, the manufacturer reacted very quickly and all findings were fixed within couple of days, so there is light at the end of the tunnel. New firmware versions which fix the vulnerabilities were released to the original device and to the re-branded devices.

• Jarmon loistava raportti Blind XSS:stä LähiTapiolalle: https://hackerone.com/reports/159498
• Jarmon haastattelu Bugcrowd Bug Bounty alustalla: https://blog.bugcrowd.com/researcher-spotlight-putsi
• Jarkon artikkeli siitä miten valvontakamera otetaan haltuun: https://blog.rot.fi/2017/02/17/tp-link-tl-sc3171g-ip-camera-r00t/
• Iiron seminaariesitys Tesla Motorsin lähdekoodin saamisesta: https://www.youtube.com/watch?v=2a8EgCeBOzw
• Jaken artikkeli mobiililaitteen liikenteen kaappamisesta ja analysoinnista: https://blog.rot.fi/2017/02/07/decomposing-lan-security-with-scapy-and-burp-suite/

Team Rot tarjoutuu käyttämään 15h/henkilö/kohde kunnan järjestelmien teknisen tietoturvan tutkimiseen. Havaitut ongelmat raportoidaan kunnan määrittelemälle henkilölle, yleensä siis tietoturvasta vastaavalle. Tämän lisäksi Team Rot ilmoittaa havainnoista myös Viestintäviraston kyberturvallisuuskeskukselle, CERT-FI:lle joka avustaa tarvittaessa esimerkiksi koordinoinnin kanssa jos haavoittuvuus koskee kunnan ulkopuolisia organisaatioita tai vaikkapa ulkoiselta toimittajalta ostettua ohjelmistoa. Kun raportoidut havainnot on korjattu, niin Team Rot julkistaa niistä yhteenvedon. Yhteenveto käydään ennen julkistamista lävitse yhdessä kunnan kanssa ja sisällöstä poistetaan tarvittaessa esimerkiksi luottamukselliset tiedot.
Havaittujen haavoittuvuuksien kokonaismäärä voidaan julkaista ennen varsinaista ongelman korjaamista, mutta haavoittuvuuksien tarkempia tietoja ja osallistuvaa kuntaa ei julkaista vielä tässä vaiheessa.
Jotta tietoturvatarkastus olisi mahdollisimman sujuva ja reilu kummallekin osapuolelle, niin kunta voi määritellä itse halutun kohteen ja esimerkiksi rajata tietynlaiset testitapaukset pois tarkastuksesta. Team Rot kuitenkin suosittelee että kohteena olisi kaikki kunnan järjestelmät, jotka ovat saatavissa julkisessa verkossa. Näin ollen kunta hyötyy Team Rotin tekemästä työstä mahdollisimman paljon. Team Rot pyrkii olemaan aiheuttamatta minkäänlaista ongelmaa kohdejärjestelmän saatavuuden, eheyden ja luottamuksellisuuden kanssa testauksen aikana.
Mikäli kiinnostuit, ota yhteyttä niin sovitaan jatkosta ja muista mahdollisista velvoitteista.
Sähköpostilla: team@rot.fi
< Iiro Uusitalo
< Jarkko Vesiluoma
< Jarmo Puttonen
< Jake-Matti Lahtinen