És mi a helyzet a php hackelésével?
Bármit mondok a PHP pluszairól, legalább egy komoly hibája van: a php szkriptek hackelésének témája valahogy rosszul világít a futóműben. Mindenki csak azt mondja, hogy ez egy nagyon szivárgó dolog, ami tompa érveket tartalmaz, például "ha a változókat nem ellenőrizzük, a webszerver a gyökér alatt van, igen, hogy a verzió szivárog. "Eközben a php már túl sok helyet kapott, és sokan nem az eredeti szkripteket használják, hanem olyan szabványos megoldásokat, amelyek gyakran átsiklanak a sebezhetőségeken. Róluk, akkor valójában megvitatják.
Ez egyike a legelterjedtebb webhelymodelleknek, amelyeknek sok lehetősége van: a cikkek és a hírek kiküldésével, az olvasók (pl. A xakep.ru) beszélgetés lehetőségével, mielőtt a bannerek megjelenítését automatizálná. A termék erejét meg lehet ítélni a bemenet mennyisége alapján: az archívum a motor legújabb verziójával súlya ... súlya ... 1.21mb! De vannak szkriptek, szöveges fájlok ...
Azonban, ahol sok kód van, sok hiba létezik. A php-nuke megjelenése óta olyan sok lyuk található, hogy minden obzaviduetsya színesanyag; És a sebezhetőségek mindegyike - a kiválasztáshoz hasonlóan itt: te és DoS, parancsok végrehajtása, sql-kérések végrehajtása, rendszergazdai jogok megszerzése és bármely php-kód végrehajtása ...
A PHP-nuke írt egy bizonyos Francisco Burzi-t (Francisco Burzi) a hírprojektnek
A motor létezésének két évében óriási számú változat létezett, a projektnek hitelesnek kell lennie, tökéletesen támogatott, és talán Francisco nagyon jól ír a PHP-ben :). Nem, ez igaz, a KUCHU lyukak ellenére, kaklbasit SUCH projekt 380 óra - ez jó;).
Sérült változatok: szinte minden;)
Diagnózis: bármely php kód futtatása
A $ file változó értékei nagyon rosszul vannak ellenőrizve - a ".." jelenlétére. "/" a sor elején. A kódoló nem gondolta, hogy a $ fájl képes és kellene, esetünkben, a PHP végrehajtható szkriptjének URL-je. Azonban nem minden olyan egyszerű. Például amikor teszteltem a hibát a winNT + Apache + php3-n, ez nem működött - "Nem sikerült megnyitni. ", Érted.
Az egész a php beállításaiban volt - az "Url fopen wrapper" funkció ki volt kapcsolva (amikor php-t állítottam be, a tehetetlenség miatt minden szükségtelen opciót feltörtem). A legtöbb szerveren a szolgáltatás be van kapcsolva, így valószínűleg nem lesz probléma. De még az én esetemben is könnyedén kóboroltam a lemezt - $ file = c: winntwin.ini. Természetesen, ha a gép a * nix alatt van, akkor ez nem fog működni - "/" a $ file sor elején van levágva.
Most a pusztító szkriptről, arról, hogy mit írj le ott. Filozófiai kérdés, de még mindig pár fejleményt adok:
Szibériából szerelem.
Regardz2: X-crew, Bill Gates és Monica Levintsky ', $ a);
Egyszerű és ízléses, bár tovább lehet menni:
Ez a kód, ahogyan megérted, végrehajt egy parancsot a $ parancsváltozó parancsból a kiszolgálón.
Például:
A PHP-ben két operátor van - igényelnek és tartalmaznak, amelyek a kódot a megadott fájlból olvassák le és futtatják. Ennek köszönhetően újra felhasználható funkciókat és állandókat hozhat létre külön fájlban, és más helyzetekben hívhatja őket. (Gyakran a kényelem a forgatókönyvet konfiguráció minden beállításával tárolása egy kis script, ahol könnyen szerkeszteni egy személy, aki nem ismeri a nyelvet, félelem nélkül károsítja a mögöttes kód. Vagy például, hogy nagyon kényelmes, hogy darabjai is html'ya ne írjon sokszor ugyanaz elemek.)
A funkciók, amint látja, hasznosak a kódolókhoz és a hackerekhez;). Mi a különbség a (); és megkövetelik (); Láthatatlan, de alapvető: require (); Egyértelműen lecserélik az értelmezés során a kódot a megadott fájlból, és include (); kiszámítja és végrehajtja a kódot egy külső fájlban, amikor egy include utasítás kimutatódik. Ez lehetővé teszi, hogy a függvény hurokba kerüljön, ami lehetetlenné tehető. És még több. Végrehajtáskor ezek a funkciók visszaadják az értékeket - ha volt probléma, hamis, ha minden rendben van, akkor igaz. A különbség az, hogy ha elkezdi a keresletet, akkor a parancsfájl leáll, ha a függvényt használják, a végrehajtás folytatódik. Így általában megköveteli, hogy egyenértékű a kóddal:
Általánosságban elmondható, hogy a rendszerfunkció végrehajt minden parancsot a kiszolgálón, végrehajtva a végrehajtás eredményét. Véletlenül sok hiba alapul. Például a következő kódot gyakran használják levélküldésre:
Rendszer ("mail $ email Ha azonban a $ e-mail úgy néz ki, mint a "--blahundragogo; rm-Rf; lohundra", akkor az összes fájlt és alkönyvtárat törli a könyvtárhoz képest. Rendszer ("mail -blahundragogo; rm-Rf; lohundra Itt a csapat három részből áll: 1) mail -blahundra - érvénytelen zászló a mail funkcióhoz, figyelmen kívül hagyva; 2) rm-Rf destruktív függvény; 3) lohundra Információim szerint ez a lyuk viszonylag nemrég jelent meg a bugtracken, és az írás idején nem adtak ki foltokat, és a hivatalos oldalon egy lyukas verziót készítettek. By the way, majdnem elfelejtettem. Ez a biztonsági rés lehetővé teszi a kiszolgáló tesztelését! Ie csak hozzon létre valahol messze, messze a távoli könyvtárban a lala.php fájlt, amelyben például írsz, itt van: Mind;). Most, hogy a paprika patch a hibás motort, akkor egy backdoor, amelyen keresztül meg lehet még egyszer lomanut hely;) Mindazonáltal egy rövid ideig fog működni - ha a paprika nem idióta, majd, miután a második megrongálni, úgy néz ki, naplók webszerver és azonnal akkor összeolvad; . (((De mindig van esély arra, hogy vagy nem férnek hozzá a naplók (write adminok Levél naplók rá, (), vagy nincs agya. Sérült változatok: 5. * Diagnózis: képes szinte bármilyen sql-lekérdezés végrehajtására Az áldozatok keresése: pollBooth.php vagy például auth.inc.php A motor korábbi verzióiban statikus táblázatok (például üzenetek, szerzők) használtak. Nyilvánvaló, hogy az adatbázisban való jelenlétük nagyon valószínű, és az összetévesztés elkerülése érdekében a nevek most egy előtagot adnak a konfigurációs parancsfájl config.php által definiált $ előtagból. Ebben az esetben az SQL lekérdezés az adatbázisra nézve így néz ki: mysql_query ("UPDATE $ prefix" ._ történetek. "SET counter = counter + 1 ahol sid = $ sid ") Amint láthatja, van egy hívás a mainfile.php-ra, amely viszont felhívja a konfigurációs fájlt. Nem kell ezt, szükségünk van egy $ előtagra, hogy szabad legyen, és oda tudjuk tenni a saját kérésünket. Ez úgy történik, egyszerűen - definiált változók $ mainfile, $ tid, $ sid, és tedd $ prefix kérés (függvény isset (); használjuk, hogy meghatározzuk a fontos tényt - meghatározzuk, hogy minden változó, azaz például hogy a felhasználó kitöltötte a a mező). Mit kell elhelyezni a $ előtagban? Nos, például itt van: a szerzők pwd = 'coolpass'; update nuke. Így a végrehajtott lekérdezés a következő lesz: Az UPDATE szerzők pwd = "coolpass" -ot állítottak be; update nuke_stories SET counter = számláló + 1, ahol sid = $ sid "), amely megváltoztatja az összes rendszergazda jelszavát" coolpass "-ra. Diagnózis: ügyféloldali kódfuttatás Az áldozatok keresése: pollBooth.php fájl, vagy például auth.inc.php (By the way, jelenleg készítek egy anyagot a két gyakran használt technológiáról a szkriptek hackeléséért: a CSS és az SQL injektálás, amelyben elmondom, hogyan kell elvégeznie a fentieket.);) Sérült változatok: 0.4.02 (legfrissebb) Diagnózis: fájlok olvasása a szerveren Áldozatok Keresés: file / lang / Englign / config Leírásalovo: Hmm ... a lyuk olyan régi, mint a világ, de valamilyen okból a programozó nem gondolta. Nos, kapd meg;). Olvassuk a felhasználó számára elérhető összes fájlt. Például elolvashatja a konfigurációs parancsfájlt, és onnan el tudja tölteni a jelszót az adatbázisba, amely egybeeshet az FTP kiszolgálón lévő jelszóval a webhelyen, és így tovább. Képzelje el, hogy az $ l ellenőrzése ".." egyáltalán nem. Nagyon idegesített - nem tudod írni, ne írj. Nem, felmászik, és még megjelenik alkotásaik nyilvános megjelenítésén - nem világos, miért? Sérült változatok: 0.4.02 (legfrissebb) Diagnózis: Adminisztrációs jogok beszerzése Xploit: cookie access = ok Leírásalovo: Őszintén szólva, amikor elolvastam ezt a hibát, körülbelül öt percig rozsdásodtam, miután ismét felsóhajtottam. Ez mennyit és mit kell inni, hogy azonosítsam a "hozzáférési" cookie rendszergazdáját az "ok" értékével :)? Nem, ha ez egy privát, eredeti szkript volt - bárhova is ment, mert csak a hibáról tudsz meg, ha megnézed a kódot, nem fogsz kideríteni kívülről. De miután a projekt összes szótagja felkerült a helyszínre, így ez a ostobaság öt perces ügy. Nézd meg magad: Xoops - egy másik lyukas motor, elég, úgy tűnt számomra, funkcionális, nagyon közönséges;). Nem találtam lyukat ebben - először a termék elég fiatal, másrészt a programozók a biztonságra gondoltak, amikor írtak, bár nyilvánvalóan nem sokáig. Sérült változatok: Xoops RC1 Diagnózis: SQL lekérdezés végrehajtása Áldozatok Keresés: file userinfo.php Opisalovo: In userinfo.php szkript nem ellenőrzi a különleges karaktereket a változó $ az uid, amelyet az SQL-lekérdezést, amely lehetővé teszi, hogy játsszon bő sql-lekérdezések, módosítására vagy törlésére adatok). Ha a $ uid $ 7545 értéket állítja be, akkor a PHP hibát jelez: MySQL lekérdezési hiba: SELECT u. *, S. * FROM x_users u, x_users_status s WHERE Hibaüzenet: Hiba történt az SQL szintaxis közelében '; ÉS u.uid = s.uid "az 1. sorban Ez sokat segít: láthatja, hogyan működik az sql-lekérdezés, ami lehetővé teszi, hogy felakasztja magát;)! Nos, például ... ilyen: $ uid = 2; frissítés x_users password = 'coolpass'; válassza ki a * x_from felhasználókat, ahol uid = '1' Most az elküldött SQL lekérdezés így néz ki: SELECT u. *, S. * FROM x_users u, x_users_status s WHERE u.uid = 2; frissítés x_users password = 'coolpass'; válassza ki a * x_from felhasználókat, ahol uid = '1' Nyilvánvaló, hogy a "frissítés x_users" helyett. "Bármely sql-kérés állhat meg, a végrehajtás jogát, amely az aktuális SQL-felhasználó. Ez a bekezdés azoknak szól, akik nem tudják, hogyan keressenek sebezhető webhelyeket. Ha nem vagy közülük - kihagyja ezeket a sorokat, akkor sem veszít semmit. Tehát ... Kezdjük az alapokkal ... Mi a szkript? A szerveroldali program futtatása mellett ez csak egy fájl. És mint minden olyan fájl, amely a webhelyen működik, a más oldalakon található hiperhivatkozások vezetnek hozzá. Tehát az áldozat kereséséhez elég a keresőmotorba beírni a sebezhető szkript nevét. Egy másik gyakran használt speciális szkennerek, amelyek, mint egy kereső bot, ellenőrizzék az adott URL-eket egy adott szkript vagy egy szkriptcsoport számára. Nyilvánvaló, hogy egy ilyen szkennelés telefonos vagy fizetett forgalommal nem agyag, ezért jobb az Altavista;). Általánosságban elmondható, hogy ezek a szkennerek akkor használatosak, amikor egy adott webhelyen dolgoznak - ötezer lyukas szkriptet tartalmazó lapot vesz igénybe, és egyik napról a másikra lapozik - ebben a forgatókönyvben ez a vizsgálat indokolt.
u.uid = 7545 $ ÉS u.uid = s.uidKapcsolódó cikkek