Apache incidens

Nemrég támadás érte a nyílt forrású webszervert fejlesztő Apache.org szervereit. – írta: sh4d0w, 14 éve

A részleteket ismerve – vagy legalábbis azokat a részleteket, amelyeket az ASF nyilvánosságra hozott – azt kell mondanom: egy igen jól tervezett, szervezett és kivitelezett támadássorozat vezetett az ASF bizonyos szervereinek kompromittálódásához.

Amit elöljáróban érdemes tudni: az áldozatul esett szerver 8.04-es Ubuntut és a JIRA nevű bug- és projekt-trackert futtatta (brutus.apache.org).

Első lépésben a támadók egy új bejegyzést küldtek be egy már korábban feltört szerverről, INFRA-2591 számmal, amiben egy rövidített URL szerepelt. (Magára kicsit valamit is adó számítógép-felhasználó ilyenre nem kattint.) A rövidített URL használatának célja egy XSS (cross-site scripting) támadás elrejtése volt, amellyel elfoghatták az adminisztrátorok session-cookie-jait. Mivel a problémajelentést az infrastruktúra-csapat számára nyitották, jónéhány admin rákattant a linkre, amivel a jogosultságaikat is elfogták.

Az XSS támadással egyidőben brute force támadás indult a JIRA login.jsp-je ellen, többszázezer jelszókombinációt kipróbálva, melyek közül az egyik sikeresnek bizonyult. A támadók így feltérképezhették a fájlrendszert, fájlokat másolhattak le, illetve elhelyeztek egy backdoort is. Ezután telepítettek egy programot, ami a hozzáféréseket logolta, majd minden infrastruktúra-adminnak levelet küldtek ki, hogy egy bug miatt változtassák meg a jelszavaikat. Az egyik ilyen elfogott jelszó megegyezett egy lokális felhasználó jelszavával, amelynek teljes sudo hozzáférése volt, így a támadók hozzáférést szereztek a brutushoz. Itt további cache-elt hozzáférésekhez jutottak, amelyekkel be tudtak lépni a minotaur.apache.org szerverre is, itt azonban nem tudtak további privilégiumszint-emelést végrehajtani.

Néhány óra elteltével az Apache-nál dolgozók elkezdték leállítani a szolgáltatásokat, majd átmozgatni azokat egy másik szerverre (thor.apache.org), miután a brutus megbízhatatlanná vált. Az ASF értesítette a támadásról a JIRA szállítóját, az Atlassiant, valamint a SliceHostot. Míg az Atlassian reagált a megkeresésre, a SliceHost semmit nem tett, így két nappal később ugyanarról a Slicehost szerverről közvetlenül kezdték el támadni az Atlassiant.

Időközben az Apache különböző szolgáltatásai ismét elérhetővé váltak.

Az első támadás egy SliceHost szerverről érkezett és egy rövidített URL-t tartalmazott. Íme a tanulság, miért kell kerülni a kattintást az ilyen linkeken – nem tudni, valójában mit rejtenek. Itt ráadásul egy XSS-attack is elbújt a link mögött, ami egy tinyurl-ből nem látszik. Nyilvánvaló, hogy ezt a gyakorlatot meg kell szüntetni és képezni kell a rendszerrel dolgozó adminisztrátorokat az ilyen hibák kivédésére. Ismertetni kell továbbá a Social Engineering aspektusait is.

Problémás a sudo access-ek kiosztása. A támadás során az egyik elfogott JIRA-jelszó megegyezett egy felhasználó teljes hozzáférésű sudo-jának jelszavával is, amely olyan biztonsági rés, amelyet szoftveres eszközökkel igen nehéz kivédeni, adminisztratív úton kell kierőszakolni a megfelelő videlkedést. Még jobb, ha nincs is szükség a sudo-ra, hanem olyan felhasználói csoportokat hoznak létre, amelyeknek megvan a szükséges hozzáférésük, de semmivel sem több. Meg kell fontolni a fail2ban alkalmazását is a login.jsp-vel szemben. Eléggé nonszensz az én szememben, hogy egy belépési ponton többszázezer felhasználónév/jelszó párost ki lehet próbálni szankciók nélkül – így tettek szert a támadók a full access-t biztosító sudo jelszóra.

Érdemes átgondolni a partnerséget a SliceHosttal. Nem azért, mert az egyik virtuális szerverükről érkezett a támadás, hanem mert a gondok jelzése ellenére egészen addig nem tett semmit, amíg a feltört szerverről nem támadták meg a JIRA szállítóját, az Atlassiant. Mindeközben az Atlassian a létező leghamarabb elkészítette az XSS-támadás kivédésére a javítást.

Elhiszem, hogy a kívülről érkező támadások egyszerűbb változataira fel vannak készítve az adminok, de úgy látszik, hogy ez nem elég (mindazok mellett, hogy itt jónéhány alapvető szabályt megsértettek) és összetettebb támadásokra is fel kell készíteni a rendszerek felhasználóit és adminisztrátorait, át kell látniuk, hogy egy lehetséges támadássorozat milyen lépésekből állhat.

Nem biztos, hogy mindenben igazam van a fentiekben, de azt hiszem, a fentiek adnak egy jó közelítést a felkészülésre a jövőbeni hasonló támadásokkal kapcsolatban.

Forrás: https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Fenti írások eredetije megtalálható itt, az ott található licenc vonatkozik rá.