Různá dělení exploitů
Exploitem, nazýváme kus kódu, který využívá bezpečnostních chybv softwaru k páchání činnosti, kterou by si autor nepřál. Někdytak bývá označována sama bezpečnostní díra. Můžeme jetřídit podleněkolika charakteristik, meziněž patří zejména:
Typ bezpečnostní chyby, kterou využívá; např. přetečení bufferu, útok na formátovací řetězec,SQLinjection atd.
Fakt zda jde o exploit vzdálený, tj. použitelný na síti bez vlastnictví jakýchkoli uživatelských účtů, nebo lokální, tj.využívajícíchybyv lokálním systému například k eskalaci privilegií (využití chyby vaplikaci běžící s vyšším oprávněním než mám jako přihlášený uživatel k provedení příkazů v jejím kontextu).
Akce,kterou využitím bezpečnostní chyby provádí;např.provedení kódu,DoS,přístup k datům
Následuje bližší náhled na samotné chyby a jejich vysvětlení.
Buffer Overflow
Buffer overflow (přetečení zásobníku) bylo poprvé veřejně zdokumentováno počátkem roku 1972, když jej zmínila studie Computer Security Technology Planning (CSTP).
„Kód, který takto pracuje, nedostatečným způsobem kontroluje zdrojovou a cílovou adresu monitoru, čímž může dojít k přepsání části paměti uživatelem. To lze využít k vložení kódu do monitoru, který umožní převzít ovládání nad strojem.“ Pojem „monitor“ je v daném případě (přece jen jde o téměř čtyřicet let starý text) vnímat ve smyslu „kernel“.
int main () {
int buffer[10];
int i;
for (i=0; i<=29; i++) {
buffer[i] = 'X';
}
}
Toto je syntakticky správný kus kódu,který bez problémů přeloží každý překladač jazyka C.K přetečení dojde, když je lokální pole „buffer", pro které je alokována paměť na deset prvků typu int, naplněno prvky dvaceti. Abychom pochopili, proč je využití sofistikovanější, koukneme se na další útržek z kódu.
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
}
void main() {
function(1,2,3);
}
bottom of memory
top of memory
buffer2 buffer1 sfp ret a
b c
<------ [ ][ ][ ][ ][
][ ][ ]
top of stack
bottom of stack
O této dané chybě by se dalo rozepsat ještě v širším měřítku, ale nejsem takto znalý v C nebo C++, abych si dovolil nadále o této sofistikované problematice mluvit hlouběji. Poroto pokud máte někdo praktické znalosti, neváhejte mi je zaslat, topic milerád updatuji.
SQL Injection
SQL Injection je bezpečnostní chyba založená na možnosti manipulovat s daty v databázi bez nutnosti mít k nim legitimní přístup. Na první pohled by se mohlo zdát, že tato chyba je problémem webových technologií. Opak je pravdou. SQL Injection je problémem všech aplikací pracujících s databází. Zneužití může vést k získaní citlivých údajů, jakými jsou přihlašovací údaje, osobní údaje (rodná čísla, čísla bankovních účtu..) a v některých případech může vést k vykonání systémového příkazu, případně k ovládnutí celého serveru/počítače. Principem je vkládání nových/rozšiřujících SQL dotazů do již existujících SQL dotazů.
SQL je zkratka pro Structured Query Language, tedy strukturovaný dotazovací jazyk využívaný v relačních databázích pro práci s daty. První myšlenka návrhu a vzniku SQL spatřila světlo světa v laboratořích firmy IBM při výzkumu a návrhu relačních databází. Cílem bylo vytvořit jazyk co nejvíce blízký běžné mluvené angličtině, což se nakonec víceméně podařilo. V dnešní době existuje celá řada databázových mutací jazyka SQL - MySQL, MSSQL, Postgre, Oracle, SQLite, MSQL atd.
Více o samotné obraně a útoku v mém topicu zde.
Cross Side Scripting (XSS)
XSS neboli Cross-Site Scripting je jedna z nejstarších zranitelností webových aplikací. A protože jí stále mnoho webů, resp. webových aplikací trpí a většina uživatelů má JavaScript zapnutý, ukážeme si jednoduché příklady, jak zranitelnost vzniká a jak se jí bránit. Článek je věnován zejména těm, kdo o XSS zatím pořádně neslyšeli.
co mohou způsobit znaky „<“ a „>“
Začneme příkladem. Mějme jednoduchou stránku s jedním vstupním polem, které je součástí formuláře. Formulář odesílá svůj obsah na stejnou stránku a zobrazí obsah odeslaného políčka.
<html>
<body>
<form>
<input type="text" name="test">
<input type="submit" value="Odeslat a zobrazit">
<br>
<?php
if (isset($_GET['test'])) {
echo 'Odeslaná hodnota je: ' . $_GET['test'];
}
?>
</form>
</body>
</html>
Co se stane, když do našeho formuláře zadáte slovo „pokus“? Na výsledné stránce se zobrazí slovo „pokus“. Co se ovšem stane, když k němu přidáte značky HTML a zadáte např. „<b>pokus</b>“? Zobrazí se tučně slovo „pokus“.
Jinými slovy – v tomto případě můžete libovolně měnit HTML stránku. Uvedený příklad je jedním z mnoha případů XSS. Kromě celkem neškodné značky pro tučné písmo můžete vložit i kód spouštějící JavaScript (odtud také pochází název Cross-Site Scripting).
Jak se útoku bránit? V našem případě postačí, když nahradíme znaky „<“ a „>“ HTML entitami, tedy „<“ a „>“.
Pro začátek předvedeme tu nejjednodušší funkci, která je k dispozici snad v každém programovacím jazyce – nahrazování výskytu řetězce za jiný – v PHP je to str_replace. Uvedený kód tedy změníme na následující:
echo 'Odeslaná hodnota je: ' . str_replace(array('<', '>'), array('<', '>'), $_GET['test']);
Tím jsem uvedený příklad ochránil proti XSS. Ale pozor, tato obrana není v některých případech dostačující. Proto čtěte dál.
Co může způsobit uvozovka nebo apostrof
Rozšíříme předchozí příklad – pro snadnou změnu během testování zobrazíme odeslanou hodnotu i v textovém poli.
<html>
<body>
<form>
<input type="text" name="test" value="<?php echo $_GET['test']; ?>">
<input type="submit" value="Odeslat a zobrazit">
<br>
<?php
if (isset($_GET['test'])) {
echo 'Odeslaná hodnota je: ' . $_GET['test'];
}
?>
</form>
</body>
</html>
Co v případě značky textarea?
V dalším příkladu předvedeme ještě jedno ošetření HTML, kde nemusí být na první pohled jasné, proč jej vůbec dělat. Na první pohled se totiž může zdát, že není nutné nic ošetřovat. Mějme následující příklad:
<html>
<body>
<form>
<textarea name="test"><?php echo $_GET['test']; ?></textarea>
<input type="submit" value="Odeslat a zobrazit">
</form>
</body>
</html>
A obrana? Jako v prvním příkladu – převádět znaky „<“ a „>“ na jejich HTML entity, například pomocí funkce htmlspecialchars().
Obrana v samotném JavaScriptu
Výše uvedené příklady měly jedno společné – uživatelský vstup se ošetřoval na straně serveru. A co když nás serverová strana zrovna nezajímá, můžeme si nezabezpečená data ošetřit i na klientské straně? Ano, i to jde, ukážeme si další příklad:
<html>
<body>
<script>
function zobraz() {
document.getElementById('vysledek').innerHTML =
'Odeslaná hodnota je: ' +
document.getElementById('test').value;
}
</script>
<input type="text" id="test">
<input type="submit" onclick="zobraz();" value="Zobrazit">
<br>
<div id="vysledek"></div>
</body>
</html>
Obrana je stejná jako u prvního příkladu: nahradíme nebezpečné znaky jejich HTML entitami. V JavaScriptu použijeme metodu replace().
function zobraz() {
document.getElementById('vysledek').innerHTML =
'Odeslaná hodnota je: ' +
[b]document.getElementById('test').value.replace(/</g, '<').replace(/>/g, '>');[/b]
}
Míchanice: HTML + PHP + JavaScript
PHP svou jednoduchostí přímo svádí k míchání kódu (např. v samotném HTML použijeme pro výpis hodnot PHP), a tak snad nepřekvapí ani generování JavaScriptu z PHP. Může se někdy samozřejmě hodit, ale opět je nutné si dát pozor.
<html>
<body>
<script>
window.onload = function() {
var value = 'Odeslaná hodnota je: <?php echo $_GET['test']; ?>';
value = value.replace(/</g, '<').replace(/>/g, '>');
document.getElementById('vysledek').innerHTML = value;
}
</script>
<form>
<input type="text" name="test">
<input type="submit" value="Odeslat">
<div id="vysledek"></div>
</form>
</body>
</html>
Zobrazení hodnoty je zde již ošetřeno. Ale podle předchozích zkušeností s uvozovkami a apostrofy nás hned napadne, jak apostrof prolomit.
A jak se bránit v tomto případě? Nejjednodušší je opět nahradit „nebezpečné znaky“: < a > za jejich HTML entity.
Další případ: uživatelským vstupem je HTML
Výše uvedené příklady pracovaly jen s prostým textem a cílem bylo jej zobrazit. Existují situace, kdy uživatelským vstupem skutečně je HTML, typickým případem může být webové rozhraní e-mailu. Zde vyvstává řada dalších otázek:
Co s nevalidním HTML?
Budou se zobrazovat externí obrázky?
Povolíme kaskádové styly?
Co s JavaScriptem?
Co s formuláři?
… (a řada dalších)
Na jednu stranu chceme zajistit bezpečnost a na druhou stranu uživatel chce mít „hezky vypadající e-mail“ – prostě HTML. Existuje více způsobů, jak řešit tento problém, ale nejúčinnějším řešením je použití tzv. whitelistu – seznamu HTML značek a jejich atributů, jejichž vložení povolíme (protože jsou bezpečné).
XSS a kaskádové styly
Kaskádové styly úzce souvisí s předchozí problematikou zobrazování uživatelského HTML. I zde existují možnosti, jak útočit a např. spustit JavaScript. Příkladem může být vlastnost expression dostupná v Internet Exploreru:
<div style="width: [b]expression[/b](alert('XSS'));">
Pro Firefox (a všechny prohlížeče postavené na jádru Gecko) existuje v kaskádových stylech také vlastnost, která umožňuje spuštění JavaScriptu (podrobnosti najdete v XSS Cheat Sheet), viz příklad:
<p style=[b]-moz-binding[/b]:url(xssByCssInFirefox.xml#xss);>text</p>
Řešení? Podobně jako v předchozím příkladu: whitelist, čili povolit jen ty vlastnosti, které opravdu povolit chceme.
Napsat vlastní HTML/CSS filtr není nic jednoduchého, proto pravděpodobně použijete nějakou hotovou knihovnu, v případě PHP např. projekt HTML Purifier.
Jiné webové zranitelnosti
CSRF Injekce -> Obrana doporučena v mém topicu zde
Neaktualizované Apache či jiný webový server. Exploity jsou totiž k dostání volně na internetu. Častá a kritická chyba.
Závěr
Závěrem bych asi jen dodal, že samotné zabezpečení webů a webových aplikací, je velice obsáhlé téma, které je v poslední době velice, ale velice omýváno pořád dokola, kvůli rozmáhání se hackerských útoků.
Rozhodně nedoporučuji bezpečnost podceňovat, dnes může být ,,hacker" kdokoliv. Snad Vás tento topic dostal do obrazu a nebo jste se alespoň dozvěděli něco nového.
Děkuji za přečtení.
Odkazy na databáze exploitů
http://1337day.com/
http://www.exploit-db.com/
