A biztonságos kód az alkalmazás-tervezésénél kezdődik. Sokan csak a biztonsági audit eredménye láttán jönnek rá, hogy a szoftvert már a fejlesztés alatt ebből a szempontból is vizsgálni kellett volna. Nekik már nem segítenek a cikkben leírtak, de ha szoftverfejlesztés előtt állsz, akkor itt az ideje, hogy elgondolkodj az alkalmazásod biztonságán is!! 

A szakmai szakértők szerint a legtöbb szoftverspecialista azt gondolja, hogy a biztonsággal elég csak az alkalmazás fejlesztése után foglalkozni. Ugyan a fejlesztők és a tesztelők ismerik az alkalmazástesztelés és a biztonság fogalmát, legtöbbjük olyan cégnek dolgozik, amely nem rendelkezik átfogó alkalmazásbiztonsági stratégiával. A biztonság kiemelt kezelésének vezetői felhatalmazása nélkül a fejlesztők és a tesztelők az üzleti nyomás áldozatául esnek, amelyben a cél az alkalmazások mielőbbi lefejlesztése.

„Csak készüljünk el, utána  majd megoldjuk a biztonsági bizonytalanságokat is! – ez az általános nézet,“ – mondja Brian Bertacini, az AppSec Consulting elnöke és alapítója, aki alkalmazásbiztonsági tanácsadóként dolgozik a kaliforniai San Joséban. „Ritkán lehet olyan szoftverekkel találkozni, amelyekben a biztonság az összes szükséges területen jelen van“ – teszi hozzá Kevin Beaver, a Georgia állambeli Acworthben működő független információbiztonsági tanácsadó, a Principle Logic LLC tulajdonosa. „A szoftverfejlesztőknek és a minőségbiztosítási szakembereknek nincs arra idejük illetve erőforrásuk, hogy az alkalmazások biztonságával foglalkozzanak. Valahogy megoldják; megteszik a legtöbbet, ami tőlük telik, majd a végén javítják.“

A SearchSoftwareQuality.com alkalmazásbiztonsági szakértőket kért fel, hogy nevezzék meg az alkalmazási életciklus minden egyes szakaszának a biztonsági problémáit, valamint hogy ajánljanak eszközöket és módszereket a biztonság növelésére. Íme az általuk nyújtott tanácsok összefoglalása:

1. Az alkalmazás fejlesztésekor a kezdetektől vezess fenyegetettség-modellezést!

A fenyegetettség-modellezés egy olyan folyamat, amelynek segítségével feltérképezhető, hogy a támadó hányféleképpen okozhat kárt az alkalmazásban még annak kifejlesztése előtt – mondja Wendy Nather, egy New York-i kutatócég, a 451 Research LLC vállalkozások biztonságával foglalkozó vállalat igazgatója. „Fel tudod törni? Képes vagy módosítani? Ellopható bármelyik része? Ezeket a kérdéseket kell megválaszolnod – tanácsolja Nather. A legjobb fenyegetettség-modellek grafikusan ábrázolják, hogy miként áramlanak az adatok, s hogyan történik a tárolásuk – hangoztatja Dan Cornell, a San Antonio-i biztonsági tanácsadó cég, a Denim Group Ltd. egyik vezetője. Hozzáteszi, hogy „a cél: előre meghatározni, melyik biztonsági elemeknél jelentkezhet probléma.“ Ezeket a tényezőket feltétlenül ismerni kell a fejlesztés kezdetekor, mert olcsóbb olyankor foglalkozni a biztonsági problémákkal, amikor az alkalmazás még csak „egy vázlat a táblán“.

2. Határozd meg az alapvető követelményeket, amelyek a biztonságra irányulnak!

Ma a fejlesztők – még azok is, akiknek nincs biztonsági képzettségük – tisztességes munkát végeznek, amikor az alkalmazásbiztonság alapvető szempontjaival foglalkoznak: szerepkörök szervezése, hitelesítés, jelszó alapú hozzáférés szabályozása. Azonban vannak olyan követelmények, amikre ezek mellett is hangsúlyt kell helyezni – hívja fel a figyelmet Beaver, majd folytatja: a felhasználói szerepek kezelése – ki, mit láthat, s mit tehet az adott információval – különösképpen bonyolult a felhő- és a sok szereplős alkalmazásoknál. „Megfelelően kell felépítened őket!“ Egy jó biztonsági gyakorlat – ahogy Bertacini nevezi –, „a lehető legkevesebb jogosultság óvatos adagolásának filozófiája“.

Amikor meghatározzuk, hogy ki,  milyen információt láthat, illetve azzal mit tehet, csak akkor adjunk jogosultságot, ha feltétlenül szükséges! „A kiindulási pont az, hogy nincs jogosultság“- tanácsolja Beaver. „Még az olyan alapvető biztonsági tényező, mint a jelszóhozzáférés is bajt okozhat, ha nem tervezed meg megfelelően a kezdetekkor.“ Beaver látott már olyan alkalmazásokat, amelyek azonosítás nélkül is beengedtek a védett alkalmazásba, s olyanokat is, amelyek nem engedték meg a speciális karakterek használatát a jelszóban. „Tényleg? Manapság? Nyilván viccel.“ Ezek azok a helyzetek, amelyekhez később nehéz visszanyúlni és javítani – teszi hozzá.

3. Állj elő visszaélési esetekkel!

A visszaélési esetek vagy lehetséges támadások forgatókönyve a követelmény szakasz egyik legfontosabb pillére, ennek ellenére manapság sok cég figyelmen kívül hagyja ezt a lépcsőt. Cornell azt mondja: „a csapatok hozzá vannak szokva, hogy egy sor olyan funkcióval jöjjenek elő, amit egAmikor meghalljuk azt, hogy penetrációs teszt, az ember rögtön a kívülről érkező hálózati támadásokra gondol, ahol a szakember megpróbál távolról betörni a rendszerbe. A piac természetesen ehhez is alkalmazkodott a tűzfalak, céleszközök és biztonsági programok szempontjából. A mobil eszközök terjedésével – amelyek akár közvetlen Wi-Fi kapcsolattal rendelkezhetnek – azonban a belső problémákkal is fel kell venni a harcot. A mobilokat egyre erősebb processzorokkal vértezik fel, képesek WI-FI kapcsolatra, kamerájuk, háttértárolójuk és még állandó internet elérésük is van 3G/4G segítségével, amely ezáltal számos alkalmazást tesz elérhetővé. A „root-olt” eszközök pedig sok esetben rendelkeznek olyan tudással, mint egy PC. Ha ezeket kombináljuk a megfelelő programmal, számos szkent lehet elvégezni percek alatt, amihez rengeteg új, az információ megszerzését célzó támadási lehetőség is párosul.

Ezek a mobil erőforrások a kényelem teljességével képesek igen erős penetrációs alkalmazások futtatására is. Méretükből adódóan viszont jobban fedettek, könnyebben elrejthetők, mint egy felnyitott laptop. A nagyvállalati IT Magyarországon is sokat költ hálózatainak biztonságára. Sok esetben azonban kimarad a végpontok biztonsága, ami alapvető hiányosság. A belső biztonsági szabályzatok – habár előírásban nem is annyira, – végrehajtásban azonban jóval lazábbak, mint a külső szabályzatok.

Egy hálózat támadása jelenleg sokkal egyszerűbb, mint pár évvel ezelőtt, mivel az eszközök és az operációs rendszerek sokkal változatosabbak, mint abban az időben, amikor letettük a voksunkat egy elsődleges és állandó WIN/LINUX rendszer mellett, ami Ethernet-kábelen csatlakozott. Napjainkban az irodák Wi-Fi-t használnak számos különböző típusú eszközzel rajtuk (laptop, tablet, telefon, stb.), amelyek nem feltétlenül vannak a vállalkozás tulajdonában (BYOD). Szóval, a „behatolónak” igen gazdag környezet kínálkozik számos támadási vektorral.

A dolgozói eszközök használatára vonatkozó belső szabályozás általánosságban elég gyér, nincs végrehajtva vagy nem is létezik. Ráadásul az alkalmazottak nem részesülnek megfelelő biztonsági oktatásokban a mobil eszközök tekintetében. Ezen a tesztelés után célzottan lehet javítani. 

Miért kell felügyelni az USB portokat?

A mobil eszközök flash meghajtóként való használata igen hatékony eszközzé teszi őket penetráció során. Gondoljunk csak a Stuxnet esetére, vagy a nem is olyan régen kirobbant katonai drónok távoli vezérlésére. Mind a két esetben USB-n keresztül jutottak be a kártékony programok a rendszerbe. Lássuk, mit tehetünk a teszt során, milyen információkat és hogyan nyerhetünk ki. Számos program áll a rendelkezésünkre, amivel csatlakozás után elérhetjük a célunkat. Az USB Hacksaw és Switchblade számtalan lehetőséget kínál erre. 

Miután megkértük a vállalati alkalmazottat, engedje meg nekünk, hogy kicsit töltsük a telefonunkat az USB-n keresztül, a program csendben kinyeri az olyan adatokat a Windows rendszerekből, mint a jelszó hash-ek, az LSA és IP információk, a webes előzmények, az űrlapmezők, valamint képes backdoor-t nyitni számunkra, ha később vissza szeretnénk kukucskálni a célrendszerbe; mindezt elképesztő sebességgel.

A másik igen hatékony alkalmazás az USBDumper, amely szintén a háttérben dolgozik. Mi csak töltjük a telefont, még bájcsevegni sem kell közben a figyelemelterelés miatt. Mindeközben a program másolja az adatokat a csatlakoztatott háttértárolókról. Igen elterjedt megoldás konferenciákon, egyetemeken.

Ezen felül lehetőségünk van USB-n keresztül trójaiak rendszerbe juttatására is. Amennyiben a vállalatnak csak szignatúra alapú vírusirtója, van és nem viselkedés alapú, akkor elegendő, ha egy jól bevált trójai forráskódját megszerezzük és részben módosítjuk, ezzel kicselezve a vírusirtók java részét. Hijack-elésnél ne feledjük az SSL csatornát, főként a tűzfal megkerülése és a rejtettség végett!

Javaslat: Az USB portokat és egyéb interfészeket le kell tiltani, és csak a vállalat által hitelesíttetett, dedikált eszközöket szabad engedélyezni az alkalmazottak számára, megfelelő naplózás mellett. Az új generációs tűzfalak és biztonsági programok pedig lehetőséget biztosítanak az SSL csatornák monitorozására is.

A „behatolás”

Vezeték nélküli hálózatok támadásánál számos úton be lehet jutni, vagy legalábbis közelebb kerülni a célponthoz. Például social enginering-rel: interjúkon, közösségi oldalakon, (LinkedIn, Facebook) sőt a Google-ön, esetleg üzleti megbeszéléseken keresztül, de alkalmat adhat rá egy házhozszállítás, takarítás, nyílt nap, vagy egy rendezvény is.

A vezeték nélküli hálózatok hatósugarát nehéz szabályozni, így már akár az épületbe való bejutás nélkül is elérhetjük a célrendszert, akár egy autóból, étteremből vagy kávézóból. A művelethez nagyjából bármely nagyobb teljesítményű „root-olt” Androidos eszköz megfelel. A mobil alkalmazás, amire első körben szükségünk lehet az a Network Discovery, amely elérhető a Google Play-ből, de használhatunk egyéb más map-elő szoftvereket is. Az említett program ingyenes, és nem igényel root-olást sem. Felülete átlátható és könnyen kezelhető. Sok igen hasznos program elérhető már iOS-en is. A Wi-Fi-hálózathoz való csatlakozás után – jelszó szükséges – az alkalmazás felismeri a csatlakozott eszközök gyártóját, típusát és operáció rendszerét. Így már jó rálátást kapunk a kiszemelt célra.

A hálózati felderítés, map-elés csak egy lehetőség, ami a nyílt Wi-Fi hálózatok szkennelésére alkalmas. Ha azonban sérülékenységet és más tulajdonságokat szeretnénk vizsgálni, több programra lehet szükségünk. Egy izraeli biztonsági cég, a Zimperium megalkotta azt a kompakt arzenált, amelyet ANTI – nak (Andoid Network Toolkit) kereszteltek el. Gyakorlatilag nem kell Linux Lászlóvá válnunk, megtanulnunk a TCP/IP alapokat, még csak nmap zenmasternek sem kell lennünk, ha be akarunk törni a hálózatba. Az integrált eszköztár igen széles, ráadásul könnyen értelmezhető egy laikus számára is.

Miután elindítjuk a programot, – telepítéshez root-olás szükséges – el is kezdhetjük a szkent a hálózaton, mint a Network Discovery-nél. Az ANTI meghatározza a csatlakoztatott eszközöket, és itt már a sérülékenységekről is ad képet. Ezeken exploit-okat tudunk elhelyezni Metasploit-ból és ExploitDB-ből, amikkel célzott támadásokat tudunk indítani.

Lehetőségünk van képernyőképeket lopni, MITM támadásokat beékelni, brute force attack-es jelszótörést indítani számos integrált könyvtár segítségével.

A „Cracker” funkció feltárja az eszközök nyitott portjait a hálózaton belül, ami eltarthat egy ideig, a számuktól és a támadásban használt könyvtáraktól függően. A Wi-Fi monitor méri az elérhető hálózatok jelerősségét és a MAC címet is leolvashatjuk vele. „Intrúzív” szkenneléssel pedig megtudhatjuk a potenciális sebezhetőségeket. A támadásokat a hálózaton kívüli HTTP szerverről is el tudjuk végezni egy hasznos modul segítségével. 

Javaslat: A kliens oldali tűzfal- és patch-menedzsment segítségével leredukálhatjuk ezeket a sérülékeny pontokat.

Session Hi-Jacking, ARP Spoofing és Wi-FI-s cselek

Sokan ismerhetik a Firesheep nevű programot, amely a Firefox böngészőből nyer ki session-öket. Ennek megvan az Androidos megfelelője, a Droidsheep. Azonban ehhez az alkalmazáshoz is szükséges a root-jog. Sok esetben belassíthatja a hálózatot, így azonosíthatóvá válik, azonban ha kikapcsoljuk az ARP Spoofing-ot azonosíthatatlan lesz. Ebben az esetben a titkosított hálózatokat nem mindig tudjuk „elterelni”. Generikus módban minden lehetséges session-t látunk.

Egy másik igen robusztus megoldás a Network Spoofer (már nem elérhető a store-ból), amely ARP Spofing-ra ad lehetőséget, vagyis módosított webes forgalmat küldhetünk a hálózatra, esetleg egy gépre. Mint említettem igen robosztus több tulajdonsága miatt is, az egyik ilyen a mérete: körülbelül 600MB, mivel alapvetően egy Debian disztribúció Squid proxyval. Számos egyéb támadásra is kiváló az alkalmazás, bár a WPA/WPA2-es hálózatot lelassítja vagy akár meg is béníthatja. A Network Spoofer képes átirányítani a teljes forgalmat a telefonra, így a Shark for root nevű alkalmazással el is tudjuk kapni a csomagokat, és menteni az SD kártyára pcap formátumban. A Shark reader alkalmazás segítségével el tudjuk olvasni, ha pedig FTP-re, laptopra akarjuk felmásolni, a Wireshark lesz a mi barátunk a művelet során. A csomagok megszerzésének van egy igen kézenfekvő módja is. Egyszerűen csinálunk a vállalat nevére emlékeztető hot-spotot, például: vállalat_guest, így a csatlakozott eszközökről közvetlenül nyerünk információt.

Hogyan hack-eljünk távolról?

Az okostelefonok nem csak a programok futtatására alkalmasak, de méretükből adódóan könnyen rejthetőek, így otthonról is be tudunk lesni a hálózatba a megfelelő előkészületek után. Első lépésben el kell helyezni a mobilt valahol az épületben egy töltőre csatlakoztatva. Ez nem egy nagy kihívás, de annál több lehetőséget ad a távoli hálózat, otthonunk kényelméből való vizsgálgatására, tesztelésére. Az eléréshez szükségünk lesz a Remote Web Desktop alkalmazásra, amely a store-ból szintén elérhető. Lényegében ezzel minden alkalmazást el tudunk érni a telefonunkról, így például a log fájlokat is ki tudjuk küldeni egy FTP szerverre.

Szkriptelés

Számos terminálemulátor elérhető Androidra, mint például a ConnectBot, amely sokrétű session-ökre és titkosított csatornákra ad lehetőséget. Az SL4A (Scripting Layer for Android pedig megkönnyíti a szkriptek végrehajtását az eszközön. Telepíthetünk Python-t, amely számos szkript futtatás mellett még a kompromittáló alkalmazásokat is képes letörölni. Természetesen használhatunk SL4A motor alatt Ruby-t, Perl-t, JavaScriptet és Beanshell-t is többek között.y alkalmazásnak tudnia kellene, azonban a biztonság szempontjából kulcskérdés lenne meghatározni, hogy egy szoftvernek mit nem szabadna művelnie.“ Egy visszaélési eset-lista elkészítéséhez azt tanácsolja a cégeknek, hogy gondolkozzanak el azon, egy támadó hogyan tudna kárt tenni a működésben. Például az Amazon.com felhasználói csak a saját rendelésüket törölhessék, más felhasználók által leadottakat ne!  Nather egy másik példát is említ: „Egy ügyfél láthassa saját bankszámlaegyenlegét a felhasználói fiókjában, de más ügyfelekét ne!“ „A te feladatod biztosítani, hogy egyik ilyen visszaélési forgatókönyv se valósulhasson meg!“ – mondja Cornell. „Ezek azok a szempontok, amikre csak manuális teszteléskor akadhatsz rá – ha vársz, mondván majd később kijavítod őket, akkor az általában már egy támadás miatt lesz.“

4. Állíts fel szabályokat a bemeneti adatok ellenőrzésére!

Nather úgy tekinti ezt a folyamatot, mint az alkalmazásod bizalmi zónáinak felállítását. „Amit tudni akarsz az az, hogy a rendszer melyik részei bíznak egymásban, illetve hogy bízniuk kell-e egymásban?“ Amint ezt kitaláltad, a következőképpen határozd meg a szabályokat:

• Ne bízz meg olyan adatban, ami az internetről jön be!
• Ha információt küldesz a rendszer alsóbb szintjeibe – pl. webszerverről adatbázisba, – akkor vizsgáld meg az adatot mielőtt fogadod!
• Ellenőrizd az összes, mindkét irányba mozgó információt, ami kimegy vagy beérkezik az alkalmazásba.

5. Használj forráskód-ellenőrzőket!

A forráskód-ellenőrzők még fejlesztés alatt megvizsgálják az alkalmazást, s sebezhetőséget keresnek: pl. egy támadó hol tudna adatot lopni? A céljuk, hogy egy olyan alkalmazás megírásában segítsék a fejlesztőket, amelyek már a kezdetekkor biztonságosabbak, ráadásul az alkalmazás adott életciklusában megjelenő későbbi biztonsági problémákat is felvetik. Korábban ezek az elérhető fizetős és nyílt forráskódú eszközök rossz hírnevet kaptak, mert hajlamosak voltak hamis eredményeket állítani. Találkozhattunk olyan forráskód-ellenőrzőkkel, amelyek hibásnak jeleztek olyan körülményeket is, amik valójában biztonságosak voltak – mondja Bertacini. „Például egy forráskód-ellenőrző jelezheti azt a kódot, amely az input-output szűrést valósítja meg. Amikor ilyen történik, a fejlesztők lesújtva érzik magukat, s azt gondolhatják, csak az idejüket vesztegették.“ De ma már jobb eredményekkel dolgoznak ezek az eszközök. „Különösen hasznosak, ha épp csak belekóstoltál a biztonságfejlesztésbe.“ – mondja Nather. „Meg kell vizsgálnod a forráskód-ellenőrzők által talált problémákat, azok típusait, és természetesen számos esetben testreszabott tesztelést is kell végezni.“ Cornell hihetetlenül hatásos eszközöknek tartja a forráskód ellenőrzőket. „De sokkal hatékonyabbak, ha lecsökkented a bő szabálykészletet, hogy ezzel ugyan kevésbé átfogó, ugyanakkor sokkal kezelhetőbb eredményeket nyújthass!“

6. A fejlesztőket vedd rá, hogy írjanak biztonságos kódot!

Egy másik mód az alkalmazás biztonságának fokozására a kódolási szakaszban, a már létező, általános feladatokat végző könyvtárak biztosítása“ – mondja Cornell. Lényegében kódmintákat írsz, amelyek azt modellezik, hogy „így kell adatbázis elérhetőséget kezelni; így kell weboldalt készíteni XSS hibák nélkül.“ – mondja Cornell, utalva egy jól ismert sebezhetőségre amit a támadók adatlopásra használnak. „A fejlesztők nagy szabadsággal dolgoznak egy alkalmazás megírásakor, s kódoló könyvtárak biztosításával ellenőrzés alatt tudhatjuk munkájukat.“ Ráadásul ilyenek létrehozásával enyhíteni lehet a biztonsági szakemberek és a szoftverfejlesztők között előforduló feszült viszonyon. „A biztonságiak mondhatják, hogy ‚Használd ezeket a könyvtárakat, s békén hagyunk!‘“

7. Használj dinamikus szkennereket, hogy támadásokat szimulálj a QA ciklus alatt!

A dinamikus szkennerek, egy black-box tesztelő eszközhöz hasonlóan „támadnak“ meg egy alkalmazást pontosan úgy, ahogy egy hacker teszi, s ezáltal képesek kimutatni a sebezhető kódot. Fizetős és nyílt forráskódú eszközöket is találunk a piacon, amelyeket arra terveztek, hogy azonosítsák az SQL injekcióval szemben sebezhető pontokat, valamint más ismert biztonsági réseket – fejti ki Cornell. Az SQL injekció akkor keletkezhet, amikor egy támadó egy beviteli mezőbe SQL-utasítások részeit emeli be, például arra utasítva az adatbázist, hogy közvetítse annak tartalmát a támadó számára. Cornell szerint a dinamikus szkennereket használó QA szakemberek feladata nem az, hogy ezernyi bejegyzést húzzanak ki az adatbázisból, hanem hogy kimutassák a sebezhetőségét.

8. Telepítési környezetben teszteld az alkalmazást!

A tesztkörnyezetnek – amennyire csak lehet – egyeznie kell azzal a környezettel, amire az éles alkalmazást telepítik – tanácsolja Nather. Ebben az esetben a legfontosabb, hogy az adatforrásokhoz biztonságos legyen a hozzáférés.

9. Az általános rugalmasság tesztelése.

Könnyen helyreáll-e az alkalmazás, ha a kapcsolat megszakad? Vagy amikor a felhő egy része beborul? Vagy amikor egy batch nem sikerül? Ezek azok az esetek, amiket mindenképpen meg kell vizsgálni – mondja Nather. „Biztosan lesznek problémák, úgyhogy készülj fel rá, hogy a rendszer helyreállítható legyen!“

10. Rendszeresen teszteld az alkalmazásokat készítésük közben!

„Még akkor is folytasd a tesztelést, ha az alkalmazás zöld jelzést kapott a biztonsági szakértőktől“ – tanácsolja Nather. Folyton új biztonsági sebezhetőségek bukkannak fel. „Ráadásul egy alkalmazás komponenseinek telepítésénél potenciálisan új sebezhető kódok keletkezhetnek a rendszerben“ – teszi hozzá. A biztonsági szakembereknek szorosan a fejlesztéssel együtt kell dolgozniuk! Még abban az esetben is, ha egy SQL injekciós sebezhetőség az alkalmazással gyártásba kerül, valamilyen kontroll segítségével – mint például adatbázishoz való biztonságos hozzáférés – megakadályozhatja a támadót a kártevésben.

Forrás:https://searchsoftwarequality.techtarget.com/tip/Ten-steps-to-better-app-testing-strategies
Szerző: Jennifer Lent