Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Menetrendek WAP

2011.09.07. 15:16 | buherator | 5 komment

Mircbugger küldte az alábbi levelet a wap.menetrendek.hu (van aki még WAP-ol?) üzemeltetőjének. Egy elég egzotikus hibáról van szó, amely egy kis továbbgondolással feltehetően kódfuttatásra is alkalmas lehetett volna. A problémát azóta úgy tűnik, már javították:

Tisztelt WebMester!

A wap.menetrendek.hu-val kapcsolatban írnék, mégpedig arról, hogy szerintem a szerveroldali szkriptek valószínűleg sebezhetőek a forráskódban az uid mező átírásával a következőképpen:

Annyit kívülről is látni, hogy az "uid" egy fájlra mutat és ha az nem létezik, hibaüzenetet ír a szkript, melyből ez kiderül, ahogy látható [az alábbi] képen.

Mivel a fájlelérés nincs levédve a könyvtárak közötti visszalépéstől (../../) így egyfelől elképzelhető olyan fájlokhoz való hozzáférés, melyekhez kívülállónak nem szabadna hozzáférnie, másfelől felveti egy DoS támadás lehetőségét, amennyiben a fájlból olvasott érték vagy kódrészlet nincs megfelelően felülvizsgálva és méretre korlátozva. Példa:

<anchor title="Teleplista">OK<go href="wml.cgi" method="post">
<postfield name="action" value="match"/>
<postfield name="uid" value="../../../dev/urandom"/>
<postfield name="beirta" value="$(honnan_i)"/>
</go></anchor>

Itt ha a CGI szkriptben egy while(<FILEHANDLE>) ciklussal olvasunk, végtelen ciklus lesz belőle és megvalósul a DoS támadás, ráadásul a memóriát is kitelítheti a program, ha minden olvasott értéket tárolunk. Amennyiben ezutóbbi átírást alkalmazzuk, és a form-ot post-oljuk, a szerver [az alább] látható hibát produkálja és utána nem is áll helyre.

A megoldás: Minden mező beolvasásakor regexppel kell validálni az értékeket, például az uid-nél a regex: [0-9]{10}\.[0-9]{5} és csak akkor szabad tovább folytatni a műveletet, ha megfelelt. Így elképzelhetetlen, hogy a "../../"-t tartalmazó sztringek értelmezésre kerüljenek és az uid mező kéretlen fájlra mutasson.

Ezt a levelet azért írtam, hogy a hiba mielőbb kijavításra kerüljön, a szerverre nem törtem be, nem loptam el semmilyen információt.

Üdvözlettel

Egy informatikus kolléga

Néhány szolg. közlemény a hibajelentésekkel kapcsolatban:

Címkék: wap az olvasó ír menetrendek.hu

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.

_2501 2011.09.07. 16:32:12

ez command exec kezicsókolom

Csiszi91 (törölt) 2011.09.10. 14:30:57

szörnyű a helyzet miskolc és neptuna körül is :/

mircbugger 2011.09.15. 11:16:17

Köszi, hogy kitetted :) A nevem mircbugger (nem eszem hamburgert:). Kódfuttatást pedig így lehetett volna: Amennyiben az uid fájlok a Perlben használt open() függvénnyel vannak megnyitva, elég uid-nek beírni pl. ezt "../../../bin/bash <paraméterek> |" és tetszőleges parancs lefut a rendszeren.

_2501 2011.09.15. 14:59:29

@mircbugger: ehh. hülye szóvicc volt. olvasásra megnyitni lehet:

1: open FH, "filename";
2: open FH, "<filename";

Az 1. esetben működik amit mondasz bash -c "ls -la". A 2. esetben nem.