Se riippuu vaatimuksistasi.

Riittävän monimutkaista ja hyvin suunniteltua järjestelmää voidaan käyttää tunnistamaan yksinkertaisimmat taka- tai trap-ovet eniten ohjelmointikielet. Jos kieli kuitenkin on Turingin täydellinen, mikä tahansa yksittäinen lauseke tai toiminto voidaan ilmaista loputtomalla tavalla, mikä tekee analyysistä yhtä suurta kuin pysäytysongelma.

Nopea esimerkki tästä on a ja b lisääminen yhteen, jolloin saadaan c.

  c = a + bc = (-a) - (-b) c = (a - 1) + (b + 1) c = ((a * 2) + (b * 2)) / 2  koodi > 

Kaikki nämä ovat yhtä suuria, ja on olemassa ääretön määrä muita tapoja suorittaa sama laskenta. Tämä tulee entistä monimutkaisemmaksi, kun on olemassa erilaisia ​​ohjeita, joita voidaan käyttää (melkein) saman asian tekemiseen.

Suurin osa nykyisistä suoritettavien tiedostojen staattiseen analyysiin keskittyvistä haavoittuvuuksien analyyseistä tunnistaa kääntäjän artefaktit, eli outoudet ja yksittäisten kääntäjien idiosynkrasiat, jotka mahdollistavat potentiaalisesti haavoittuvien koodijuppien allekirjoitukseen perustuvan sovituksen. Automaattiset työkalut sylkivät kuitenkin pois suuren määrän vääriä positiivisia tuloksia, joten ammattitaitoisen henkilön on silti tutkittava tuloksia.

Koska takaovi ei ole määritelty esine, ts. useita erilaisia ​​muotoja (esim. takaoven tili, käänteinen kuori, piilotetut tiedostot jne.), tällaisten ongelmien tunnistaminen on vieläkin vaikeampaa. Jos takaovi on jotain tahallisen puskurin väärinkäytön kaltaista, jotta puskurin ylivuotoa voidaan hyödyntää helposti, niin voi olla mahdollista havaita tällainen ongelma. Jos se on jotain monimutkaisempaa, kuten tietty salainen komento, jota käytetään poistamaan tiedostojen pääsyn hallinta, se on melkein mahdotonta.

Ei. Haitallisten takaovien automaattinen havaitseminen koodistasi on uusimman tason ulkopuolella.

Voit toki kirjoittaa koodinskannaustyökalun etsimään tiettyä tunnettua takaovea. Mutta ongelmana on, että hyökkääjä voi käyttää takaovea liian monella tapaa, eikä kaikkia tällaisia ​​malleja voida tunnistaa. Itse asiassa, jos ajattelet sitä hieman, huomaat nopeasti, että - yleensä - takaovien puuttumisen tarkistaminen on yhtä vaikeaa kuin koodin oikeellisuuden tarkistaminen, mikä on useimmat nykyisin rakentamamme ohjelmistojärjestelmät.

On vakavia syitä uskoa, että haitallisten takaovien automaattinen löytäminen on vaikeaa perustuen pysäytysongelman vähentämiseen. Käytännön esteet ovat kuitenkin vielä vakavampia. Tämän seurauksena tällä hetkellä ei ole hyvää, luotettavaa tapaa tarkistaa ohjelma automaattisesti ja selvittää, sisältääkö se haitallisen takaoven.

Siksi nykypäivän tavanomainen tapa on luottaa luottamukseesi ohjelman kirjoittaneisiin ihmisiin. Jos ohjelma tulee henkilöltä, jolle luotat, ei hyökkää sinua vastaan ​​(esim. Microsoft, Apple, olettaen että luotat heihin), voit suorittaa sen ja luottaa luottamukseesi ohjelman lähteeseen. Tämä lähestymistapa johtaa luottamiseen brändäykseen tai henkilöihin, joihin sinulla on suhde. Vaihtoehtoisesti, jos et luota ohjelman lähteeseen, sinun on joko ajettava se ja otettava riski tai suoritettava se hiekkalaatikossa, joka rajoittaa ohjelman mahdollisuuksia. Jälkimmäinen johtaa hiekkalaatikkorakenteisiin, kuten web-selaimet tarjoavat Javascriptin suorittamisen (koska yleensä ei ole mitään syytä luottaa Javascriptin lähettäneelle verkkosivustolle, ainoa turvallinen vaihtoehto on suorittaa Javascript hiekkalaatikossa, joka rajoittaa jyrkästi sitä tehdä niin, että haitallisille takaoville aiheutuvien vahinkojen määrä on rajallinen). Näillä lähestymistavoilla on omat rajoituksensa, mutta tekniikan tason mukaan ne ovat nykypäivän realistisin puolustus.

Mitä teoreettisesti voidaan tehdä, on antaa tietylle sovellukselle muodollinen määritelmä sen tarkalle toiminnalle ja sitten muodollinen todiste (tietokoneella todennettavissa) siitä, että sovellus todella täyttää määritelmän . Tätä ei voi lyödä olemassa olevalle ohjelmalle kaikilla yleisyyksillä (katso Pysäytysongelma: vaikka toiminnallisuus "lopulta pysähtyy", sitä ei voida todistaa totta tai vääräksi kaikki ohjelmat). Tämä voidaan kuitenkin tehdä ohjelmoijan tai hänen kääntäjän avulla.

Siitä on olemassa hyvin supistettuja versioita, esim. Java-virtuaalikoneen tavukoodi. Toiminnallisuus on, että "ei kirjoita puskurin ulkopuolelle, ei kutsu olemattomaa menetelmää objektille" (se on tietysti karkea yksinkertaistaminen). Kun JVM lataa koodin, se "osoittaa", että tätä toimintoa kunnioitetaan. Tämä toimii käsitteellisesti yksinkertaisen vuon analyysin kanssa ja se toimii, koska Java kääntäjä huolehti koodin tuottamisesta, jolle virtausanalyysi toimii (viimeisimmissä versioissa kääntäjä sisältää jopa vihjeitä, jotka JVM: n on vain tarkistettava pikemminkin kuin laskea uudelleen).

Ihannetapauksessa haluaisimme muodollisen erittelyn, joka sieppaa enemmän käyttäjätason semantiikkaa. Tämä johtaa kolmeen ongelmaan:

• Haitallisen ja ei-haitallisen koodin välillä on vaikea erottaa toisistaan. Onko tiedoston poistaminen haitallista toimintaa? Kyllä, paitsi jos sitä käyttäjä halusi. Käyttäjän mielikuvien kääntäminen viralliseksi määrittelyksi näyttää melko pelottavalta tehtävältä.

• Määrittelyn tulee noudattaa matemaattista rakennetta, joka voidaan tarkistaa automaattisesti. Pysähtymisongelma nousee lähistöllä.

• Ohjelmoijan pitäisi pystyä muuttamaan määritys tehokkaasti koodiksi, joka on todistettavissa ja joka toimii silti kohtuullisella nopeudella.

Jos pystymme tekemään kaikki kolme, voimme kirjoittaa sovelluksia, jotka eivät todellakaan ole haitallisia. Sivuvaikutuksena todistamme myös, että sovellukset ovat virheettömiä. Pelkästään tämä osoittaa, että se ei ole helppoa.

Jotkut ihmiset työskentelevät sen parissa. Älä kuitenkaan pidä hengitystäsi.

TL; DR: Kyllä, mutta se riippuu siitä, mitä tarkoitat tietokoneohjelma , lähde tai objektiversio , automatisoi , testaus ja takaovet .

Aloitan ehdottamalla tiettyjä määritelmiä joillekin yllä olevista termeistä, osittain siksi, että aiemmat vastaukset viittasivat eri merkityksiin, ja osittain keskustelun seuraamisen helpottamiseksi.

• Tietokoneohjelma : Jotta voimme pysyä täysin myyjä-agnostisina, oletetaan, että on olemassa sellainen tuote, jonka avulla voimme ohjelmoida säännöt ja että kohdekoodiin. Tämän pitäisi toimia tietyssä muodossa, katso alla, mutta oletetaan, että tällainen tuote on olemassa.
• Lähde- tai objektiversio : keskustelen lähdekoodianalyysistä täällä; teoriassa pitäisi olla mahdollista purkaa binääriobjektimuoto lähdekoodiksi ja jatkaa siitä. En kuitenkaan ole koskaan testannut tätä osaa, enkä tunne tuotteita, jotka tekisivät tämän puhtaasti. Lähdekoodi on siis vaatimus tälle vastaukselle.
• Automatisoitu : Vaikka olisin odottanut, että tällainen ohjelma skannaa ihmisille tuhansia ja miljoonia koodiriviä automaattisesti ilman manuaalista puuttumista, En vaadi tämän olevan 100-prosenttisesti automatisoitua suoraan laatikosta, enkä myöskään odota, että ohjelmalla olisi yleinen vastaus KAIKKIIN kohdeohjelmiin. Sallin pikemminkin manuaalisen määrityksen / säätämisen / komentosarjat, ennen kuin suoritan täydellisen tarkistuksen.
• Testaus : Tarkoituksena on löytää olemassa olevat takaovet - ei välttämättä 100%, eikä matemaattisesti todistaa, ettei muita ole, vaan löytää mahdollisimman monta sellaista, että se tarjoaa korkean tason luottamustaso. Aivan kuten XSS-skannerit yrittävät löytää useimmat tällaiset puutteet, mutta ilman matemaattista takuuta se on täydellinen. Lisäksi luottamustaso korreloi suoraan uhkamallin kanssa - pidä jokaista takaoven luokkaa uhkana, niin voimme etsiä niitä (toteutuksesta riippumatta). Jos et ole mallinnanut sitä - sitä ei löydy.
• Takaportti : OWASP: n määritelmästä: Ohjelmaan lisätty haitallinen koodi, jonka avulla kirjoittaja voi käyttää salaa pääsyä ... Ohjelma.
  En tarkoita, etten sisälly tähän mihinkään "takaoven ohjelmistoon", ts. troijalaisiin hevosiin tai muihin haittaohjelmiin, kuten BackOrifice; En sisällä järjestelmätason takaovia, kuten piilotettua käyttöjärjestelmän käyttäjää; EI sisälly mitään kehystason tai kääntäjäpohjaista, kuten Ken Thompsonin klassinen Unix-kääntäjän rootkit; enkä sisällä salauksen lukko-ovia, kuten Debianin virhe. Puhun vain kooditason takaovista (muuten koodien skannaaminen niille ei ole merkityksellistä).
  En myöskään tarkkaan sanoen OLE yleisiä tietoturva-aukkoja; hahmona @ D.W. laita se kommenttiin: takaovet (kehittäjän tarkoituksella käyttöön ottamat) vs. haavoittuvuudet (kehittäjien tahattomasti esittämät) . Tai vielä yksinkertaisempi: Luvaton toiminta .
  Selitykseni vuoksi en viittaa myös epäluotettaviin asiakassovelluksiin; on yksinkertaisempaa keskustella vain suurten yrityspalvelinjärjestelmien tapauksista, joissa uhka on, että yksi järjestelmän monista kehittäjistä lisäsi ei-toivotut toiminnot sallimaan itselleen "salaisen pääsyn". Tämä voidaan kuitenkin helposti siirtää myöhemmin myös asiakas- ja / tai kolmannen osapuolen sovelluksiin.

Ennen kuin jatkan, on tärkeää huomata, että tämän "takaoven" määritelmän mukaan takaovien testaus on melkein merkityksetöntä, ilman lisämääritelmää. (Se olisi samanlainen kuin sanoa "test for all bugs" - sinun on määriteltävä, minkä tyyppisiä vikoja odotat löytävän. Tai kuten PHB sanoi Dilbertille: minun on tiedettävä kaikki odottamattomat asiat, jotka voivat mennä pieleen . ) En nyt väitä pelkästään sitä, että meidän pitäisi kuvata nimenomaisesti takaovi, ja sitten voimme löytää sen; mutta tarkoitan, että on olemassa tietty määrä luukkuja takaovia, ja voimme etsiä minkä tahansa määritetyn takaoven luokan (jota tietysti on ääretön määrä mahdollisia toteutuksia).
Esimerkiksi täällä ovat muutamia takaovien luokkia, jotka on luokiteltu (väärin) toiminnallisuuden mukaan:

• Todennuksen ohitus (erityisen käyttäjän / "maagisen numeron" tai parametrin / piilotetun URL-osoitteen kautta)
• Valtuutus ohitus (erityisen käyttäjän / piilotetun parametrin kautta)
• Tietoihin pääsy backend-vuotojen kautta (eli tietojen lähettäminen suojatun tietokannan ulkopuolelle, esim. luottokortin numeroiden lähettäminen sähköpostitse).

Tietysti on muitakin, tosin ei loputtomia; jos (väärä) toiminnallisuus voidaan suunnitella, se voidaan analysoida, mutta aloitetaan nyt.

Kun olemme määrittäneet haluamasi toiminnallisuuden (toteutuksen kannalta epäolennaisen), kuvailemme, miltä mahdollinen ohjelma + sääntöjoukko näyttäisi kuten löytää tällainen (väärä) toiminnallisuus.

Tällainen skanneri ei tietenkään voinut toimia skannaamalla koodia tiettyjen kuvioiden ja allekirjoitusten varalta, koska tietyn toiminnon toteuttamiseen on ääretön määrä tapoja.

Jotta skanneri onnistuisi tässä, sen olisi suoritettava kokoamismuoto analysoimalla sekä tietovirta (tulojen, muuttujien, parametrien, lähtöjen jne. välillä) että ohjausvirta (esim. mikä vaikuttaa milloin haarautumaan, mitä muita toimintoja kutsutaan, miten silmukka jne.), ja myös niiden väliset korrelaatiot (esim. haarautuminen riippuen syötteeseen perustuvan laskelman tuloksesta).
Lisäksi on oltava mahdollista meidän on määritettävä räätälöity jokaiselle skannaamallemme kohdeohjelmalle, kuinka löytää tietyt sovelluksen globaalit, hyvin määritellyt elementit. Esimerkiksi mikä esine tai menetelmä edustaa todennustarkistuksia? Tämä voi olla yhtä yksinkertaista kuin kohteen / menetelmän nimi tai monimutkaisempi jopa heuristiikan suhteen; mutta toistaiseksi sanotaan, että voimme määrittää todennusmekanismin nimen. Sama asia siitä, miten sovellus käyttää tietokantaa (suunnitellulla, laillisella tavalla).

Jos nyt voimme skriptata oman sääntöjoukkomme, olisi mahdollista löytää mikä tahansa kulku, joka onnistuu välittämään todennusmekanismin, ilman kelvollista vertailua käyttäjän syötteestä tulevan käyttäjänimen ja tietokanta JA kelvollinen vertailu käyttäjän syötteestä tulevan salasanan ja tietokannan arvon välillä.
Toisin sanoen, etsimme on kulkua, joka vastaa näitä ehtoja: ((pass-authentication ) (&&! ((Input.username == tietokanta.username) && (input.password == database.password))) (hyvin säälittävässä pseudokoodissa ...) Arvot voidaan tietysti tarkistaa SQL: ssä , tai ensin vedetty tietokannasta ja tarkistettu sovelluskoodi ...
(Meidän on myös sopeuduttava salasanan salaukseen, joka voidaan ratkaista samalla tavalla kuin aiemmin, ja hei, kun olemme siinä, tarkistetaan, että salasanat ovat salattuja, muuten heittävät heikkouden ...)
Pohjimmiltaan juuri löysimme kaikki tapaukset, joissa on mahdollista "todentaa" lähettämättä kelvollista käyttäjänimeä ja salasanaa. Ongelma ratkaistu.

Vastaavalla tavalla voimme tehdä samoin valtuutuksen ohituksen: julistaa valtuutusmekanismin ja löytää sitten paikkoja, joissa käyttäjätunnus tai identiteetti kumoaa tämän tai ohittaa sen (mihin itse asiassa vaikuttaa myös käyttäjänimi. ..). Meidän on myös löydettävä paikkoja, joissa ei ole pääsyn tarkistusta, mutta arkaluonteiset / epäilyttävät toiminnot suoritetaan.
Taustatietojen varastaminen: määritä arkaluontoiset tiedot (esim. Salasanat, luottokortin numerot jne.); etsi mikä tahansa paikka, jonka data kulkee ulkoiseen kohteeseen (esim. sähköpostitse, verkkoon, tiedostoihin jne.) tietokannan lisäksi. Huomaa, että joudumme ehkä hienosäätämään tätä sovelluksen mukaan - ehkä on olemassa MQ-palvelin, joka kopioi kaiken keskusyksikköön ... Mutta voimme yksinkertaisesti sulkea pois myös nämä, samoin kuin sulkimme pois tietokannan. Huomaa myös, että näiden tulisi olla arkkitehdin tuntemassa .

Kun otetaan huomioon tällaisen skannausalustan olemassaolo ja pyrkimys komentosarjaamme, voimme ehdottomasti löytää kaikki luvattomat toiminnot (määritelmän ongelmalle).

JALKAISU:
Voit kuitenkin nyt esittää vastaväitteen: "No, varma, mutta määritit vain pienen osajoukon mahdollisista takaovista".
Oikeastaan, vaikka tämä saattaa olla totta tiukassa mielessä, se ei ole käytännöllinen tapa, ainakaan aiempien määritelmiemme mukaan.
Hyvin korkealla tasolla on hyvin rajoitettuja tapoja päästä ohjelmaan - ja vaikka en mainita ne kaikki, luettelo ei ole pitkä. Muista, että etsimme mitään piilotettua toimintoa, vain niitä, jotka tarjoavat pääsyn kooditasolla.
Jos jokin muu takaoven muoto katsotaan merkitykselliseksi, sovelluksen uhkamallin / riskiprofiilin mukaan kyseinen muoto voidaan samalla tavalla analysoida ja komentosarjoja varten.

Jos esimerkiksi haluamme nyt tarkistaa, ettei ohjelmoija ole upottanut koodia, joka sisältää salattujen ohjeiden lohkon, jonka avain on johdettu erilaisista järjestelmän parametreista, niin että todellinen takaovi on piilotettu - voisimme skriptaa helposti säännön, joka löytää minkä tahansa paikan, jonka koodi purkaa lohkon, purkaa sitten ja suorittaa sen dynaamisesti. Toki saattaa olla mahdollista, että tulee väärä positiivinen - ehkä jos on olemassa outoja, ainutlaatuisia toiminnallisia vaatimuksia tämän oikeastaan ​​tekemiseksi (todella?) - mutta niitä voidaan säätää ja skannata alkuperäisen koodin esisalauksen.

Joten lopputulos - Onko mahdollista skannata tietyn luokan takaoven lähdekoodia?
Kyllä. Ongelmallinen osa on määritellä asiaankuuluvat takaovien luokat.

Tarjoaako tämä tyypillisesti 100% takuun matemaattisten todisteiden avulla?
Ei. Jälleen kerran sama pätee mihin tahansa muuhun tyyppiseen haavoittuvuusskanneriin (esim. Lähdekoodin skannaus XSS: lle), mutta ponnistuksen määrästä riippuen voimme päästä asteittain ja ksenomorfisesti lähemmäksi 100%, niin että se on tarpeeksi hyvä / em>.

Jos tutkitaan blackbox-ohjelmistoa (ei avoimen lähdekoodin ohjelmistoa), käsitellään sitä vain blackbox-ohjelmana, eli tarjotaan joitain syötetietoja ja analysoidaan tuloksia, IMHO on intuitiivisesti ilmeinen, että on tuskin mahdollisuutta, että riittävän älykkäästi istutetut takaovet koskaan havaita. Esimerkiksi ohjelmisto voi sisältää "ajastetun pommin", toisin sanoen se tekee jotain erityistä, kun tietty pratasulaarinen aika tulee, mutta muuten käyttäytyy täysin normaalisti odotetusti. Useita vuosikymmeniä sitten sattui tietämään tällaisesta ajastetusta pommista: Yrityksen tietokone (keskusyksikkö) kaatui melkein joka toinen päivä yön aikana, ja järjestelmän asiantuntijana toimivan työntekijän täytyi tulla työskentelemään kovasti järjestelmän nostamiseksi uudelleen . Jonkin ajan kuluttua johto huomasi tämän kaverin merkityksen yritykselle ja ylisti hänet tietokonekeskuksen päälliköksi. Sen jälkeen tavallinen yön kaatuminen "salaperäisesti" katosi.

On kaupallisia analysaattoreita, jotka toimivat käännetyillä binaareilla, esim. Veracode ja Fortify.

Jos he eivät löydä mitään pysähtymisongelman takia, se ei tietenkään tarkoita sitä, ettei ole luukkuja.