Komentáře k článku

Jdu hacknout váš server… díl 2

V minulém díle jsem na cílovém serveru objevil bezpečnostní trhlinu (SQL injection) a připravil jsme si další postup. Nyní si z databáze konečně něco vypíšu – rozhodně seznam uživatelů (a hesla, pravděpodobně zahashovaná), s trochou štěstí systémové soubory. Prozatím ale skromně začnu zjištěním metadat: verze a typ databáze a názvy důležitých tabulek a sloupců.

Zpět na článek

30 komentářů k článku Jdu hacknout váš server… díl 2:

  1. hide

    No tak to mne polil pot

    Tak jak jsem si tohle precetl, tak mne polil pot. Kdyz si predstavim co zakaznici maji za diry v PHPcku na nasich serverech … a samozrejmne

    SELECT „foo bar“ INTO OUTFILE ‚/tmp/result.txt‘;

    fungovalo.

    Bohuzel MySQL nema moznost tohle centralne vypnout, takze jsem to musel udelat na urovni useru.

    Nastesti funguje:

    update user set File_priv=’N‘, Shutdown_priv=’N‘;
    flush privileges;

    Diky moc za tenhle clanek.

    1. tomo_tn

      Re: No tak to mne polil pot

      SELECT „foo bar“ INTO OUTFILE ‚/tmp/result.txt‘;

      U mna nastastie nefungovalo, a celkovo som sa snazil riesit rozhranie pre pracu z DB velmi jednoducho a priamociaro, ale i tak by ma zaujimalo nakolko som to sprasil…
      Popravde po precitani druhej casti clanku som asi 20 minut rozmyslal a zasol nad tym „co vsetko sa da vymyslet“ a vecsina z toho ma ani len netrkla :)

      Ak by sa nasiel nejaky dobrovolnik na test poprosim nech sa ozve na tomo.hornacek@gma­il.com

    2. Ruenix

      Re: No tak to mne polil pot

      Zrovna nad /tmp to nemá moc vypovídající hodnotu, stejně jako čtení /etc/passwd. Většina moderních distribucí má nějakou bezpečnostní nadstavbu (selinux, apparmor), která přístupy hlídá a zrovna tyhle lokace jsou minimálně u apparmoru povolené. Takže když jsem to zkoušel u nás, tak passwd si přectu, ale jiné soubory (byť s právy 666) ne.

  2. kei.101

    Python+SQLite?

    Máte někdo zkušenosti se zabezpečením jednoduchých WSGI aplikací? O tom by mě zajímal článek…

  3. danaketh

    Re: Jdu hacknout váš server... díl 2

    A proto je při vytváření uživatelů jediný správný přístup přiřazování pouze těch oprávnění, která reálně využijí. Bohužel si spousta adminů usnadňuje práci přes ALL PRIVILEGES, aby nemuseli řešit případné problémy, kdyby se náhodou nějaká aplikace zbláznila a chtěla třeba zamykat tabulky. Případně nemají šajn jak to funguje, což je ještě horší.

  4. j

    Re: Jdu hacknout váš server... díl 2

    „Nemám to statisticky podložené, shodneme se ale, že klíčový business použije databázi od Oracle nebo Microsoftu, a to není není sféra, kde programátor nechá neošetřený vstup.“

    Tohle bych se tvrdit neodvazil, neb s nekolika firemnimi aplikaceni rekneme stredniho az vetsiho rozsahu mam tu cest, a derave je to jak reseto (doslova).

    1. František Kučera

      Microsoft a Oracle

      +1 taky mne tahle věta zarazila. Děravých webů postavených nad MS technologiemi jsem viděl až až – tam je snad penetrace bastlířů vyšší než u PHP. S Oraclem to bude trochu lepší, protože ne každý na to má (peníze, hardware, znalosti), ale taky už jsem vidět exoty, kteří si nainstalovali bezplatnou verzi a postavili nad tím úplnou hrůzu.

      1. okbob

        Re: Microsoft a Oracle

        Copak webů – ale aplikací – většina aplikací z 90 let, pokud neprošla zásadní renovací je děravá – a k některým z nich se dodělal i vzdálený přístup. Tipoval bych, že 1/3 profesionálních programátorů neví o SQL injection dodnes.

      2. j

        Re: Microsoft a Oracle

        Ono zalezi, co se mini pod pojmem bastlir … vs pripadne profesional …

        Pokud totiz vemu hledisko financniho ohodnoceni, tak uz sem potkal spoustu profesionalne placenych bastlicu, ktery jen lepej kod aby to „nejak“ fungovalo (= delalo priblizne to, co zakaznik chce) a nejakym resenim bezpecnosti nebo osetrovanim chyb se vubec nezabejvaj. Samo jejich sprasenina vyzaduje idealne administratorska prava, protoze leze vsude mozne a ani autori nevedi, kam vlastne jaka prava potrebuji => 777 je bezne doporuceni … lol
        Vysledek je ten, ze kdyz se neco nekde podela, tak se neda prakticky ani zjistit proc. (zadny logy, proste nic…)

        Prozmenu znam spoustu amateru, kteri odvadeji profi praci => vsechno se pekne loguje, vsechny vstupy pocitaji s cimkoli (a to i v pripade, ze „to se proste nemuze stat“) a samo vse bezi s minimalnimi nutnymi pravy.

  5. Jirka

    No a co?

    Je hezké vědět, že vaší/náší aplikaci dokáže prolomit každý fundovanější člověk, ale ruku na srdce. „No a Co?“ U blogu a eshopu, tak uteče co kdo v kolik, za kolik. Případně nějaká ta adresa a číslo účtu. Nic co bych si jednoduchým crawlerem nedokázal zjistit rychleji a snadněji.

    Pokud si určíme cenu daných informací zjistíme že takovou cenu nemají, aby se je vyplatilo chránit.
    Horší jsou díry, které mohou vést, až do přístupu k systému, ale to se dá elegantně řešit nastavením práv pro komponenty tvořící aplikaci.

    Stačí si stáhnout crawler, který prohledává inputy a cpe do nich nejznámější injecty. Já ho mam nastavený cca na 150 klíčů. Pokud tyhle testy projdou žádný hacker se nebude dál náhodně dobývat do systému. Pokud si někdo vyhlédne vaší aplikaci, že jí prolomí a bude chtít investovat peníze a čas. Tak jí stejnak dřív nebo později prolomí.

    A proc vlastně něco hackovat? Stačí si sednout do internetové kavárny, nebo se připojit do kolejní sítě. A bedlivě naslouchat.

    1. okbob

      Re: No a co?

      U špatně napsaného eshopu může utéci číslo kreditní karty. A taky s reputací na tom budete dost špatně – docela bych si rozmyslel a nebudu sám, kdo by provedl platbu v eshopu, kterému utekly citlivé údaje a dostalo se to ven – kdo ví, co ještě dalšího tam může být zpytlíkované?

      Navíc dost uživatelů používá jeden username, jedno heslo – takže získaná data mohou být využita jinde. U malých eshopů je to jedno – žádnou reputaci nemají, a tudíž nemohou nic ztratit – podvodných eshopů jsou desítky. Zavedenému eshopu to ovšem může dost nabořit byznys.

      Kdo nedokáže ochránit aplikaci proti jednoduchému útoku jako je SQL injection, tak ji asi těžko dokáže uchránit proti složitějším útokům.

        1. František Kučera

          Re: No a co?

          Třeba tenhle :-)

          K dobru jim lze přičíst snad jen to, že čísla karet a fakturační adresy byly údajně šifrované. Nicméně k tomu, zda se je útočníkům podařilo dešifrovat se staví trochu vyhýbavě: „Zatím jsme nezaznamenali žádný případ, kdy by kreditní karty nebo fakturační adresy byly nějak zneužity“ (a vyzývají uživatele, aby pečlivě kontrolovali výpisy z bankovních účtů).

        2. avp8

          Re: No a co?

          popř zoohit.cz/sk..etc. Když jsem jim napsal že se mi to nelíbí (bez zeptání a bez možnosti to číslo smazat/přepsat) tak mi odpověděli že se nemám bát že jejich systém je dokonale zabezpečen….ale že mi ho na žádost ochotně z účtu vymažou..

      1. Jirka

        Re: No a co?

        Eshop nemá důvod po Vás číslo kreditních karet chtít. A pokud mě při volbě platbě kreditní kartou nepřesměruje na zabezpečený zdroj třetí strany, kde platbu provedu. Tak ve eshopu neobjednávám.

        Ano,máte pravdu. Do systému, který spravuji se uživatele hlásí emailem a heslem. Pro problémech s neautorizovenému přihlašování (pod heslem uživatele) do systému jsem udělal kontrolu. Cca 30% lidi se pokoušelo po zneplatnění všech hesel. Vytvořit nové heslo, pod kterým se dalo přihlásit do daného emailu. A to bylo v emailu upozornění ať takovéto heslo nedávají. Cca dalších 40% má slovníkové heslo, to sice není asi takový problém, protože po 10 neúspěšných přihlášeních se login blokuje, ale to také mnoho aplikací nemá.

        „Zavedenému eshopu to ovšem může dost nabořit byznys.“ – problém je, že se to většinou nezjistí.

        Já jsem nechtěl příspěvkem říct, že ochrana není důležitá. Ale chtěl jsem upozornit, že je důležité si říct, jaké informace a jak moc chránit.
        Třeba u čísel kreditních karet, bych se nebál použít nějaké šifrování a ukládat jen šifrovaný string.

        Pokud je kvalitně nastavený systém, tak je tento článek trochu mimo.
        Třeba netuším proč by uživatel pod kterým běží databáze měl mít přístup k /etc u příkladu SELECT Load_file(‚/et­c/passwd‘).
        Řeší se tu problémy které by se neměli řešit na aplikační vrstvě, ale na vrstvě systému, dle mého názoru jednoduší, elegantnější, levnější.

        1. okbob

          Re: No a co?

          To co je zásadní je otázkou důvěryhodnosti – a otázka implementace.

          Myslím si, že pouze s prostředky, které dnes nabízejí SQL databáze lze postavit velice bezpečný systém s minimálními důsledky kompromitace některého uživatelského účtu – bezpečněji než šifrování (protože někde v kódu bude k dispozici metoda pro dešifrování) – přičemž platí, že na klasickém hostingu nelze zaručit bezpečnost (což neznamená, že se o ni nemáme snažit), a je nutné okamžitě zahazovat data, která nejsou nezbytně nutná.

          S vlastním železem se bezpečnost zajistit dá – na několika úrovních – a minimálně databáze poskytují dostatečné prostředky pro minimalizaci dopadů průniku (jednoduché, neprůstřelné – jen je začít používat).

          > „Zavedenému eshopu to ovšem může dost nabořit byznys.“ – problém je, že se to většinou nezjistí.

          Asi ne všechno se dostane na veřejnost – v každém případě to provozovatele něco bude stát, takže si na to pravděpodobně dá velký pozor. Doufám – u některých větších společností jsem se setkal s docela důraznou a koncepční bezpečnostní politikou – takže tam je alespoň určitá naděje. Větší riziko vidím u malých specializovaných eshopů, kde osobně bych nikdy nepoužil platbu kartou nebo jiné než jednorázové heslo.

    2. j

      Re: No a co?

      Tak napriklad u toho eshopu muzete nejen dostat velmi slusnej (v milionech) flastr, ze nezabezpecujete data zakazniku, ale jako bonus vas muzou zalovat ty zakaznici (o dalsi miliony).

      A specielne v pripade, ze se prokaze, ze ste nepodniknul ani ty nejzakladnejsi kroky, tak nemate zadnou sanci u soudu uspet.

      1. Jirka

        Re: No a co?

        Když si přelouskáte zákon na ochranu osobních údajů ( tedy já jsem louskal, nejsem právník), tak zjistíte zajímavé věci. A troufal bych si říct, že flastr by mohlo dostat až 50% eshopu. Ale oni tam jsou takové obezličky, které vám vysvětlí až právník, že ten zákon je vlastně k ničemu.

        Aby mě mohli zažalovat zákazníci, tak by daný hacker musel říct, že ty data získal. A samozřejmě by se vyšetřovalo jak je získal byl by v průšvihu i on. Tak proč by to dělal?

        1. František Kučera

          Re: No a co?

          A když anonymně uniknou a objeví se někde na webu, tak to nestačí jako důkaz, že je získal někdo nepovolaný?

          1. j

            Re: No a co?

            Presne tak, kdyz se nekde po netu budou povalovat data, ze kterych bude jednoznacne videt odkud pochazi, tak muzu zalovat toho, kdo ta data nezabezpecil a je mi celkem uprdele jestli ho nekdo hacknul, nebo jestli to pustil do sveta jeho zamestnance.

    3. Ash

      Re: No a co?

      Hackování není jen o krádeži dat, můžete na server také umístit reklamu a máte na čas třeba i dost lukrativní reklamní prostor zdarma, za což vám inzerent štědře zaplatí.

  6. Jakub Vrána

    Pár upřesnění

    • Není mi jasné, proč se používá příklad, který nefunguje v MySQL: SELECT * FROM articles LIMIT 50 OFFSET 50 * 0 UNION SELECT 2. MySQL musí mít za klauzulí OFFSET číslo, obecný výraz způsobí syntaktickou chybu.
    • V MySQL se dá použít COLLATE binary, které je kompatibilní s jakýmkoliv způsobem porovnávání.
    • Pro funkčnost LOAD_FILE nejsou důležitá práva uživatele, pod kterým běží web, ale toho, pod kterým běží databázový server, kde se také tato funkce vyhodnocuje.
    • Strašně rád bych se dozvěděl, jak se dá v MySQL 5 znepřístupnit databáze information_sche­ma.
    1. danaketh

      Re: Pár upřesnění

      – protože se Anonymní Hacker zamotal v popisování příkladů pro různé databáze :)

      – to bys musel lidi donutit chodit na školení nebo alespoň číst manuál

      – navíc je potřeba mít FILE oprávnění a soubor musí být menší než je nastaveno v max_allowed_packet. údajně navíc musí být soubor čitelný kýmkoliv (asi by stálo za zkoušku). Takže pokud má admin rozum, je tahle funkce nepoužitelná.

      – information_schema stejně ukazuje jen metadata pro daného uživatele, takže pokud má každá databáze vlastního uživatele s omezením právě na sebe, je to vcelku fuk IMO.

      Netuším jak jsou na tom běžné hostingy ale já uživatelům FILE rozhodně nedávám a navíc mám secure_file_priv nastaveno do /tmp/mysql pro případ, že bych snad náhodou někdy…

  7. Pilgrim

    Neberte ten článek jako návod jak co hacknout

    ale jako článek jak zabezpečit ještě více své aplikace a servery… Já jsem se třeba dozvěděl, že v podstatě na tom nejsem nejhůř, ale ani nejlíp. Na databázi používám separátní uživatele a dávám jim práva USE (select, insert, update, delete). Plus jednotlivé weby (domény) jsou děleny také na uživatele zvlášť, atd. atd. K programování většinou používám frameworky, které mají třeba SQL injection už většinou pohlídané a když ne, není nic jednoduššího než kontrolovat hodnoty, který přicházejí. Dnes už asi není potřeba něco tak ukrutně vyloženě hackovat, všechno se dá při nejhoršim vyparsovat bez větších problémů přímo ze stránek, pokud někomu nejde o účty adminů apod.

  8. vks

    Re: Jdu hacknout váš server... díl 2

    „a to není není sféra, kde programátor nechá neošetřený vstup“
    lollol rofl.
    prave to je sfera, kde se toci nejvic penez a proto se tam ochomyta nejvic neschopnych kretenu, kteri nejsou schopni ani pochopit, ze sql dotazy a xml se nemuzou tvorit slucovanim stringu bez kontroly a pojisteni nezavadnosti obsahu.

  9. Ash

    POST nebo GET

    <i>Mimochodem, je lepší použít <?php passthru(isset($_POS­T[‚q‘]) ? $_POST[‚q‘] : $_GET[‚q‘]) ?> protože GET se sice lépe upravuje…</i>

    To isset?: v kontextu nedává moc smysl, to q tam posílám já, takže pokud ho posílám přes GET, použiji v injection GET, pokud přes POST, použiji POST. Leda kdybych byl sklerotik a zapomněl co vlastně zrovna dělám, použiji isset :)

  10. Lojza

    MSSQL a bankovni aplikace PPF banky

    Ani MSSQL není argumentem pro kvalitního programátora a protože se Oracle víc než desetiletí kupoval jen proto, že jeho pád nešlo svádět na admina, je i v jeho případě předpoklad dost vedle.
    PPF banka měla svou báječnou aplikaci na bankovnictví od jakési české firmy, kde panovalo zděšení z růstu linuxu (jejich reakce byly vysloveně legrační). Takže aplikace byla čistě wokení, pod wine nefungovala a vyžadovala admin práva na lokálu, aby vůbec běžela. Těch cest, kterými bylo možné se do aplikace probourat byla řada a některé spočívaly třeba v chybně ošetřeném vstupu uživatelského jména. Číst data o úkonech s účtem tedy mohl prakticky kdokoliv. A to máme MSSQL a bankovní odvětví, tedy teoreticky to nejhládanější.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3606