HTTP Request Smuggling - új támadási formák
A web alkalmazások sebezhetőségének új családja került nyilvánosságra a napokban. Ezúttal azonban nem a felhasználók által is látható alkalmazások sebezhetőségeiről van szó, hanem a kéréseket feldolgozó kiszolgáló programok: webszerverek, gyorsítótárak, tűzfalak sebezhetőségeire derült fény. A problémát az okozza, hogy a HTTP feldolgozás liberálisan került implementálásra a legtöbb termékben, hogy a hibásan érkező kéréseket is feldolgozhassák. Csakhogy a hibák feloldása különbözőképpen történik eltérő termékekben, és ez nagyon komoly sebezhetőségeket eredményezett.
A Watchfire nevű kockázatkezelő cég jelentette meg azt a részletes leírást (PDF), mely az általuk HTTP Request Smuggling névre keresztelt technika problémáit tárgyalja. A trükkök nagyrésze arra a hibára vezethető vissza, hogy a különböző HTTP implementációk másképp kezelik a
Nézzük a szerzők egyik példáját, ami bemutatja, hogy miként lehet egy a szerver előtt található gyorsítárban más tartalomra cserélni az oldal címéhez tárolt adatokat. A példában minden sor [CRLF] azaz kocsivissza-soremelés karakterrel végződik, kivéve az a sor, ahol ez külön jelzett:Tegyük fel, hogy a gyorsítótár szerver a második tartalom hossz sort veszi figyelembe, míg a webszerver az elsőt (a SunONE Web Server 6.1 SP1 és a SunONE Proxy 3.6 SP4 ilyen kombináció). A proxy tehát 44 bájtos kérés törzset vár, ez pedig a bla utáni szóközzel végződik. Az ezt követő karaktersorozat már egy második kérésként kerül feldolgozásra. A webkiszolgáló viszont a nulla hosszra vonatkozó adatot látja, és így számára rögtön kezdődik a második lekérdezés. Annak viszont a bla fejléce tartalmazza a rákövetkező GET sort (hiszen ott nincs sortörés), és így a harmadik HTTP kérést már nem látja, annak fejléceit a második kérés részének érzékeli.
Amikor a válasz előállítása történik, a webszerver tehát a
Ennél az egyszerű példánál sokkal izgalmasabb és komolyabb sérülékenységeket is feltártak a Watchfire szakértői, érdemes átböngészni az egész leírást. Nem csak a
Jó kérdés, hogy miként védekezhetünk az ilyen támadások ellen, ugyanis nem egy adott szoftver hibáinak, hanem bizonyos kombinációnak a kihasználásáról van szó. Mint a fenti példa is mutatja, még azonos szállítótól származó termékek használata esetén is felbukkanhat a probléma. Használjunk aktuális szoftvereket, és ha lehet, akkor a hibás kéréseket visszautasító szervert alkalmazzunk (az Apache ilyen, bár bizonyos körülmények között az is sebezhetővé válik)!
Eric Meyer a technikai liberalizmus (hibás adatokból való felépülés) és a technikai konzervativizmus (hibás adatok teljes elutasítása) kérdését feszegeti ennek a problémának a kapcsán blogjában. Arra a sajnálatos következtetésre jut, hogy éppen a liberalizmus vitte a webet abba a káoszba, amiben ma van, különösen a böngésző oldali technológiák mostoha és inkonzisztens kezelése, és a belátható jövőben nem várható a konzervativizmus felülkerekedése. Gondoljunk csak az RSS feldolgozók hibatűrésére, és hogy mégiscsak jobb RSS kezelőnek tekintjük azt, amelyik jobban értelmezi a hibás RSS-eket. Ilyen körülmények között azonban nem kerülhetjük el a jövőben sem a HTTP Request Smugglinghoz hasonló sérülékenységek felbukkanását.
■ A Watchfire nevű kockázatkezelő cég jelentette meg azt a részletes leírást (PDF), mely az általuk HTTP Request Smuggling névre keresztelt technika problémáit tárgyalja. A trükkök nagyrésze arra a hibára vezethető vissza, hogy a különböző HTTP implementációk másképp kezelik a
Content-Length fejlécek tartalmát, azaz másképp oldják fel azt a helyzetet, amikor kettő ilyen fejlécet adunk meg. Így elérhető az, hogy a kérés feldolgozási folyamat során különböző programok más kérésnek lássák ugyanazt a karaktersorozatot, és így például egy tűzfalon is át tudjuk juttatni rosszindulatú lekérdezéseinket a mögötte található webszervernek.Nézzük a szerzők egyik példáját, ami bemutatja, hogy miként lehet egy a szerver előtt található gyorsítárban más tartalomra cserélni az oldal címéhez tárolt adatokat. A példában minden sor [CRLF] azaz kocsivissza-soremelés karakterrel végződik, kivéve az a sor, ahol ez külön jelzett:
POST http://WEBHELY/weblap.html HTTP/1.1
Host: WEBHELY
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 44
[CRLF]
GET http://WEBHELY/helyettesito_oldal.html HTTP/1.1
Host: WEBHELY
Bla: [szóköz, de nem CRLF!]
GET http://WEBHELY/helyettesitendo_oldal.html HTTP/1.1
Host: WEBHELY
Connection: Keep-Alive
[CRLF]
Amikor a válasz előállítása történik, a webszerver tehát a
weblap.html és a helyettesito_oldal.html fájloknak megfelelő tartalmat továbbítja. A gyorsítótár kiszolgáló ugyanakkor úgy tudja, hogy a weblap.html és a helyettesitendo_oldal.html lapokra érkeztek kérések, így ezeknek megfelelően teszi tárolójába az adatokat. Nos, ezzel megvalósult a helyettesítés.Ennél az egyszerű példánál sokkal izgalmasabb és komolyabb sérülékenységeket is feltártak a Watchfire szakértői, érdemes átböngészni az egész leírást. Nem csak a
Content-length feldolgozásának hibáival kapcsolatos gondokra hívják fel a figyelmet, hanem egyéb kiszolgáló szoftver specifikus sérülékenységeket is említenek, amelyek úgyszintén kihasználhatóak.Jó kérdés, hogy miként védekezhetünk az ilyen támadások ellen, ugyanis nem egy adott szoftver hibáinak, hanem bizonyos kombinációnak a kihasználásáról van szó. Mint a fenti példa is mutatja, még azonos szállítótól származó termékek használata esetén is felbukkanhat a probléma. Használjunk aktuális szoftvereket, és ha lehet, akkor a hibás kéréseket visszautasító szervert alkalmazzunk (az Apache ilyen, bár bizonyos körülmények között az is sebezhetővé válik)!
Eric Meyer a technikai liberalizmus (hibás adatokból való felépülés) és a technikai konzervativizmus (hibás adatok teljes elutasítása) kérdését feszegeti ennek a problémának a kapcsán blogjában. Arra a sajnálatos következtetésre jut, hogy éppen a liberalizmus vitte a webet abba a káoszba, amiben ma van, különösen a böngésző oldali technológiák mostoha és inkonzisztens kezelése, és a belátható jövőben nem várható a konzervativizmus felülkerekedése. Gondoljunk csak az RSS feldolgozók hibatűrésére, és hogy mégiscsak jobb RSS kezelőnek tekintjük azt, amelyik jobban értelmezi a hibás RSS-eket. Ilyen körülmények között azonban nem kerülhetjük el a jövőben sem a HTTP Request Smugglinghoz hasonló sérülékenységek felbukkanását.
