Tietoturva-arjen kysymyksiä ja vastauksia kirjan perusteella
Ohje: Valitse nimikoimaton tehtävä alla olevasta luettelosta. Nimikoi se eli kirjoita nimesi sen alkuun numeron jälkeen ja nimen jälkeen toteutuskerran tunnus muodossa (201*-x), missä x=s tai k. Laadi 100-150 sanan mittainen vastaus määräaikaasi mennessä tehtävän alle, ja noudata Moodlen keskustelualustalla olevia lisäohjeita.
Neil Bergman, Mike Stanfield, Jason Rouse, Joel Scambray: Hacking Exposed: Mobile Security Secrets & Solutions, 2013.
Jotkin tehtävät on laadittu mukaillen sitä, millaisiin kysymyksiin kirjoittajat itse kertovat kirjansa lukujen vastaavan. Vastaukset tällä sivulla riittää rajata sopivaan osaan tätä kenttää, kunhan rajauksesta on jokin maininta. Kirjan verkkosivu.
1. Miten suuren uhkan vääränlainen matkapuhelinverkko muodostaa käyttäjälle?
Ville Koskinen (2014-k)
Kirja esittää muutaman skenaarion, joiden avulla tunkeutuja voi luoda valetukiaseman GSM-verkkoon, johon käyttäjät liittyvät. Ensimmäinen on Rohde&Schwartzin valmistama testilaite GSM-verkkojen testaamiseen, joka käytännössä toimii tukiasemaemulaattorina. Emulaattoriin täytyy vain syöttää 3-numeroinen maakoodi ja 3-numeroinen operaattorikoodi, joilla määritellään verkko johon halutaan tunkeutua. Ongelmana kaappauksessa on se, ettei testilaite pysty emuloimaan muita matkapuhelinverkon ns. core-elementtejä, joten käyttäjän kannalta vaikka hän onkin kytkeytyneenä verkkoon, ei hän kuitenkaan pääse käyttämään verkon palveluita kuten puheluita. Seittiselaaminen voidaan mahdollistaa kytkemällä verkkokaapeli laitteeseen, mutta muiden ominaisuuksien mahdollistaminen vaatisi huomattavasti enemmän.
Käyttäjän toimista verkossa voidaan tässä skenaariossa kaapata lähetetyt tekstiviestit, datayhteydet ja puheluyritykset.
Toisessa esimerkissä otettiin käsittelyyn pienen alueen kattavat femtocell-tukiasemat, joita voidaan asentaa esimerkiksi toimistorakennuksien sisätiloihin. Koska femtocell-tukiasemien ohjelmisto perustuu Linuxiin, oli siihen jo uutena valmiina hyökkäystyökaluja tarjolla. Samanlaisen femtocell-tukiaseman pystyi myös rakentamaan yksinkertaisista radioista ja OpenBTS-ohjelmistosta, jolloin hintaa tukiasemalle syntyy kirjan mukaan noin 1500 dollaria. Hyökkääjä voi rakentamansa tai kaappaamansa tukiaseman avulla kaapata käyttäjien puhelut, tekstiviestit ja tiedonsiirron ilman, että käyttäjät huomaavat sitä. Rajoitteena on femtocellien rajoittunut lähetyskantama, mutta jo alle 100 dollarin panostuksella voidaan lähetystehoa sekä kantamaa parantaa huomattavasti.
Kysymykseen, miten suuren ongelman vääränlainen matkapuhelinverkko voi käyttäjälle aiheuttaa, vastaus on: suuren. GSM-verkossa vain käyttäjä tunnistautuu verkolle, eli verkko ei tunnistaudu käyttäjälle. Näin ollen käyttäjä ei voi mitenkään varmistua onko hänen matkapuhelimensa liittynyt ”aitoon” verkkoon vai ”väärään” verkkoon. Myöhemmissä verkkosukupolvissa myös verkon täytyy tunnistautua käyttäjälle.
2. Onko Applen aidatun puutarhan bisnesmalli hyvä myös tietoturvallisuuden kannalta? (Älä käsittele luvun 5 iOS-asiaa)
Juha Jokinen (2014-k)
Kirjoittajan mukaan Applen aidatun puutarhan malli on tehnyt iOS-käyttöjärjestelmistä yhden turvallisimmista mobiililaitteiden käyttöjärjestelmistä. Alkujaan Apple ei hyväksynyt laitteisiinsa ollenkaan kolmannen osapuolen sovelluksia lataamista, mutta myöhemmin näiden sovelluksien lataaminen käyttäjien laitteisiin on mahdollistettu App Storen kautta.
Tämä tapahtuu kuitenkin Applen valvomana. App Store on vahvasti rajoitettu eli sinne ei voi vapaasti lisätä sovelluksia ladattavaksi, vaan kaikkien sieltä ladattavien sovelluksien on oltava Applen hyväksymiä ja allekirjoittamia. Tällä tavalla Apple estää tietoturvallisuuden kannalta haitallisten sovelluksien päätymisen sovelluskauppaan ja sitä kautta käyttäjien laitteisiin. Lisäksi sovellusten käyttöoikeuksia on rajoitettu siinä määrin, että niillä ei ole pääsyä kaikkiin laitteen resursseihin.
Kirjoittajien mukaan aidatun puutarhan mallin avulla ei voida kuitenkaan saavuttaa täydellistä turvallisuutta, vaan iOS-käyttöjärjestelmällä on kuitenkin omat heikkoutensa, jotka mahdollistavat hyökkäykset Applen laitteisiin. Mutta aidatun puutarhan malli on suurin syy siihen, minkä takia iOS-käyttöjärjestelmään on tiedossa merkittävästi vähemmän haitallisia sovelluksia muihin mobiililaitteiden käyttöjärjestelmiin verrattuna.
Nykyään Applen puhelimia voidaan ”jailbreikata”, mikä mahdollistaa Applen rajoituksien kiertämisen. Jailbreikattuihin puhelimiin voidaan esimerkiksi ladata App Storen ulkopuolisia sovelluksia, mikä tekee laitteista kuitenkin haavoittuvaisempia haittaohjelmille.
3. Mitä tietoturvan kannalta villiä Androidin ekosysteemissä on kirjoittajien mukaan?
Tuomas Kunnamo (2014-k)
Ehkä suurimmaksi ongelmaksi Androidin tietoturvaa ajatellen kirjassa mainittiin sen eri versioiden määrä ja hajanaisuus. Useimmat eri laitevalmistajat tekevät Androidista oman hieman erilaisen versionsa käyttäen hyväkseen sitä, että Android on julkisen lähdekoodin projekti. Laitevalmistajat eivät kuitenkaan tee päivityksiä omille Android-versioilleen yhtä nopeasti, kuin Androidiin tulee. Tästä seuraa, että Androidin virallisesta versiosta korjatut tietoturva-aukot saattavat jäädä elämään pidemmäksi aikaa laitevalmistajan omaan versioon. Tämä on luonnollisesti aika huono tilanne tietoturvaa ajatellen. Yleensä voidaan ajatella, että open-source ohjelmistot ovat tietoturvallisia, koska kaikki halukkaat pääsevät näkemään koodin ja täten antamaan vinkkejä mahdollisista bugeista ja tietoturva-aukoista. Laitevalmistajien omien Android-versioiden lähdekoodit ovat kuitenkin usein suljettuja, joten tätäkään etua ei saada.
Tämän lisäksi toiseksi ongelmaksi kirjassa mainitaan Android-applikaatioiden välinen kommunikaatio. Tämä suurentaa hyökkäyksille altista pinta-alaa ohjelmissa. Ohjelmistokehittäjien täytyy olla varovaisia koodinsa suhteen, ettei ohjelmaan jää aukkoja, joita haittaohjelma voi hyödyntää.
4. Kuvaile jokin luvussa 5 esitetty Android-haittaohjelma ja siltä suojautuminen
Tuukka Lahti (2013-s)
Luvussa käsiteltiin useita erilaisia Android-haittaohjelmia (ja yllättäen vain yksi iOS-haittaohjelma). Näistä suurin osa vaati toimiakseen ohjelman asentamisen kolmannen osapuolen sovelluskaupasta. Poikkeuksen tähän joukkoon tekee DroidDream, joka aikoinaan oli niin yleinen, että muistan itsekin törmänneeni kyseiseen haittaohjelmaan.
DroidDreamin toimintaperiaate oli yksinkertainen: Googlen sovelluskaupan (kirjassa viitattu nimellä Google Play Store mutta taisi noihin aikoihin kulkea vielä nimellä Android Market tai vastaava) paketti korvattiin uudella paketilla joka sisälsi alkuperäisen ohjelman lisäksi myös haitallisen koodin. Asennuksen yhteydessä ohjelma pyysi paljon tarpeettomia oikeuksia (puheluiden tekeminen, järjestelmätyökalujen käyttäminen, muistikortin sisällön muokkaaminen ja niin edelleen).
Ohjelman käynnistyksen yhteydessä ohjelma käynnisti ylimääräisen Asetus-palvelun lähettääkseen puhelimen tietoja hyökkääjän palvelimelle. Tietojen lähettämisen jälkeen haittaohjelma roottasi puhelimen hyödyntäen kahta eri androidista löytynyttä haavoittuvuutta - adbd:ssä ja udevissä. Roottauksen jälkeen haittaohjelma pystyi asentamaan uusia ohjelmia - joita se myös asensi - muun muassa latausmanagerin, jolla haittaohjelma pystyi asentamaan päivityksiä ja uusia ohjelmia käyttäjän huomaamatta. Tässä vaiheessa DroidDreamilla olikin jo täydellinen hallinta kaappaamaansa puhelimeen ja hakkeri pystyi hallitsemaan ohjelmien asentamista ja tietojen varastamista suoraan palvelimeltaan (Command and Control server).
Google paikkasi DroidDreamin käyttämät tietoturva-aukot Androidin versiossa 2.2.2 ja poisti saastuneet ohjelmat Play Storesta. Symantecin arvioiden mukaan jopa 50k - 200k puhelinta sai tartunnan ja haittaohjelma jatkoi elämäänsä Play Storesta poistamisen jälkeen kolmannen osapuolen sovelluskaupoissa. Paras keino ohjelmalta suojautumiseen oli yksinkertaisesti kiinnittää huomiota ohjelmien asennuksessa vaatimiin oikeuksiin - jos ohjelma pyysi asennusvaiheessa sellaisia oikeuksia joilla se ei tee yhtään mitään (esimerkiksi peli joka haluaa soittaa puheluita) oli kyseessä todennäköisesti haittaohjelma.
5. Millainen kokonaisuus iOS-haittaohjelmia luvussa 5 esitellään?
Samuli Huhtamäki (2014-k)
Toisin kuin Googlen Playn ja kolmansien osapuolten kaupassa, joissa haittaohjelmia on runsaasti, Applen kauppa on suhteellisen puhdas. Kourallinen iOS-haitakkeita on julkaistu, ja niistäkin suurin osa on "jailbreakatuille" puhelimille, eli pääkäyttäjän oikeuksille mahdollistetuille puhelimille.
Ensimmäinen haittaohjelma löydettiin kesällä 2009. Se väitti itseään iPhonen tärkeäksi päivitykseksi ennen uutta 1.1.3 laiteohjelmistoa eli firmwarea. Tämä vaikutti puhelimeen siten, että jos sen asennuksen poisti, niin jailbreakatun puhelimeen asennettuja ohjelmia, kuten Doom, Launcher ym. lakkasi toimimasta. Tekijäksi paljastui 11-vuotias lapsi, tai niin hän väitti puhelimessa. Tekijä löytyi ModMyiFone forumilta, jonka kautta paljastui rekisteröintitietojen perusteella puhelinnumero.
Marraskuun alussa 2009 löytyi haittaohjelma, joka hyödynsi jailbreakatun iPhonen SSH-palvelimen "heikkoutta" eli siihen asetettua oletussalasanaa eli "alpine" - jos sellaisen oli puhelimeen asennettu. Haittaohjelma ilmoitti viestin, että puhelin on murrettu ja, että lunnaita vastaan puhelimen murto poistuu ja haittaohjelma sen mukana. Hollantilainen teini oli tämän takana. Hän pyys myöhemmin anteeksi ja poisti ilmaiseksi ohjelman.
Myöhemmin marraskuussa 2009 australialainen teini julkaisi ensimmäisen iOS-madon, iKee, joka myös käytti hyväkseen SSH:n haavoittuvuutta. Tämä muutti käyttäjän taustakuvan pop-laulaja Rick Astleyn kuvaan. Tämän jälkeen mato etsi tietystä IP-avaruudesta muita haavoittuvia puhelimia. Heinäkuussa 2012 ensimmäinen Applen kaupassa esiintynyt haittaohjelma julkaistiin, nimeltä ”Find and Call”. Se latasi uhrin puhelinnumerot palvelimelle, ja sen jälkeen palvelin aloitti roskapostittelun tekstiviesteitse.
6. Mitä heikkouksia mobiilipalveluihin autentikoitumisen järjestelmissä tuodaan esille luvussa 6?
Mika Mäenpää (2013-s)
Suurin osa mobiili- ja web-sovelluksista autentikoi käyttäjän salasanapohjaisella autentikoinnilla. Lisäksi käyttäjät eivät halua koko ajan kirjoittaa uudestaan salasanaansa käyttäessään palvelua. Kuitenkaan salasanan ja käyttäjätunnuksen säilömistä selväkielisenä mobiililaitteella ei suositella.
Yhtenä ratkaisuna on token-perusteinen autentikointi. Ensimmäisellä kerralla käyttäjä kirjautuu sisään normaalisti. Tämän jälkeen säilötään autentikoinnin yhteydessä saatu token, jonka avulla kirjaudutaan tulevaisuudessa. Vaikka hyökkääjä saisikin tokenin käsiinsä, järjestelmät voivat rajoittaa vahinkoja asettamalla tokeneille järkevät vanhenemisajat, rajoittamalla sen laajuutta, mitä tokenilla saa tehdä, ja poistamalla oikeudet tokeneilta, jotka ovat mahdollisesti paljastuneet ulkopuolisille.
Luvussa käsitellään lisäksi tarkemmin autentikoinnin framework OAuth 2. Joitakin OAuthin heikkouksia mainitaan. OAuth ei pakota käyttämään TLS:ää liikennöinnissä, joten tokenit voivat paljastua matkalla. OAuth 2 on lisäksi haavoittuvainen Cross-site request forgerylle, koska CRSF:ältä suojaava parametri on määritelty suositelluksi, mutta ei pakolliseksi osaksi speksiä. Lisäksi mainitaan ongelmalähteiksi tokenit, joille on annettu liikaa oikeuksia sekä tokenit, joille on annettu liian pitkä vanhenemisaika tai ei vanhenemisaikaa ollenkaan.
7. Mitä heikkouksia luvun 6 mukaan löytyy mobiiliselaimista?
Viljami Salmi (2013-s)
Monet kehittäjät haluavat tehdä ohjelmia, jotka toimivat eri alustoilla. Tähän tarkoitukseen on käytössä erilaisia tapoja, mutta yleisin tapa on internet-selaimen tai internet-näkymien käyttö applikaatioissa. Näitä ohjelmia tehdään HTML5-koodilla ja JavaScriptillä (JS), ja myös JavaScript-silloilla, joilla voidaan käyttää laitteen natiivitoiminnallisuuksia. Näin pystytään minimoimaan alusta- ja käyttöjärjestelmäspesifin koodin tekeminen.
Molemmat käyttöjärjestelmät, iOS ja Android antavat mahdollisuuden määrittää kustomoituja URI-schemejä. Tämä mahdollistaa saastuneen JS- tai HTML5-koodin käyttää natiiveja toiminnallisuuksia. Nämä hyökkäykset käyttävät hyväkseen luottamusta selaimen ja kohteena olevan applikaation välillä. Näin kohteena oleva puhelin voidaan saada lähettämään viestejä tai jopa soittamaan numeroihin, joihin hyökkääjä haluaa laitteen ottavan yhteyttä. Molemmat käyttöjärjestelmät sisältävät URI-schemen tel, joka avaa puhelin sovelluksen ja asettaa siihen numeron johon halutaan soittaa. Käyttäjän tulee itse painaa vielä SOITA-nappia, jotta puhelu alkaa. Skypessä oli ennen vastaava URI-scheme "skype", joka ei kysynyt skypepuheluun hyväksyntää vaan aloitti puhelun välittömästi.
JavaScript-siltoja voidaan hyväksikäyttää molemmissa käyttöjärjestelmissä. Molemmissa on mahdollisuus applikaatioiden käyttää WebView-oliota, jolla voidaan sisällyttää applikaatioon selainkomponentti, josta voidaan näyttää mobiilia internetsisältöä. Silta voidaan molemmissa järjestelmissä luoda natiivin mobiilitoiminnallisuuden ja WebViewissä suoritettavan JS-koodin välillä. Tällä tavoin voidaan myös lähettää viestejä tai yhdistää puheluita. Lisäksi tällä haavoittuvuudella voidaan tehdä Man in the middle -hyökkäyksiä, missä lähtevä liikenne kiertää hyökkääjän palvelimen kautta ja näin hyökkääjä pääsee käsiksi liikenteeseen kahden puhelimen välillä.
Hyvä tapa pitää puhelin turvallisena on tarkastaa oikeuksia, joita applikaatiot tarvitsevat. Jos esimerkiksi peli haluaa oikeudet puheluiden tekemiseen on kyseessä todennäköisesti jokin haittaohjelma. Nämä hyökkäykset käynnistyvät silloin kun tietty iframe on sijoitettu web-sivujen koodiin ja puhelin voidaan saada tekemään melkein mitä vain haitallista.
8. Miten mobiililaitteiden hallinta eli MDM-järjestelmät vaikuttavat niiden tietoturvallisuuteen?
Tomi Saarinen (2013-s)
Mobiililaitteiden hallintajärjestelmät mahdollistavat rajatussa määrin kaikille laitteille pakotetut yhteiset ja etähallittavat asetukset. Silloin kun ne toimivat oikein, niiden avulla voidaan valvoa ja pakottaa etähallitut laitteet noudattamaan vaadittuja tietoturva-asetuksia ja pyyhkiä tai lukita vaarantuneet laitteet. Yritysorganisaatioissa, joissa käytetään mobiililaitteita, joilla käsitellään ja tallennetaan arkaluontoista dataa, ne ovat ehdottomasti tarpeellisia, sillä ilman niitä laitteiden valvonta niiden kulkiessa käyttäjien mukana ties missä olisi ylläpidolle aivan mahdotonta.
Kirjassa kuitenkin puhutaan paljon siitä, kuinka helposti aikaisempia MDM-järjestelmiä on pystynyt ohittamaan. Mobiililaitteet harvemmin ovat jatkuvasti yhteydessä etäpalvelimeen eli MDM-asetukset on tallennettu laitteelle paikallisesti, joten niihin on mahdollista päästä käsiksi ja niitä muokkaamalla sallia tai olla sallimatta uusia asioita. Lisäksi monet MDM-järjestelmät perustuvat siihen, että puhelimen käyttöjärjestelmä toimii niinkuin sen pitää. Tilanteissa, joissa itse järjestelmää on muokattu, eli esimerkiksi jailbreakattu iPhone, MDM-järjestelmälle itselleen voidaan syöttää väärää tietoa, vaikka oikeasti toimittaisiin toisin. Sen takia yksi nykyaikaisten MDM-järjestelmien avainominaisuuksia on omien ja puhelimen asetustiedostojen valvonnan lisäksi pyrkiä kaikin mahdollisin keinoin havaitsemaan puhelimen käyttöjärjestelmän murtaminen.
Kolmas, missä voidaan päästä MDM-järjestelmän kimppuun, on sen liikenne palvelimen kanssa. Useimmat MDM-järjestelmät pohjautuvat client-server malliin. Jos puhelin laitetaan esimerkiksi lentokonetilaan, niin yhteys etäpalvelimeen menetetään eikä sieltä siten saada enää ohjeita ja näin saadaan hyvin aikaa käydä joko MDM-järjestelmän tai sen suojelemien tietojen kimppuun. Tästä syystä MDM-järjestelmiin on usein lisätty myös omaa päätöksentekologiikkaa, etteivät ne olisi täysin etäpalvelimesta riippuvaisia. Jos puhelimeen päästään riittävästi käsiksi, niin hyökkääjä voi lähettää palvelimelle virheellisiä vakuutuksia MDM:n toimivuudesta. MDM-sovelluksien lähdekoodit eivät tietenkään saa olla liian helposti selvitettäviä, sillä muuten niiden heikkoudet ja toiminta on helposti selvitettävissä. Varsinkin android-puolella koodin selvittäminen on ollut liiankin helppoa ja siksi koodin hämäännyttämiseen on jouduttu panostamaan.
Asian yhteenvedossa kuitenkin tiivistetään, että MDM-työkalut ovat kehittyneet paljon, mutta paljon on vielä tehtävää. Kuten muullakin tietoturva-alalla niin MDM-järjelmät ovat jatkuvassa kovassa kilpailussa hyökkääjiä vastaan.
9. Mitä sellaista mobiilisovellusten laatijoiden pitäisi ottaa huomioon tietoturvan kannalta, joka on erilaista kuin epämobiileissa sovelluksissa?
Marko Leppänen (2014-k)
Kirjassa mobiiliympäristössä piilevät uhat, jotka sovelluskehittäjän on huomioitava, on jaettu kolmeen luokkaan: käyttäjä itse, laitteen muut ”omistajat” (sidosryhmät) ja tiedot (assets).
Käyttäjä voi vaarantaa oman tietoturvansa pitämällä bluetoothia ja Wifiä turhaan päällä, jolloin laite voi yhdistyä vaaralliseen tukiasemaan. Yhteyttä ei välttämättä tarvitse itse edes kytkeä päälle. Käyttäjä saattaa ”jailbreikata” laitteensa, jolloin ympäristö jossa ohjelma ajetaan, saattaa muuttua tietoturvan kannalta merkittävästi.
Toisin kuin koti PC:llä tai kannettavalla, mobiililaitteilla on useita sidosryhmiä pääkäyttäjän lisäksi: sovelluskaupan tunnuksen omistaja, joka saattaa olla eri henkilö kuin laitteen omistaja, ohjelman julkaisija, operaattori, laitteen valmistaja, sovelluskaupan ylläpitäjä ja mahdollisesti puhelinta hallinnoiva IT-osasto. Sidosryhmillä on huomattavasti suurempi vaikutusvalta ja kontrolli mobiililaitteeseen kuin tavallisessa käyttöjärjestelmässä. Esimerkiksi operaattori ja laitteen valmistaja ovat saattaneet jo valmiiksi muokata käyttöjärjestelmää. Sidosryhmien tavoitteet eroavat ja tilaisuuden tullessa, jokin niistä saattaa toimia vastoin toisen tietoturvaperiaatteita. Jokin taho saattaa toimia oman tai vain käyttäjän edun mukaan, mutta asia tulkitaan silti uhkana muille.
Jokainen sidosryhmä haluaa suojata tietonsa, kun taas operaattori ja sovellukset haluavat pääsääntöisesti kerätä laitteesta tietoa. Sovelluskehittäjän pitäisi arvioida tietojen (tunnisteet, data-varasto, käyttäjätunnukset, käyttäjätiedot jne.) tyypin mukaan, kuinka niitä käsitellään, jotta muut sidosryhmät eivät niitä pystyisi väärinkäyttämään.
10. Mitkä hyökkäykset ja torjunnat Google Wallet -järjestelmää vastaan esitetään luvussa 9?
Risto Viitanen (2013-s)
Mobiililaitteen turvallisuudessa pitää ottaa huomioon mahdollisuus, että laite varastetaan. Tämän takia Google Walletin käyttö edellyttää pin-koodin syöttämistä. Koodissa on kuitenkin vain 4 numeroa, joten vaihtoehtoja on 10000. Jos mahdollinen hyökkääjä pääsee käsiksi puhelimeen root-oikeuksien kanssa, tämän murtuu nopeasti. Ratkaisuna tähän tarjotaan pin-koodin tarkistamista SE:n (Security Element) kautta. SE:n käyttö on todella rajattua ja näin Google Walletin käyttämän 6 arvauksen politiikan saisi pakotettua suoraan puhelimen raudalla. Kun käyttäjä on epäonnistunut syöttämään pin-koodin tietyn arvausmäärän verran, menee puhelimen SE lukkoon, eikä enää hyväksy uusia arvauksia. Toinen heikkous on ”Relay attack”, jossa maksutapahtuman yhteydessä hyökkääjä lähettää maksupäätteen kyselyt oman puhelimensa kautta uhrin puhelimelle. Näin maksun suorittaisi uhrin puhelin. Ratkaisuna tähän tarjotaan maksupäätteille timeout-logiikkaa, joka estäisi yhteyden kierrättämistä useamman laitteen kautta. Toinen ratkaisu tähän olisi käyttää puhelimen geolokaatio-ominaisuutta, joka estäisi tapahtuman, jos puhelin ja maksupääte ovat liian kaukana toisistaan.