Apache HTTP Server 2.4.48 haavoittuvuuden vaikutukset Haltun ylläpitämiin järjestelmiin

Tammikuun 31. päivä havaitsimme, että muutamissa asiakkaidemme tuotantoympäristöissä oli hyödynnetty Apache HTTP serveriin liittyvää haavoittuvuutta. Haavoittuvuus oli tyypiltään palvelunesto, eli järjestelmät oli saatettu tilaan, jossa niitä ei voitu käyttää normaalisti. Käytännössä järjestelmä palautti käyttäjälle ikävän näköisen Error 503 sivun.

Haavoittuvuuden aiheutti ympäristöissä käytössä oleva Apache HTTP Serverin versio 2.4.48, johon ei enää tarjota tukea.

Havainto tehtiin aamulla 07:04 ja kaikki tietoomme tulleet palvelunestot korjattiin tilapäisellä ratkaisulla 07:56 mennessä. Asiakkaitamme on tiedotettu haavoittuvuudesta, sen vaikutuksista sekä suositelluista korjaustoimenpiteistä.

Lisätietoa Apachen haavoittuvuudesta: https://nvd.nist.gov/vuln/detail/CVE-2021-40438

Apache Log4j 2 haavoittuvuuden vaikutukset Haltun ylläpitämiin järjestelmiin

Perjantaina 10.12 Haltun tietoon tuli nollapäivähaavoittuvuus Log4j 2 komponentissa. Arvioimme parhaillaan haavoittuvuuden vaikutuksia ylläpitämiimme järjestelmiin. Tiedotamme asiakkaitamme tilanteen etenemisestä sähköpostitse ja tätä blogipostausta täydentäen.

Taustaa

9. Joulukuuta raportoitiin nollapäivähaavoittuvuudesta komponentissa Log4j 2.14.1 ja osassa sen vanhemmissa versioissa. Haavoittuvuus antoi hyökkääjälle mahdollisuuden ajaa mielivaltaisia komentoja hyökkäyksen kohteena olevalla sovelluspalvelimella.

Arviomme vaikutuksista Haltun ylläpitämiin järjestelmiin

Haltun toteuttamat asiakasjärjestelmät eivät ole java-pohjaisia sovelluksia, joita haavoittuvuus koskettaa.

Haltu käyttää Log4j 2 kirjastoa omassa keskitetyssä lokienhallintajärjestelmässään, joka on ollut altis hyökkäyksille. Käsityksemme mukaan haavoittuvuutta ei ole ehditty hyödyntämään ja olemme rajoittaneet ongelmaa poistamalla kyseisen kirjaston käytöstä 12. päivä sunnuntaina.

Lisätietoja aiheesta: https://log4shell.com ja https://www.kyberturvallisuuskeskus.fi/fi/haavoittuvuus_38/2021

Päivitys: 14.12.2021 kello 14:06 Olemme jatkaneet vaikutusten arviointia ja selvittäneet onko haavoittuvuudella vaikutuksia asiakkaidemme järjestelmiin. Emme ole havainneet haittoja ylläpitämissämme asiakasjärjestelmissä. Tutkimme edelleen asiaa.

Päivitys: 17.12.2021 kello 16:48 Emme ole havainneet haittoja ylläpitämissämme asiakasjärjestelmissä. Seuraamme Kyberturvallisuuden haavoittuvuustiedotteita sekä viestintää ja reagoimme tarvittaessa.

Työpöytätoteutusten teknisestä ratkaisusta.

Dream-alustaan pohjautuvat työpöytäratkaisut kuten Airo-työpöytä ja Edison-työpöytä tukeutuvat Haltun toteuttamaan ja ylläpitämään Dream-teknologiaan. Työpöydän suhteen on esitetty huolta siitä, että teknologia vanhenee ja se ei ole enää tuettu. 

On totta, että työpöydissä käytetään Angular.js versiota 1.X, jolta loppuu pian yhteisön tuki kokonaan. Tätä kirjastoa ei kuitenkaan käytetä lainkaan taustajärjestelmäpuolella (Backend) vaan ainoastaan käyttöliittymäpuolella selaimessa (Frontend). Käyttöliittymäkerros käyttää taustajärjestelmiä yksityisen käyttöliittymärajapinnan (Private UI API) läpi. Tämä API-kerros on toteutettu REST-teknologialla ja käytettävä teknologia on DRF (Django Rest Framework). 

Tämä API-kerros ja teknologia siitä alaspäin on ajantasaista ja pitkään tuettua teknologiaa (Django 2.X ja Python 3.X), jota päivitetään aina tarpeen mukaan ja jonka tietoturvapäivitykset pidetään palveluissa ajantasalla säännöllisesti. 

Käyttöliittymäkerroksessa käytetty Angular.js on valittu siksi, että se tarjoaa työpöydässä käytettäville laatoille parhaan mahdollisen UI-toteutuksen laattojen siirtelyyn ja asetteluun liittyen sekä kirjasto on erittäin hyvin tuettu kaikilla käytössä olevilla selaimilla sekä päätelaitteilla. Angularia käytetään siis ainoastaan visuaalisten elementtien asetteluun. Minkäänlaista tietoturvariskiä Angularin käyttö tällä tasolla ei aiheuta ja Haltu arvioi jatkuvasti päivitystarvetta suhteessa muuttuviin käyttötapauksiin. 

Dream-alusta on kokonaisuudessaan erittäin helposti laajennettavissa ja alustalla on myös avoimia rajapintoja, jotka on dokumentoitu osoitteessa dreamplatform.fi. Käytännössä kuitenkin ulkoiset palvelut eivät ole käyttäneet näitä rajapintoja, jotka ovat toteutettu myös DRF:lla ja joiden teknologia on ajantasalla. Lisäksi rajapinta toteutus on Backend-tasolla, jolloin mahdolliset uudet toteutukset on helppo toteuttaa ilman vaikutusta käyttöliittymäkerroksiin. 

Lisäksi Dream-alustan arkkitehtuuri on rakennettu sellaiseksi, että asiakaskohtaiset räätälöinnit rakennetaan pääasiassa Dream-alustan päälle ja näin mahdollistetaan uusien asiakaskohtaisten toteutusten rakentaminen ilman muutoksia perusteknologiaan. 

Djangoa kohtaan on myös esitetty huolta sen harvinaisuuden suhteen. Haltun kanta kuitenkin on, että Django on erittäin elinvoimainen ja suosittu teknologia erityisesti nuorten yritysten ja uusien kehittäjien keskuudessa. Lisäksi Django on tosiasiassa yksi suosituimmista web-kehitysalustoista ja sitä tukee, kehittää ja käyttää erittäin isot organisaatiot. Lue lisää: https://steelkiwi.medium.com/django-for-product-development-questions-answers-on-django-in-2019-72eaa8230d6b

Löytyykö äppisi Huaweista?

Long story short: Trump ja Kauppasaarto --> uusissa Huawein malleissa ei ole enää Googlen ydinpalveluja (Google Mobile Services, jatkossa GMS) käytössä, ei vaikuta vanhempiin malleihin, kuten esim. Huawei P10, P20, P30, mutta esim. P40 ja P40 Pro eivät sisällä Googlen ydinpalveluja.

Eikö kosketa sinua käyttäjänä tai sovelluksentekijänä?

Kokeillaas toista lähestymistapaa:

Puhelimestasi ei löydy enää Google Play -kauppaa!

Eikä Youtubea. Eikä Gmail-sovellusta!

Alkoiko jo kiinnostamaan?

Eli jos sinulla softan tekijänä tai julkaisijana, startuppina tai yrityksenä on Android-sovellus, niin jatkossa se on ladattava saataville myös Huawei AppGalleryyn, jotta se olisi suoraan ladattavissa Huawein puhelimiin. AppGallery on siis kuten Play-kauppa nykyisissä Android-puhelimissa (tai AppStore Apple-laitteissa.)

Tämän lisäksi tulee huomioida muutamia asioita kehityksessä:

• Sovellus kannattaa alusta lähtien suunnitella siten, että se on ladattavissa sekä Huawein että Googlen kauppaan. Tämä koskee mm. seuraavia toiminnallisuuksia:

  • Push-notifikaatiot: Jos käytät Googlen Push -palvelua, niin Push-viestit eivät tule perille Huaweissa olevaan sovellukseen.

    • Ratkaisu: Toteuta erillinen Huawei variantti sovelluksesta ja käytä siinä Huawein omaa Push-palvelua. 

    • Tämän puutteen ratkaisu ei ole mikään iso homma ja kannattaa myös miettiä, että voiko sovellusta julkaista AppGalleryyn ilman toimivia Push-ilmoituksia, koska moni käyttäjä voi olla tilanteeseen tyytyväisempi kuin sovelluksen täydelliseen puuttumiseen.

  • In-App -Maksutoiminnallisuudet

    • Google Play -palvelut eivät ole käytössä, joten maksut pitää hoitaa toisella tapaa. Tähänkin löytyy Huawein oma toteutus: https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-Guides/appgallerykit-app-iap-0000001055276890

  • Kartat sovelluksissa

    • Google Mapsista on luovuttava, mutta rehellisesti sanottuna, on olemassa paljon kauniimpiakin toteutuksia, joita voisi käyttää sekä Google että Huawei -versioissa.

      • Esim. Here Maps -SDK:ta voisi ymmärtääkseni käyttää molemmilla alustoilla ja välttää kahden eri version välillä kikkailua.

    • Huaweilta toki löytyy tähänkin oma karttatoteutus, johon siirtyminen on erittäin suoraviivaista: https://developer.huawei.com/consumer/en/doc/development/HMS-Guides/hms-map-migrate

    • Lisäksi itselleni vieraampi https://www.mapbox.com/ pitäisi olla hyvä ratkaisu tarjoilemaan kartat alustariippumattomammin.

Nopea summaukseni onkin, dokumentaatioita tutkittuani, että teknisesti kyseessä ei ole valtava ponnistus seuraavista syistä:

• Googlen ja Huawein -palvelujen tekniset toteutukset ovat koodin näkökulmasta lähes identtiset, joten erillinen "variantti" on helppo toteuttaa.

• Voi johtaa hyvään sekä kehittäjän että käyttäjän kannalta, koska muitakin ekosysteemitaisteluja on käynnissä, mm. Googlen ja Amazonin välillä.

• Johtaa parempaan arkkitehtuuriin, koska komponentit tulee suunniteltua siten, että käytettävät palvelut on helppo korvata / vaihtaa.

Suurimmat ongelmat:

• Päättäjät eivät ymmärrä, että sovelluksien tulee olla molemmissa kaupoissa, koska käyttäjät alkavat jakautumaan entistä tasaisemmin eri sovelluskauppojen välille

  • esim. Säästöpankin tunnistussovellusta ja Säästöpankkisovellusta ei ole tällä hetkellä Huawein AppGalleryssä. Sieltä puuttuu myös EasyPark ja Parkman.

  • Huawei-yhteensopivuudella olisi nyt helppoa ottaa kärkipaikka sovelluskaupassa ja myös positiivinen markkinointikulma edelläkävijuudesta.

  • "Katellaan mitä muut tekee, ei me tehä nyt mitään"

  • Jos kohderyhmänä ovat nuoret, niin esim. Honor-sarjan puhelimet ovat asiakassegmentissä erittäin suosittuja. Älä siis tee päätöksiä perustuen omaan iPhone-kaveripiiriisi perustuen. 

• Negatiivinen käyttäjäpalaute yritystä kohtaan, koska sovellus ei ole saatavilla puhelimeen

  • Tämä ei sinänsä ole julkaisijan vika, mutta ei myöskään Huawein vika.

• Huawei on tällä hetkellä 2. suurin Android-puhelinvalmistaja heti Samsungin jälkeen, Huhtikuun tilastoissa Huawei ohitti valmistajana Samsungin. Molemmilla n. 20% osuus. Lähde: https://www.statista.com/statistics/271496/global-market-share-held-by-smartphone-vendors-since-4th-quarter-2009 ja uudempi lähde: https://www.forbes.com/sites/zakdoffman/2020/06/15/samsung-and-apple-beaten-by-huawei-in-huge-new-smartphone-surprise/

• Ylläpidettävä kehityshaara (joka ei oikeasti työllistä niin paljon)

• Hieman enemmän testattavaa

Lyhyt yhteenveto: Älä stressaa liikaa, mutta ota tämä asia huomioon, ennen kuin negatiivinen palaute osuu tuulettimeen.

Jos mielestäsi kirjoitus oli hyödyllinen, niin arvostaisin sen jakamista, jotta tämä tietoa saadaan mahdollisimman monen mieliin.

Mistä saan DUNS-numeron ja mitä se maksaa?

Päivitys 13.4.2021:

Sain sähköpostiviestiä Bisnodelta, jossa kerrottiin, että DUNS-numero palvelu on muuttunut ilmaiseksi. Nyt siis DUNS-numeron saa tarkastettua suoraan palvelusta:  https://www.bisnode.fi/duns/.

Jokaisella suomalaisella yrityksellä on siis DUNS-numero, ja sen voi tarkastaa tuosta palvelusta veloituksetta.

DUNS (tai D-U-N-S) -numero

käytän lyhenteenä DUNS, koska en jaksa kirjoitella väliviivojaMyöntäjä on Dun & Bradstreet (D&B) ja sitä käytetään laajasti tunnistamaan yrityksiä. Meidän liiketoiminnassa DUNS-numero tulee usein vastaan, kun asiakkaamme tarvitsevat sovelluskauppatilin Applelle, voi nykyään olla myös Googlen vaatima.Suomessa numeroa tarjotaan maksullisen palvelun kautta, mutta oikeasti numeron hakeminen on täysin ilmaista ja yksinkertainen prosessi.

DUNS-numeron hakeminen

Yleensä suomalaisilla yhtiöillä ei ole olemassa DUNS-numeroa, mutta jos on, niin se selvinnee tällä Applen työkalulla, jonka avulla voit myös hakea yrityksellesi numeroa, mikäli numeroa ei löydy. Palvelu vaatii kirjautumisen Apple-tunnuksella.https://developer.apple.com/enroll/duns-lookup/#!/searchSinulta tullaan kysymään lomakkeella ainakin seuraavat kysymykset:

• Yrityksen virallinen nimi

• Päätoimipaikan osoite

• Postiosoite

• Työyhteystietosi

Osana varmennusprosessia D&B:n yhteyshenkilö saattaa laittaa sinulle viestiä varmentaakseen hakemuksen oikeellisuuden.Ohje on vapaasti käännetty Applen ohjesivulta osoitteessa: https://developer.apple.com/support/D-U-N-S/

5 tapaa ajaa äppiprojekti metsään

1. Ostat vain tiimin resursseja / osaajia

Sinulla on tarve ohjelmistokehitykselle ja haluat ostaa projektin toteutuksen. Joten haluat tehdä sen niin kuin aina on tehty. Pitää löytää ohjelmistoyritys, jolta löytyy projektipäällikkö ja sopivan kokoinen lauma koodaajia. Toisaalla sinulla on mainostoimisto, joka tuottaa graafista materiaalia. Olet tehnyt itse sovelluksesta kuvauksen ja mahdollisesti ostanut jo käyttöliittymäsuunnittelun ja nyt etsit vain sopivaa toteuttajaa, joka kasaa sovelluksen pystyyn. Ei näin.Varsinkin, jos olet Startup-yrittäjä tai teet jonkinlaista ReStartup -projektia isomman yrityksen sisällä, niin todennäköisesti sinulla on kovastikin seuraavanlaisia rajoitteita:

• Budjetti

• Aikataulu

• Tavoite

• Toiminnallisuudet

Siinä missä ostettu tiimi keskittyy näistä asioita kolmeen, niin mielestäni oikea tapa on keskittyä yhteen. Ja se on TAVOITE. Tavoite todennäköisesti summaa jollain tavalla kaikki muut rajoitteet, mutta mikäli tavoite ei ole selkeästi tiedossa valitulla toimittajalla ja keskitytään vain budjettiin, toiminnallisuuksiin ja aikatauluun, niin todennäköisesti vähintään yksi näistä menee pieleen ja näin projektin tavoitekin jää saavuttamatta. Sen sijaan, tiimi, joka tietää tavoitteen (sekä tietenkin budjetin, aikataulun ja halutut toiminnallisuudet) pystyy keskittymään siihen, että yhteinen tavoite projektille on se, johon on PAKKO PÄÄSTÄ. Tällöin tavoitteen ympärille saadaan aikaan keskustelu, jonka kautta voidaan yhteisymmärryksessä säätää kolmea muuta tekijää niin, että projekti voidaan katsoa onnistuneeksi ja sen päälle voidaan alkaa rakentaa (liike-)toimintaa.

2. Et kerro kaikkea

Luottamuspula tai "eihän tämä nyt liity tähän projektiin millään tavalla" on yksiä suurimpia kiistan- ja ongelmanaiheuttajia projekteissa. Otetaan esimerkkeinä vaikka aikataulu- ja budjetti.

Aikataulu

Olet kertonut softakumppanille, että sovelluksen pitäisi olla valmiina tammikuussa 2020. Mutta se, mitä jätät kertomatta on se, että helmikuun 2. päivä on alkamassa kansainväliset messut, joissa sovelluksen tulisi olla yksi vetonauloista osana uutta tuotelanseerausta. Tiimi ei tiedä asiasta mitään ja mahdollisesti epäselvästä viestinnästä tai sairaspoissaoloista johtuen projektin priorisointi painottuu enemmän toiminnallisuuksiin ja budjettiin.Näissä tapauksissa projektissa viestinnästä alkaa tulla tulehtunutta ja ehkä hakataan jopa nyrkkiä pöytään ja ollaan tyytymättömiä. Samaan aikaan tiimi on ihmeissään, koska projektin sisältö ja budjetti ovat erittäin hyvin hallinnassa. Lopulta palaverin jälkeisellä lounaalla yhdessä tiiminvetäjän kanssa tulee puheeksi, että "niin kun nämä messutkin on viikon päästä ja ei tästä nyt tule mitään.."Joten: Kerro mielummin liikaa kuin liian vähän. Ja jos se hirvittää, niin salassapitosopimuksia luodaan juuri sitä varten, että kaikkein sensitiivisin tieto on varmasti turvassa ja sen voi avata huoletta kumppanille.

Budjetti

Rahasta on tyypillisesti vaikea puhua, varsinkin jos ne ovat kyseessä on on rahaa tai yritys, jonka varoja käytät, on vastuullasi. Projektissa voi olla ikävää keskustella siitä, että homma pyörii vahvasti sijoittajien tai esim. julkisen rahoittajan tuella ja projektin tietyt vaiheet sekä onnistumiset ovat kriteereinä lisärahoitukselle tai maksatuksille.Usko tai älä, voin väittää, että minulla on kokemusta lähes kaikista näistä keisseistä ja ymmärrän erittäin hyvin tilanteen, jossa esim. ELY-keskuksen tai Business Finlandin maksatukset ovat myöhässä. Mutta se, mikä alkaa hiertään minua ja toisaalta myös projektia on se, että tehdystä työstä ei tule maksua ja selittely alkaa siinä kohtaa, kun ollaan jo parin laskun verran myöhässä.Älä siis pidä projektin budjettia tai rahoitusta myöskään salassa, koska hyvältä kumppanilta löytyy varmasti ymmärrystä ja myös neuvoja. Esim. projektin toiminnallisuuksista voidaan valita ensin ne, jotka vaikuttavat eniten rahoituksen jatkumiseen tai käyttäjien saamiseen sovellukseen.Mutta muista myös se, että harvalla softafirmalla on varaa toimia kenenkään pankkina.

3. Julkaisukammo

Uskomusteni mukaan kirjailijoilla on usein sellainen olo, että kirja ei ole koskaan valmis. Samaa asennetta löytyy myös sovellusten tilaajilta, aina pitäisi vähän viilata jotain pikseliä tai "ei tätä voi ainakaan ilman tätä ominaisuutta julkaista", vaikka asiasta ei olisikaan mitään faktoihin perustuvaa tietoa.Suosittelemmekin usein hankkimaan luotettavia testausryhmiä (oikeita käyttäjiä), joiden kanssa voidaan kokeilla sovellusta jo varsin aikaisessa vaiheessa ja sitä kautta selvittää, onko sovelluksesta jo hyötyä käyttäjille. Jos on, niin SHIP IT!Hyödyn jälkeen toki pitää päästä siihen vaiheeseen, että sovellus tuottaa liikevaihtoa, tavalla tai toisella.Ja mikäli asiakkaana haluat olla varmempi siitä, mitä käyttäjät oikeasti haluavat, niin kannattaa tehdä heti projektin alussa käyttäjätestausta esim. prototyypeillä sekä haastatella juuri niitä tulevia käyttäjiä.

4. Etsitään syyllisiä

Aina paras tapa pilata mikä tahansa suhde, on lähteä syyttelemään. Esimerkiksi: "Kyllä tämä ennen toimi, tää on teidän vika, en todellakaan maksa tästä mitään", on oiva tapa saada kitkaa aikaa tiimin osaavien kehittäjien kanssa, kun unohdetaan samalla sellainen sivuseikka, että järjestelmään on tullut esimerkiksi kymmeniä miljoonia rivejä dataa sen jälkeen, kun ensimmäinen versio oli testattu toimivaksi 20 000 rivillä.

Asioista toki pitää puhua oikeilla nimillä ja selvittää, mistä mahdolliset ongelmat johtuvat. Ja joskus alaa syvemmin tuntematta tiedon lisääntyminen järjestelmässä ei tunnu isolta asialta. Samaan aikaan kehittäjistä voi tuntua siltä, että asiakas kiusaa, koska pakkohan hänen on ymmärtää, että tiedon määrä vaikuttaa kaikkeen toiminnallisuuteen, varsinkin kun siihen ei olla osattu varautua.Lisäksi useat järjestelmät nykyään käyttävät ulkopuolisia palveluja ja/tai koostuvat useasta erillisjärjestelmästä, joissa on sekä toiminnallisuuksia ja tietoa. Näin ollen, jos yksikin palveluista ei toimi tai muuttuu niin ettei siitä informoida kaikkia osapuolia, niin ei pitäisi lähteä etsimään syyllisiä vaan rakentavasti keskustelemaan siitä, mitä on tapahtunut ja mikä on saattanut aiheuttaa havaitun ongelman.

5. Ei panosteta markkinointiin

Yhteenkään sovellukseen tai palveluun ei ole tullut käyttäjiä ilman markkinointia. Ja miten enemmän ja ammattimaisemmin markkinoit niin sitä parempiin tuloksiin todennäköisesti pääset. Omassa toiminnassamme meillä ei ole paljoakaan eväitä ammattimaiseen markkinointiin tai esim. kasvuhakkerointiosaamista, mutta omista verkostoista sitä löytyy runsaasti ja pyrimmekin aina auttamaan ohjaamalla asiakkaamme oikeanlaisten kumppanien luo.Itse ennemmin lähtisin tekemään juuri sellaista tuotetta, joka näyttää hyvältä, tarjoaa perusominaisuudet ja tuottaa lisäarvoa tai liikevaihtoa brändille ja heti kun tuotteen pystyy julkaisemaan, niin käynnistäisin siihen markkinointitoimenpiteet, koska ilman käyttäjiä millään sovelluksella ei ole arvoa, mutta ei myöskään suuntaa.