Přejít k navigační liště

Zdroják » Různé » Jdu hacknout váš server… díl 1

Jdu hacknout váš server… díl 1

Články Různé

Jsem hacker a chci váš server. Přečtěte si, jak postupuji, čeho se snažím vyvarovat a jak mě naopak můžete odhalit. Možná jsem se přes bezpečnostní díru ve formuláři dostal na vaše SSH. Jako root. Nebo jenom k celé databázi, to přes sql injekce. Dnes začnu přípravou průniku. Pojďte mi nakouknout přes rameno.

Celý článek se točí kolem hacknutí jednoho webu, detailně ale zmiňuje i další postupy, které jsem nemusel využít. Využívám pouze chyby, kterých se dopouštění programátoři webových aplikací, takže se nedozvíte, jak obejít firewall, otrávit DNS, ani jak odchytávat zabezpečené připojení a lámat hesla. Začínám SQL injekcí. I pokud víte o co jde, dozvíte se něco nového. Než začnu hledat nezabezpečené vstupy, zjistím si co nejvíc informací. Je dobré projít detaily domény (whois), http hlavičky a další…

SQL injection

Až příliš častý problém při práci s databází je SQL injection – ohnutí uživatelského vstupu tak, aby pozměnil původní SQL příkaz. Dá se příjemně snadno otestovat: stačí vyzkoušet různé varianty uvozovek a klíčových slov na některé uživatelské vstupy. Náchylná stránka se v drtivé většině případů rozbije, protože programátor s chybou v SQL samozřejmě nepočítá. Jestli jsme úspěšní, zjistíme tedy často na první pohled: server pošle jenom část odpovědi (neúplnou/useknutou stránku) nebo se výstup nějak kriticky změní – typicky se mohou načíst články bez omezení, protože se změní LIMIT, nebo se načtou všechny kategorie/tagy místo vybrané ap.

Můj první cíl bylo pole pro vyhledávání mezi příspěvky. Zkusil jsem zadat jenom apostrof a uvozovky "'. Po odeslání se mi vrátila escapovaná varianta "'  – téměř jistě známka zapnutých magic quotes.

Jakkoliv se na tuhle dnes zastaralou a z PHP 5.4 úplně odstraněnou vlastnost dívá s despektem, svou roli splňuje výborně. Zatím mi brání vyskočit z SQL příkazu a upravovat ho podle chuti… nebo ne?

Oťukávání vstupů

Jako programátor se můžu zkusit vžít do toho, jak původní autor postupoval při vytváření aplikace: text je jasně v uvozovkách, číslo se přece píše rovnou. Kámen úrazu jsou proměnné. To když si vývojář po proměnou cislo_stranky nedokáže představit jako text a do SQL ji zapíše takhle:

SELECT * FROM articles LIMIT 50 OFFSET 50 * $_GET['cislo_stranky']

Číselné vstupy jsou různá id, stránkovač, nebo rovnou offset/limit a podobné, rozhodně by neměl být problém nějaký najít a prozkoušet.

Kliknul jsem si tedy na druhou stránku výpisu a v url jsem přidal k číslu ještě '2 OR 1=1'. To je vstup, který původní SQL příkaz nerozbije, jenom nechá vypsat všechno bez omezení. Tentokrát jsem měl štěstí a našel jsem tady bezpečnostní díru. Kdyby byly všechny vstupy v uvozovkách, musel bych obcházet magic_quotes.

Vícebajtová kódování

Málo známý problém s magic_quotes jsou vícebajtová kódování. Zjednodušeně jde o to, že PHP vyhledává všechny bajty 0x22 (uvozovky), resp. 0x27 (apostrof) a přidává před ně 0x5C (lomítko). To znamená, že z vstupu 0xKL 0x22 (nějaký bajt a uvozovky) se stane 0xKL 0x5C 0x22. Běžné ASCII, které má pro každý znak právě jeden bajt, je v bezpečí. Běží-li ale cílový server na kódování s proměnlivou délkou znaků, stačí nám zvolit takový bajt, aby 0xKL 0x5C byl validní znak. Celkem tedy vzniknou dva znaky: paskvil z našeho bajtu a lomítka od PHP a jedny čisté uvozovky, díky kterým můžeme napsat SQL injekci.

(Zdroj: shiflett.org)

Anonymita

Když si nedáte pozor, skončíte dřív, než jste vůbec začali. V dobrém případě jenom v blacklistu (to pokud je admin úplně matlas), v horším případě si chyby všimne a opraví ji. Samozřejmostí by měla být nějaká spolehlivá proxy (ne, jestli posílá X-Forwarded-For, není to ideální volba).

Dobrá síť je TOR, možná jsem ale zatím jenom nenašel nic lepšího. Zpátky se k vašemu PC se prakticky nikdo nemůže nedostat. Když nepracujete nad secured http, může si sice první a poslední node přečíst, co vlastně děláte, ale to není riziko, nad kterým bych si osobně lámal hlavu.

U SQL injection je teoreticky dobré se vyvarovat vstupů, které skončí chybou na serveru, protože ty se logují explicitně. Jelikož je ale rychlejší zkusit deset nápadů než jeden složitě promýšlet, radši doufám, že správce se na log nekoukne. A jestli obdrží při každé chybě e-mail, nedostali bychom se moc daleko tak jako tak.

Je obecně dobré vybírat si POST formuláře, protože GET parametry se logují (POST se pochopitelně loguje také, ale jenom adresa, ne parametry). POST navíc nemá omezení na délku požadavku tak tragicky krátké. Na to je dobré myslet při posílání dat na server.

A pochopitelně jestli na sebe nechcete vůbec upozorňovat, posílejte požadavky přiměřeně velikosti serveru a hlavně v rozumnou dobu. Nic nepřekvapí víc než peak v datech Google Analytics kolem dvou hodin v noci. To když jste zrovna pouštěli nějaký testovací skript.

Plán

Už víme, že cílový server je náchylný na SQL injection. Nastává dobrý čas připravit si další postup – seznam čeho a hlavně jak chceme dosáhnout. V tomto případě si chci vypsat z tabulky obsahující uživatele jejich hesla a přihlašovací jména. Na to potřebuji znát, jak přesměrovat původní SELECT na jinou tabulku a musím také zjistit, jak se vůbec tato tabulka jmenuje. Budu pokračovat tím, že si zjistím typ a verzi databáze, se kterou bojuji. Tou samou databází si přečtu /etc/passwd a zkusím zapsat php shell. A samozřejmě už dávno budu mít seznam potenciálních uživatelů a jejich hesla.

… ale to až v příštím díle!

Komentáře

Subscribe
Upozornit na
guest
60 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
kdosi

UTF8 je sice vicebajtove kodovani, ale jeho platne hodnoty jsou:

U+00000000 – U+0000007F 0xxxxxxx
U+00000080 – U+000007FF 110xxxxx 10xxxxxx
U+00000800 – U+0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
U+00010000 – U+0010FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

2 az 4 bajt tedy musi mit hodnotu vetsi nebo rovnou 128. Zpetne lomitko (92) tak muze byt pouze v prvnim bajtu. Pokud poslu (alespon do MySql) neplatny utf8 znak , dotaz selze.

Tento typ utoku je tedy pouzitelny pouze s kodovanim, ktere nema toto omezeni. Zname je napr. GBK.

KapitánRUM

To je pravda, ostatně i v tom článku z odkazu je napsáno „UTF-8 does not fit this description“. Ale ano, stál bych o vysvětlení.

KapitánRUM

Ovšem oceňuji VELICE zajímavý článek.

PokerFace

„může si sice první a poslední node přečíst, co vlastně děláte“

kazdy skolak vi, ze prvni node nevidi nic… Jak muze „hacker“ neco takoveho vypustit z ust?

Dragonn

Není náhodou u Toru standartně první node na localhostu? Ten přeci vidí zprávu nešifrovaně a stejně tak může být teoreticky Tor nainstalován na hraničním routeru lokální sítě a můžeme ho proto nazývat prvním nodem, ne?

Ale jinak souhlasím s výtkou, myslím, že tohle Anonymní hacker trochu přehlédl a je to matoucí …

limit_false

Ne. Na localhostu je pouze SOCKS proxy. Prvni node je nektery z Tor relayu a ten vidi pouze RELAY_EXTEND cell.

jenicek

Myslí to dobře, ale blbě to napsal.
Jinak nešifrovaný traffic ve směru hacker-tor-cil může číst poslední node v toru, zrovna tak zpětný proud cíl-tor-hacker může číst poslední z pohledu cíle, což je první z pohledu hackera.

Hloupý Nemouš

Jen tak dál a houšť. Pokud to takhle půjde dál, bude to jeden z nejlepších článků s bezpečnostní tématikou za poslední dobu.

Geekon

SQL Injection je častý problém, ale co je mnohem horší, to je development stage, nebo nevypnutí zobrazování chyb.

Spojení těchto dvou věcí je jako si namalovat na zadek terč.

Co by začínající hacker měl přečíst, jsou určitě databázové komentáře. Ty mu umožní v požadovaném místě uříznout dotaz. Proto určitě nestačí mít escapování (nebo cokoli dalšího) na středník a uvozovky.

Za další školáckou chybu lze považovat umístění admina v databázi jako uživatel s id 1. Injekce username ve tvaru 1′ or 1=1# nás přihlásí jako první uživatel v tabulce, což je potom většinou admin.

Další málo známá injekce je neošetření unsinget int. Dotaz na stránkování, nebo článek ve tvaru:

select * from articles where idarticle = {(int)get[clanek]}

poté při nepoužití mysql_num_rows končí někde chybou. Z tohoto důvodu je vhodné rovnou při vstupu kontrolovat čísla jako regulérní výraz :

preg_match(‚/^[0-9]{1,3}$/‘,$_­GET[‚clanek‘])

pro int(3), kde si podvědomně hlídáme i přetečení proměnné.

Jen na téma ošetření vstupů by se dalo napsat další dílo o rozsahu bible. Ať už unicode injection, non-alfanumerický javascript, CSRF, SQLi, LFI, uploady, dowaload ala /../../../../­../../../etc/sha­dow/, chmod0777 a tak dále ..

Geeok

Jen tak namátkou, na co jsem teď narazil při upravování upravování webu klienta od „další renomované firmy“..
Máme 21 století, tak je cool mít javascript editory na texty, zrovna nyní tu mám krásný TinyMCE
View:

<textarea class=“editor“> <?php echo $row[‚body‘]?></tex­tarea>

Controller:
..
$body = mysql_escape_strin­g($_GET[‚body‘]);
..
..
$query = ‚update comments set body = ‚.$body.‘ where id_articles = ‚.$id;
..
(Je to psáno v MVC, na SQL se používá DIBI, kde je body escapován jako string za pomocí %s)
Tak kolik tu je chyb ?

1) nepoužití limit u dotazu
V každém editu, delete už psát jako cvičená opice „limit 1 ;–„. Tedy za předpokladu, že se nejedná o hromadnou operaci.

2) Neošetření nevhodných tagů .. první věc co udělám, je :
vypnu javascript a do textarea vám napíšu:

<script>alert(‚Hac­k3d by krutohacker‘);</scrip­t>

nebo je libo iframe ?

3) další věc se mi tam nelíbí, ale zkuste na ní příjít sami.

Michal Zahradnicek

Mam taky maly dotaz k bodu 1.

Poprosim o logicke vysvetlenie, ze preco mam pisat pri dotaze LIMIT, pokial mam premennu $id osetrenu – teda viem ze sa v nej nachadza iba cislo, ktore identifikuje jeden riadok v tabulke.

3) Jasne ze chlapik zabudol dat body do uvodzoviek – pekna prasacinka, ani som netusil ze to takto ide.

podhy

k bodu jedna bych doplnil že limit u update/delete nepodporuje každá DB

Sten

Pokud by autor byl alespoň trochu zkušený, použil by transakce a UPDATE … LIMIT … se potom dá snadno emulovat pomocí SELECT COUNT(…) … FOR UPDATE.

David Grudl

> Proto určitě nestačí mít escapování (nebo cokoli dalšího) na středník a uvozovky.

Pokud proměnnou uzavřu do uvozovek, stačí mi escapovat uvozovky a nic dalšího včetně středníku escapovat netřeba. Výjimkou mohou být dotazy pro operátor LIKE.

Pokud proměnná není v uvozovkách, protože je to číslo, musím zajistit, aby to skutečně číslo bylo a pak jej není třeba escapovat.

Geekon

Davide, neber v potaz jen injection, ale i ošetření nestandartního běhu aplikace.

Jakub Vrána

Uvnitř uvozovek je obvykle ještě potřeba ošetřovat zpětné lomítko.

jfila

Tak to jsem zmaten! Co je na konstrukci:
$dotaz=“SELECT * FROM `produkty` WHERE `ID` = „.(int)($_REQU­EST[„Produkt“]);

špatně? $_REQUEST[„Pro­dukt“]) je přece přetypován na číslo, pokud se nejedná o číslo, pak vrátí nulu. Což je zase ošetřeno dále a stránka řekne, že podobný produkt není. Stránky jsem testoval například proti tomuto: 5′;DROP TABLE produkty; — můžete uvést konkrétní příklady vstupů které tato konstrukce neustojí?

David Grudl

Skutečně to mělo být na mě? Z hlediska SQL je to v pořádku, z hlediska bezpečnosti je vhodnější použít $_GET[„Produkt“], protože pokud bych vytvořil cookie Produkt, zobrazoval by se produkt i v případě, že by parameter nebyl v URL.

Geekon

Tato konstrukce je jak sem psal nebezpečná na nestandartní chování aplikace, web prolejzají stovky crawlerů a ty testují i vkládání nestandartní int do requestu.

Je to spíše goog practics

Čelo

Jenom bokem menší výtku… píše se „nestandardní“ (vidím, že si to slovo použil třikrát a vždy špatně).

David Grudl

Pokud přetypuji proměnnou na integer, tak je konstrukce bezpečná, ať už bude vstupem cokoliv. Nebo máš nějaký příklad vstupu, který by příklad Jana Fíly narušil?

To Jan Fíla: omlouvám se, že jsem to považoval za reakci na svůj komentář. „Závada“ je na straně Zdrojáku: pokud je příspěvek nový (třída .new), posune jej padding o 10px vpravo, takže vypadá jako reakce na jiné vlákno.

j

Podotykam, ze nejsem programator (nebo se za nej napovazuju).

Ale samozreme, kodu sem napsal celkem hromadu. Co si pamatuju uz od ZS, tak vzdycky bylo osetreni vstupu 80% kodu. Dneska je ovsem „moderni“ vstupy neosetrovat, a pockat az to nekde zbuchne na nejake vyjimce …

A presne podle toho to taky vypada.

František Kučera

No, ošetřovat vstupy… v první řadě je potřeba rozlišovat význam – zda se jedná o data nebo o program. V tomto případě je programem SQL dotaz. Uživatel mi nesmí zasahovat do programu, ale data mi může posílat libovolná (ať si řetězce obsahující apostrofy a další značky klidně vyhledává nebo zadává do formulářů).

Následně můžu ošetřovat vstupy třeba stylem, že nedovolím, aby uživatel mohl zadat jako věk člověka 300 let nebo další omezení. Nicméně základem nedovolit, aby se data interpretovala jako program.

BTW: mám tu jednu aplikaci (SQL Výuka), která uživateli umožňuje zadat libovolné SQL a vykonat ho – taková záměrná SQL injection. Nestojím o DoS útoky, ale pokud by si chtěl někdo hrát a zkoumat, zda se to dá nějak zneužít, budu rád, když mi pak napíše výsledek svého snažení :-)

NN

Kedysi dávno bola zaujímavá séria článkov/cvičení na blackhole.sk. SQL injection je tam len simulovaná, ale je to celkom dobrá zábava: http://blackhole.sk/cvicenie-na-sql-injection
Ďalšie zaujímavé „hackerské“ cvičenia:
http://blackhole.sk/cvicenie-manipulacia-webovych-ankiet
http://blackhole.sk/cvicenie-na-web-aplikacie

Kedysi dávno som skúšal hru na niečom podobnom ako je hackthissite.org akurát to fungovalo bez registrácie. Žaiľ na názov webu si už nespomeniem, ale vyššie levely tam boli už veľmi prepracované a zaujímavé.

x

Jenze spousta „programatoru“ trebas nekde ocekava vstup – rekneme cislo, ale nijak nezjistuje, ze to cislo skutecne je. Jednoduse se to, co tam nekdo flakne, pokusi insertnout do int pole v DB a cekaji, estli to vrati chybu (napr).

Mam denne tu cest s jednim „erp“, kde SQL injection je standarni postup … – system samozrejme nepouziva SQL opravneni, ale resi si je na urovni aplikace => pokud se najde trochu znaly uzivatel, muze si data(jakakoli) nejen precist, ale i libovolne modifikovat na urovni databaze … Jako bonus se samozrejme neda zjistit, kdo to byl (pokud by se na nejakou zmenu prislo, coz je pri tech desitkach GB nerealny).

jfila

Ještě jednou, nějak jsem se zamotal do vláken.
Tak to jsem zmaten! Co je na konstrukci:
$dotaz=“SELECT * FROM `produkty` WHERE `ID` = „.(int)($_REQU­EST[„Produkt“]);

špatně? $_REQUEST[„Pro­dukt“]) je přece přetypován na číslo, pokud se nejedná o číslo, pak vrátí nulu. Což je zase ošetřeno dále a stránka řekne, že podobný produkt není. Stránky jsem testoval například proti tomuto: 5′;DROP TABLE produkty; — můžete uvést konkrétní příklady vstupů které tato konstrukce neustojí? Hlavně mluvím o přetypování.

v.sp

Já nějak nechápu, proč je SQL injection pořád ještě takový problém. Přece i mysql umí bindované proměnné, ne? Oč je těžší dát do textu SQL „where id = ?“ než pracně lepit text?
(A nevím jak mysql, ale třeba v Oraclu použití proměnných znamená menší počet parsování, což server velmi ocení.)

To to neumí PHP? Nebo jsou programátoři takoví matláci? Já fakt nevím, webové jazyky zas tak dobře neznám a PL/SQL, OCI či Perl (DBI) to umí v pohodě.

Geekon

1)
Programátor stojí kolem 30-70k/měsíc, student sice neumí ani používat indexy, ale stojí kolem 10-30k/měsíc.
2)
Menší počet parsování se projeví až u více zatěžující aplikace, na web města, který běží na předražené VPS, nebo web na hostingu, s návštěvností 200 lidí denně se to prakticky neprojeví (== není důvod řešit,bohužel)

Oracle neznám, to je segment trhu, kde se nepohybuji, takže nevím, jestli lze přímo quotovat unsinget int.

Tomi

Presne tak, co sa webovych frameworkov tyka tak napr. z Javy take JDBC, JPA alebo Hibernate toto v pohode osetruje, takisto .Net a ku vsetkemu to riesi aj priamo SRBD tym ze nenecha po spadnutom prikaze prejst „injectnuty“ dalsi.
…skoda ze tento clanok sa opiera o vec ktora dnes uz moc nefunguje :(

MartinX

No cisto teoreticky by bolo mozne urobit SQL injection aj na J2EE appservri, ale kedze samotny SQL dotaz vytvara az JPA (alebo Hibernate framework) a data do dotazu idu z servletu/jsp vo web containeri cez perzistentne objekty v entity EJB v EJB containeri , tak to prechadza cez tolko vrstiev, ze potencialny SQL injection utok je ovela narocnejsi, ako v pripade priamej generacie SQL dotazu v PHP.

zz_indigo

bohuzial v poslednom riadku sa mylis.

NEveril by so kolko lusi naksle na sebavzdelavanie a veci programuju tak ako pred par rokmy a zmeni sa len grafika aby to bolo IN.

j

Viz vejs, technika funguje velmi dobre, pocitam ze 30% webu se da pres injection napadnout. Samo nektere to primo ulehcuji.

Murdej

Nevim jak primo v PHP ale Zend_DB umožňuje zapsat dotaz takto
$db->fetchRow(„SELECT * FROM neco WHERE sloupec=? AND sloupec2=?“, array($val1, $val2));

Zen

Co se prelozi jako
SELECT * FROM neco WHERE sloupec=$val1 AND sloupec2=$val2
A pokud nejsou osetrene hodnoty $val1 a $val2, tak se opet racite nachazet tam, kam slunce nesviti (PHP samo neosetruje skoro nic)

...

napřed bych si o tom něco zjistil než napíšu takovou blbost…pokud použijete mysqli nebo pdo tak se tyto proměnné do dotazu bindují

Sten

A co si to zkusit? Zjistíte, že výsledek bude stejný jako u:
‚SELECT * FROM neco WHERE sloupec=“‚.mys­ql_escape_strin­g($val1).'“ AND sloupec2=“‚.mys­ql_escape_strin­g($val2).'“‚

Btw. tohle sestavování dotazu nedělá PHP :-)

enumag

SQL Injection je známá a u nových projektů dnes už většinou důkladně hlídaná věc. Článek je tedy z mého pohledu poněkud neaktuální. Uvítal bych příklady jak hacknout server, který na SQL Injection náchylný není, tedy méně známé a tím nebezpečnější techniky.

X

Nesuhlasim. Uz len z komentarov som sa dozvedel niekolko zaujimavych veci, ktore mi predtym nenapadli.

David Grudl

Jsem vděčný za každý solidní článek o bezpečnosti, protože je stále podceňovaná a na také toto téma koluje řada mýtů, ale tentokrát se to úplně nepovedlo :-(

Hlavní problém s magic quotes spočívá v „předčasném escapování“, data jsou tedy upravena pro použití v SQL dotazu v konkrétním dialektu starší MySQL či Sybase. Čímž se komplikuje provádění jakýchkoliv jiných operací s nimi, počínaje použitím v jiném dialektu a kódování SQL, přes ověření délky, zkrácení nebo prosté vypsání do HTML. Na což vlastně i autor narazil, když se mu vypsaly před uvozovkama lomítka.

Magic quotes jsou tedy problematické už z principu a problém vícebajtových kódování je logický důsledek. Ten je v článku popsán korektně, nicméně UTF-8 se skutečně netýká. Jelikož na webu je primárním kódováním právě UTF-8, obvykle se i s databází komunikuje v UTF-8 a problém je tedy, alespoň v našich končinách, spíše hypotetický. Nicméně když už ho zmíním, je vhodné dodat, jak problému předejít: buď použitím bindovaných proměnných nebo escapovat vhodnou funkcí, např. mysqli_escape_string (či použít vyšší vrstvu).

Příklad s ‚2 OR 1=1‘ v případě stránkování mi připadá nevěrohodný, nenapadá mě stránkovací dotaz, který by se tímto nerozbil a nechal všechno vypsat bez omezení. Poradíte?

Ondřej Melkes

Varainta: ‚2 OR 1=1‘
SELECT article_name FROM article WHERE category_id = 2 OR 1=1 LIMIT 0,30

Případně varainta: ‚2 OR 1=1 –‚
SELECT article_name FROM article WHERE category_id = 2 OR 1=1 — LIMIT 0,30

David Grudl

Díky. Takto je to jasné, nedává mi to smysl v kontextu toho odstavce o stránkování a věty „Kliknul jsem si tedy na druhou stránku výpisu a v url jsem přidal k číslu ještě ‚2 OR 1=1’“

Autor

Máte určitě pravdu, že v kontextu té věty to úplně smysl nedává. V originále bylo stránkování řešené WHERE id < x AND id > x - 10, takže když jsem to psal, mluvil jsem o stránkování. Názornější bylo zmínit jenom WHERE.

K utf-8: to je nešťastně zmíněné jako příklad dynamic width kódování, zbytek odstavce se na to nevztahuje. Beru v potaz, příště pečlivěji.

David Grudl

Současná formulace „Běží-li ale cílový server na kódování s proměnlivou délkou znaků…“ stále není správná, stejný problém se totiž týká i kódování s _pevnou_ vícebajtovou délkou znaků, jako je třeba UTF-32.

František Kučera

Problém se týká hlavně hloupého jazyka (resp. jeho standardní knihovny), pokud tam funkce tohoto typu pracuje na úrovni bajtů a ne na úrovni znaků…

David Grudl

Právě proto je už z knihovny odstraněna.

XXX

>> Hlavní problém s magic quotes spočívá v „předčasném escapování“, data jsou tedy upravena pro použití v SQL dotazu v konkrétním dialektu starší MySQL či Sybase. Čímž se komplikuje provádění jakýchkoliv jiných operací s nimi, počínaje použitím v jiném dialektu a kódování SQL, přes ověření délky, zkrácení nebo prosté vypsání do HTML. Na což vlastně i autor narazil, když se mu vypsaly před uvozovkama lomítka.

Toto je ale o bezpecnosti, ne o tutorialu programovani. Magic quotes jsou skutecne spatne a zadelavaji na spoustu problemu, fakt ale je, ze pro hackera jsou velkou prekazkou.

Jakub Vrána

Pokud bychom s obskurními kódování skutečně pracovali, tak pro správné ošetření mysqli_escape_strin­g() nestačí, je potřeba zavolat ještě mysqli_set_char­set().

Pilgrim

I když pro mě nic nového, ale i tak oceňuji kvalitu článku zejména v jednoduchosti vysvětlení o co vlastně jde u SQL Injection. Osobně jsem již také na jednom svým webu toto zkoušel. Pravda, že schválně jsem si přizpůsoboval skripty příkazům v URL, ale to hlavně, abych dokázal ještě víc poznat, na co si dát pozor. Těším se na další díl…

profi hacker

Nezlobte se na mě, ale SQL injection je opravdu amatéřina, profesionální hacker používá sociální metody a vlastní software na infiltraci do sítě, dá se pak dostat téměř všude.

Uvedu příklad, naprogramuji si vlastní trojan, který přidám do warezu a rozšířím ho přes warezové stránky. Nádhera je, pokud není moc rozšířený, tak se v nějakých blacklistech antivirů můj trojan vůbec neobjeví.

A co můj trojan může dělat, sebrat heslo s Total Commandera na FTP, sebrat hesla z prohlížeče atd… To je jen malá ukázka toho, kam se dá zajít. Chce to taky trošku social engineeringu, znalosti programování atd…

Problém většiny „rádoby“ hackerů tkví v tom, že nemají sociální skilly, nejsou tedy schopni opravdu promyšlených útoků. Podle mě se mnohem lépe útočí se social engineeringem než bez něj.

Sten

Metoda by vždy měla odpovídat vytyčenému cíli. Pokud chcete napadnout nějaký (jakýkoliv) server a to pokud možno hodně masově, je trojan asi nejlepší řešení. Pokud chcete napadnout jeden konkrétní server a navíc u toho nechcete vzbuzovat moc velkou pozornost, jsou na to jiné metody; e-mailem poslaný trojan může projít, ale co když jej chytí heuristika antiviru? Nebo na druhé straně bude někdo, kdo není úplně blbý (anebo na ten server nemá přímý přístup)? Akorát je zalarmujete, že se o něco snažíte. Osobní sociální inženýrství je ještě účinnější (hacker vydávající se za technika jdoucího opravit klimatizaci v serverovně ap.), ale co když nevyjde? Většinou vás při něm mohou i zadržet a vaši totožnost už pak zjistí policie.

SQL injection tak možná vypadá jako amatéřina, ale pro zahájení útoku cíleného na jeden konkrétní server, a to co nejvíce diskrétně (kolik adminů sleduje logy webserveru?) a anonymně, je velmi dobrou metodou. Nakonec se druhá strana většinou ani nedozví, že k nějakému útoku (ať již úspěšnému nebo třeba jenom pokusu, kdy se dozvíte alespoň nějaké zajímavé informace jako jména adminů nebo umístění serveru) došlo, což výrazně zvyšuje vaše šance s jinými metodami (třeba když na tom serveru nejsou data, která potřebujete, a ten server je v DMZ, ale najdete tam jména správců serveru, které uvedete u vchodu, včetně jejich pracovní doby, tedy abyste přišel, když tam zrovna nejsou, a přístupová jména a hesla, která vyzkoušíte v té serverovně nebo na počítačích v kanceláři).

_diehard

>Uvedu příklad, naprogramuji si vlastní trojan, který přidám do warezu a >rozšířím ho přes warezové stránky. Nádhera je, pokud není moc rozšířený, tak se >v nějakých blacklistech antivirů můj trojan vůbec neobjeví.

nezlobte se, ale autor clanku uvedl konkretni priklady, a evidentne se v problematice vyzna i prakticky.

Ve vasem prispevku pouze teoretizujete, viz odstavec vyse. Vyvedte mne z omylu a popiste jak konkretne budete postupovat..

>Problém většiny „rádoby“ hackerů tkví v tom, že nemají sociální skilly,

domnenka nebo je to necim podlozeno ?

liquid

ihmo clanek je vhodny pro ctenare, kteri neumeji anglicky.

ja

No, jestli není programátor úplný amatér, tak používá vázané proměnné a vy si s vaší SQL injection ani neškrtnete. Každý schopný programátor totiž zachází s SQL takto:

stmt = sql_prepare(dbh, "SELECT * FROM accounts WHERE username = ?");
sql_bind_value(stmt, 0, form_input_username, SQL_PARAM_STRING);
sql_execute(stmt);

Váš uživatelský vstup se syntaxu SQL ani nedotkne. A v horším případě (pro vás) jsou všechny takto čisté a univerzální SQL výrazy dokonce předkompilované a nabindované přímo v databázovém enginu jako package, u nichž má RDBMS předem připravený optimální access plan a které může využívat třeba 10k aplikací zároveň s nulovou režií.

Jakékoli „magické uvozovky“, escapování desítek znaků a sekvencí a podobné blbosti jsou jen chatrné berličky, které „pomáhají“ špatným programátorům být ještě horší.

Celý obsah článku je zvláštní. Možná by byl marginálně relevantní před 10 lety, ale dnes? Podle chvástání ve vašem perexu jsem čekal něco zcela jiného. Že třeba root.cz konečně lapil někoho fakt dobrého. O čem bude příští článek? Jak využít string format vulnerability v SSH-1.5? To vám ale asi příliš fandím… Možná by se však někde ještě taková verze našla. Že by stará SPARCstation v knihovně nějaké Kazachstánské základní školy? :)

Jestli je článek o tom, jak útočit na domácí stránky fanboyů PHP, tak beru zpět. I když ti se na víc než sdílený hosting nezmůžou a tam vám popen(), system(), passthru() ani nic podobného fungovat nebude. Tím se vám zřejmě narušil váš velkolepý plán, protože bez nich vy na serveru nespustíte jediný proces a váš sen o shellu, který byste mohl mít za 100,- ročně legitimně, opět končí v slzách. ;o)

Omlouvám se, že vám dávám tak zabrat, ale bylo to ve mně jako v koze. :) Nemyslím to zas až tak vážně. Cokoliv je lepší než ostatní články-reklamy tady. Tohle byl první článek, který jsem si přečetl po několika měsících. I když jen ironicky. Už jsem sem úplně přestal chodit.

Těším se na další díl. ;o)

Radek Miček

Možná by byl marginálně relevantní před 10 lety, ale dnes?

Nejste z jiné planety? Viz třeba http://www.pcworld.com/article/229316/lulz_boat_hacks_sonys_harbor_faq.html nebo http://en.wikipedia.org/wiki/SQL_injection#Known_real-world_examples

ja

Nejsem. Jsem forenzní analytik a programátor. Citované hodnocení se přece odkazuje na článek jako celek, ne na samotnou techniku SQL injection.

Od článku „Jdu hacknout váš server“ s úvodem jaký má bych čekal něco šťavnatějšího, nového a zajímavého. SQL injection jako primární útočný vektor je joke, viz dále. Navíc je to technika stará jako web samotný a omletá do zblbnutí. Proto je v této podobě článek 10 let pozadu. Neznalost jak funguje TOR; úsměvný návrh řešení magic_quotes; neznalost bindování; domněnka, že nějaký admin bude opravovat chybu v aplikaci… také přispívá k mým pochybnostem o autorově know-how.

S SQL injection útočník prostě jen doufá, že programátor bude naprostý diletant, stejně jako provozovatel, který nikdy systém ani aplikaci nedal zauditovat ani neprojel žádným checkerem ani nerozdělil do patřičných separátních vrstev. Objevení takové chyby je triviální a v drtivé většině případů se ani po úspěšném útoku k ničemu nedostane. Jen „pouhý“ přístup k jinak nepřístupným datům vyžaduje několik dalších technických a designových podmínek („chyb“) ve volbě RDBMS, driveru, DB schématu a použitých funkcích, které preprocesují užvateský vstup.

Většina případů (a ty high-profile všechny), které jste odkazem uvedl, neměly SQL injection jako primární vektor. Jde o jiné průniky do hlubších, méně chráněných, vrstev systémů, kde je již vyčíslitelná šance SQL injection uplatnit.

Jestli žijete v přestavě, že třeba onen útok na Sony PSN proběhl tak, že někdo na front-endovém webu zadal ve svém FFku vychytralý dotaz do políčka Search a vyjely mu účty s hesly a čísly kreditek, tak jste z jiné planety vy sám.

PS autorovi: Jak jsem ale napsal, nemyslím to zas až tak vážně. Jako zinscenovaná demonstrace principu na záměrně vadné aplikaci je to dobré. I kdyby jen pro zvýšení povědomí o problému u potencionálních programátorů, kteří si to přečtou.

Radek Miček

Jestli žijete v přestavě, že třeba onen útok na Sony PSN proběhl tak, že někdo na front-endovém webu zadal ve svém FFku vychytralý dotaz do políčka Search a vyjely mu účty s hesly a čísly kreditek, tak jste z jiné planety vy sám.

Pokud vím, tak jsem neodkazoval na PSN hack, ale pouze na hack SonyPicters.com

Většina případů (a ty high-profile všechny), které jste odkazem uvedl, neměly SQL injection jako primární vektor. Jde o jiné průniky do hlubších, méně chráněných, vrstev systémů, kde je již vyčíslitelná šance SQL injection uplatnit.

Podle těch popisů, co odkazuje Wikipedie, to vypadá, že nemáte pravdu. Nebo máte jiné zdroje?

Radek Miček

s/SonyPicters­.com/SonyPictu­res.com/

ja

Co odpovědět člověku, který se dohaduje na základě popisků v sekci referencí narychlo vygooglené stránky z Wikipedie s někým, koho daný obor léta živí a je mu i koníčkem, na otázku „Nebo máte jiné zdroje?“

Myslím, že jsem své věcné argumenty k článku rozvedl dostatečně, takže se prosím neurazte, když se s vámi rozloučím. Začíná mi to připadat jako nikam nevedoucí flame diskuze. Svoje názory ani zkušenosti vám nevnucuji.

fos4

„..které může využívat třeba 10k aplikací zároveň s nulovou režií.“

Nepřenáší se náhodou u bindování zvlášť dotaz a zvlášť data ? Pak je režie větší než v případě přípravy dotazu mimo db server.

ja

V citovaném scénáři se dotazy se nepřenáší vůbec, jsou předem naplánované přímo v DB enginu. Když máte update logiky a/nebo schéma DB, tak se nainstalovaných aplikací nemusíte ani dotknout. Pouze zupdatujete package (kolekce dotazů) nabindované v DB. Dobré řešení se tedy nepromítá pouze do rychlosti a bezpečnosti SQL, ale i ohromným úsporám času při vývoji a administraci.

Na celém dotazu je zdaleka nejpomalejší vyhodnocení přístupového plánu – co ten dotaz vlastně chce, jak požadovaná data poskládat a hlavně jak to udělat co nejrychleji (je hromada metod přístupu k datům, kombinací indexů, kontroly referenční integrity, atd). I když máte „jen“ připravené univerzální SQL (prepare) – tedy ne jako package v DB, ale běžně remote z aplikace – tak engine při preparu naparsuje dotaz, připraví plán a veškeré volání query daného dotazu jsou čisté přístupy k datům. Díky této separaci je opakovaný dotaz o několik řádů rychlejší.

Ve skutečnosti se „přenáší dotaz a parametry zvlášť“ ať voláte jak chcete. Příprava a vykonání dotazu jsou vždy dva kroky. Když prepare neuděláte vy, udělá ho aplikační driver za vás (jenže ne jednou, ale při každé invokaci). Vlastní žádost o data (ať s prázdnou nebo plnou množinou substitučních hodnot) půjde na server samostatně.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.