URL Spoofing (Falešnou URL)

Podvodné URL popisuje jeden web který se vydává za jiný. To někdy použije mechanismus, který využívá chyby ve webovém prohlížeči technologie, umožňující zákeřné počítačové útoku. Takové útoky jsou nejúčinnější proti počítačům, které postrádají posledních bezpečnostních záplat. Jiní jsou určeny pro účely parodie .

Během těchto útoků, uživatel počítače nevinně navštíví webové stránky a vidí známé URL v adresním řádku jako http://www.wikipedia.org ale je, ve skutečnosti, zasílání informací na zcela jiné místo, které by obvykle sledovat informace o zloděje. Když informace jsou citlivé na žádost podvodné webové stránky, to je voláno phishing .

Uživatel je typicky lákaly na falešné webové stránky z e-mailu nebo hypertextového odkazu z jiného webu.

V další variaci, webové stránky mohou vypadat jako originál, ale je ve skutečnosti parodii na to. Tyto jsou většinou neškodné, a jsou výrazněji odlišné od původního, protože většinou nemají zneužít chyby v webovém prohlížeči technologie.

To může také probíhat v souboru hosts . Je možné přesměrovat stránku (y) do jiné IP, které by mohly být falešnou internetových stránkách.

Cross-site scripting

Cross-site scripting (XSS) je metoda narušení WWW stránek využitím bezpečnostních chyb ve skriptech (především neošetřené vstupy). Útočník díky těmto chybám v zabezpečení webové aplikace dokáže do stránek podstrčit svůj vlastní javascriptový kód, což může využít buď pouze k poškození vzhledu stránky, jejímu znefunkčnění anebo dokonce k získávání citlivých údajů návštěvníků stránek, obcházení bezpečnostních prvků aplikace a phishingu.

 Ukázka útoku

 Typ 1

Většinou se označuje jako lokální nebo DOM based. Lze ji využít i na statických stránkách a jde o neošetřené přenesení proměnné z URL adresy do javascriptu. Pro ilustraci si představme že máme html stránku s následujícím kódem:

<SCRIPT>
 var pos=document.URL.indexOf("jmeno=")+6;
 document.write("Ahoj "+document.URL.substring(pos,document.URL.length));
</SCRIPT>

a na stránku vstoupíme přes standardní link

http://URL/stranka.html?jmeno=Alice

stránka standardně vypíše pouze „Ahoj Alice“. Útočník však může link pozměnit na

http://URL/stranka.html?jmeno=<script>alert('Toto je úspěšný XSS útok.');</script>

a tím vykoná zákeřný kód.

Tento vektor útoku (stejně jako u typu 2) stojí a padá na přístupu přes upravenou url a většinou je takto i snadno odhalitelný pomocí prosté logiky. Pokud na stránku přijdete přes normální link, tak se zachová tak jak má.

 Typ 2

Označuje se jako non-persistent nebo reflected. Je postaven na úpravě části URL která se interpretuje do stránky jako její součást, například jako nadpis. Pokud do URL přidáme svůj kód který není před interpretací upraven, tak se stránka v prohlížeči zachová, jako by námi vložený kód byl její součástí. Tato zranitelnost se týká především stránek s generovaným obsahem, pro příklad používáme php a někde ve zdrojovém kódu máme

 <?php echo $_GET['nadpis']; ?>

stačí uživateli podstrčit url upravenou například takto:

http://URL/stranka.php?nadpis=cokoliv<script>alert('Toto je úspěšný XSS útok.');</script>

Tento typ útoku je nejběžnější.

 Typ 3

Je označován jako persistent, stored nebo second-order. Jde o nejnebezpečnější možnost, protože na takto napadené stránky nemusíte vstoupit přes upravený link. Vzniká pokud je obsah stránky generován z databáze. Náš javascript jednoduše vložíme třeba jako součást komentáře - spolu s ním se uloží do databáze a je následně zobrazen všem lidem, kteří si takovýto komentář zobrazí.

Ahoj, super <script>alert('Toto je úspěšný XSS útok.')</script>stránky!

 Obrana

 Na straně serveru

• Při vkládání dat od uživatele do HTML stránky odfiltrovat „nebezpečné“ znaky z uživatelského vstupu resp. je převést na příslušné HTML entity ( < za <, > za > atd.), na což lze použít ad hoc funkce (např. v jazyce PHP je to funkce htmlspecialchars).
• Pokud se jedná sice o textové parametry, ale z omezené množiny hodnot, lze zvážit indexace této množiny a přenášení pouze číselného indexu, který lze před výstupem (podle možností daného skriptovacího jazyka) implicitně přetypovávat na celé číslo.

 Na straně uživatele

Na straně uživatele lze vypnout JavaScript. Je třeba si ale uvědomit, že o zamezení možnosti cross-side scriptingu by se měl postarat skript na straně serveru.

Cross-site request forgery

Cross-site Request Forgery (CSRF nebo také XSRF) je jedna z metod útoku do internetových aplikací (typicky implementovaných skriptovacími jazyky nebo cgi) pracující na bázi neočekávaného resp. nezamýšleného požadavku pro vykonání určité akce v této aplikaci, který ovšem pochází z nelegitimního zdroje. Většinou se nejedná o útok směřující k získání přístupu do aplikace (i když i pro to může být zneužit); spíše využívá (zneužívá) akce uživatelů, kteří jsou k ní již v okamžiku útoku přihlášeni.

 Příklad

Existuje nějaká netriviální internetová aplikace (typu wiki, blog, diskuzní fórum, e-shop, redakční systém, …), která má svou administrační část, přístupnou pouze pro administrátory, a u které útočník zná (nebo dokáže odhadnout) URL adresy (popřípadě i posílané proměnné) pro spuštění akcí určených na změnu (editaci obsahu, smazání, …) jejích objektů (příspěvků na blogu či fóru, článků v redakčním systému či wiki, apod…).

Útočník současně zná (je v kontaktu, nebo dokáže oslovit a přesvědčit) jiného uživatele, který se do této aplikace již přihlásil a operuje v ní s administrátorskými právy. Útočník poté (většinou s využitím tzv. sociálního inženýrství) přiměje tohoto administrátora, aby zobrazil (jím předem připravenou) maligní internetovou stránku, která provede samotný CSRF útok.

Ten spočívá v tom, že součástí této maligní stránky je vyslání požadavku na adresu (popř. kombinaci adresy a proměnných) do zmíněné internetové aplikace, který způsobí změnu určitých záznamů či objektů, které spravuje. Tento požadavek (HTTP Request) může být realizován (pro HTTP metodu GET) přímo v HTML, pomocí značky, u které se specifikuje zdroj (obrázek, rám stránky, …, navíc často pomocí stylů nebo atributů skryté nebo minimalizované, aby si jich původce požadavku nevšimnul), nebo (pro metodu POST) sestavením požadavku ve skriptovacím jazyce při zpracování stránky.

Útok je úspěšný, pokud v okamžiku požadavku na tuto stránku je uživatel, který maligní stránku spustil, do aplikace platně přihlášen a tato aplikace není proti tomuto typu útoku zabezpečena. Skrytý požadavek na editaci nebo smazání objektů v inkriminované aplikaci se tak vykoná, protože aplikace není schopna odlišit, z jakého podnětu požadavek přišel (zda-li z její vlastní administrační stránky nebo právě z CSRF útoku) – tento útok tedy patří do skupiny tzv. „problému zmateného zástupce“ (en:Confused deputy problem), která je charakteristická tím, že strůjcem maligní akce je nikoli útočník, ale legitimně přihlášený uživatel. Změny se projeví, aniž by to tušil a mnohdy zůstanou dlouho nezjištěny.

Útočník nemusí znát, který záznam chce takto nechat nic netušícím administrátorem smazat nebo změnit, přesto v nechráněné aplikaci je schopen způsobit často neopravitelné škody. Méně často se může pokusit nechat spustit požadavek, který žádný objekt nemění, a místo toho zobrazí pro útočníka zajímavé nebo potenciálně zneužitelné informace. Přístupové údaje k jiným účtům mezi ně ale většinou nepatří a konkrétně hesla většina aplikací z pochopitelných důvodů zobrazuje nepředvyplněná a při možnosti jej změnit navíc s podmínkou zadání starého hesla.

 Opatření proti CSRF

• V administrační části internetových aplikací, pro akce, které mažou určité záznamy nebo je jiným způsobem mění, se doporučuje zásadně používat HTTP metodu POST. (To útok CSRF znesnadňuje, ale ještě zcela nevylučuje.)
• Používat autorizační token – tedy náhodně vygenerovaný řetězec pro tuto akci, platící jen pro aktuálního uživatele, ideálně pokaždé (tj. pro každý vygenerovaný formulář) jiné. Typicky skript, starající se o administrační část aplikace, si před zobrazením formuláře vygeneruje tento autorizační token, který si jednak zapamatuje (uloží do session, databáze, …) a současně do onoho formuláře vloží (jako skryté vstupní pole). Při zpracování odeslaných dat pak tuto proměnnou porovnává s předtím uloženou hodnotou. V případě shody může požadavek zpracovat, v případě neshody se zřejmě jedná o pokus o Cross-Site Request Forgery. Autorizační token by neměl být od ničeho odvozený, zcela stačí v podobě (dostatečně velkého) náhodného čísla. Zatímco administrátor jej má v každém nabídnutém formuláři aplikace automaticky předvyplněný, útočník (nezávisle na počtu zaslaných podvrhnutých požadavků) autorizační token není schopen uhodnout.
• Implementace autorizačním tokenem je sama o sobě považována za dostatečné opatření proti CSRF útokům. Nicméně, je více než vhodné používat ji v rámci ostatních bezpečnostních opatřeních, s kterými je možno ji kombinovat (zabezpečení webového serveru, nastavení limitů a přístupových práv, použití SSL/HTTPS nebo HTTP autentizace, zásady pro ukládání citlivých údajů a hesel (např. tzv. password salting, vyžadování starého hesla při jeho změně), ošetřování vstupů od uživatele, stratifikace uživatelských práv, atd.).

SQL injection

SQL injection je technika napadení databázové vrstvy programu vsunutím (odtud „injection“) kódu přes neošetřený vstup a vykonání vlastního, samozřejmě pozměněného, SQL dotazu. Toto nechtěné chování vzniká při propojení aplikační vrstvy s databázovou vrstvou (téměř vždy se totiž jedná o dva různé programy) a zabraňuje se mu pomocí jednoduchého escapování potencionálně nebezpečných znaků.

 SQL injection a web

V klasickém případě je útok na internetové stránky prováděn přes neošetřený formulář, manipulací s URL nebo třeba i podstrčením zákeřně upravené cookie. Bohužel, na internetu je stále velké množství webů, spravovaných převážně nezkušenými programátory, kteří o této technice útoku prostě neví a tuto kritickou chybu opomíjejí.

 Ukázka útoku

Mějme program odesílající dotaz do databáze:

 statement := "SELECT * FROM uzivatele WHERE jmeno = '" + zadaneJmeno + "';"

Pokud však uživatel zadá jako jméno například:

a' or 'b'='b

aplikační program dotaz doplní a odešle databázi ve formě

 statement := "SELECT * FROM uzivatele WHERE jmeno = 'a' or 'b'='b';"

což může zapříčinit přemostění autorizační procedury, protože 'b' = 'b' je vždy pravda.

Pro SQL injection se samozřejmě dají použít všechny dostupné příkazy, pokud by tedy útočník v předešlém příkladě jako jméno zadal

a';DROP TABLE uzivatele; --

vypadal by dotaz při odeslání serveru jako

 statement := "SELECT * FROM uzivatele WHERE jmeno = 'a';DROP TABLE uzivatele; --';"

čímž by smazal celou tabulku uživatelů. Poslední apostrof se pomocí sekvence dvou pomlček stane poznámkou a nemá žádný vliv.

Podobných průniků je samozřejmě celá řada, díky klauzulím UNION a JOIN nejsme ani vázáni na tabulku předepsanou v části FROM a můžeme vypisovat data odkudkoliv z databáze.

 Obrana

 Na straně aplikace

Nejjednodušší obrana spočívá ve vhodné kontrole a úpravě vstupních dat. Prakticky každý skriptovací program s podporou databáze má nějakou vestavěnou funkci pro převedení potenciálně nebezpečných znaků na bezpečnou sekvenci. Tuto funkci je možné použít před vytvořením dotazu.

Například pro Perl

 $query = $sql->prepare(
        "SELECT * FROM uzivatele WHERE jmeno = "
        . $sql->quote($zadaneJmeno)
   );

pro PHP (v příkladu implementace MySQL):

 $sql = "SELECT * FROM uzivatele WHERE jmeno = '"
        . mysql_real_escape_string($zadaneJmeno)."'";
 mysql_query($sql);

pro PHP Oracle:

$stmt = oci_parse($connOci, 'SELECT * FROM LOGIN WHERE jmeno = :login');
oci_bind_by_name($stmt, ':login', $_POST['login']);
oci_execute($stmt);

Obecně řečeno, spolu s tímto je vhodné aplikaci otestovat pro všechny možnosti uživatelského vstupu. Ve vývojové verzi se doporučuje mít nastavenu nízkou úroveň vypisování chybových hlášek a varování (abychom si jich všimnuli a opravili je). V ostré verzi je naopak zvykem vypisování chybových hlášek co nejvíc potlačit (mohly by poskytnout útočníkovi dodatečné informace).

 Na straně databáze

V databázi můžeme útoku zabránit (nebo ho přinejmenším extrémně ztížit) vhodným nastavením práv uživatele, se kterými bude program přistupovat. Málokdy je třeba přímo z aplikační vrstvy mazat tabulky či dokonce databáze, proto stačí povolit jen základní SQL příkazy.

 Případy SQL injection

• 1. listopadu použil jistý student SQL injection, aby pronikl na stránky tchajvanského časopisu o počítačové bezpečnosti.
• 29. června 2007 hacker „znetvořil“ stránku britské pobočky firmy Microsoft. Její databázový systém se stal terčem útoku v lednu následujícího roku, kdy byl spuštěn hromadný útok zneužívající chyby v Microsoft SQL Server na SQL injection a byly nakaženy desítky tisíc počítačů, zejména v Číně. Další, ještě větší vlna útoků, zaměřující se na bezpečnostní díry Microsoft IIS a Microsoft SQL server, proběhla od dubna do srpna 2008 a odhadem zasáhla kolem půl milionu počítačů.
• u případu krádeže informací se 130 miliony čísel platebních karet (který je uváděný jako největší krádež identity vůbec) padl rozsudek 17. srpna 2009 na Američana Alberta Gonzalese a dva nejmenované Rusy.

Mezi (poměrně úzkou) komunitou programátorů, bezpečnostních analytiků a databázových návrhářů se v posledních několika měsících dokonce rozšířil humor, narážející na některé tyto útoky, mezi jinými i SQL injection.

SMS_spoofing

SMS spoofing je relativně nová technologie, která využívá krátkých textových zpráv (SMS), k dispozici na většině mobilních telefonů a osobních digitálních asistentů , kteří pro nastavení se zobrazí zpráva, že přijde z nahrazením původní telefonní číslo (Sender ID) s alfanumerickým textem. Spoofing má oba legitimní použití (nastavení název firmy, ze kterého je zpráva odesílána, nastavit vlastní telefonní číslo, nebo název produktu) a nelegitimní použití (například vydávat jiná osoba, společnost, produkt).

Jak se SMS spoofing provádí

SMS falešného obsahu nastane, když odesílatele manipuluje adresu. Často to je děláno s cílem vydávat se za uživatele, který má potulovali na zahraniční sítě a předkládá zprávy do domácí sítě. Často jsou tyto zprávy adresované do destinací mimo domácí síť - s domácí SMSC podstatě je "unesen" k odesílání zpráv do jiných sítí.

Dopad této činnosti je trojí:

1. Domácí síť může vzniknout terminační poplatky způsobené doručení těchto zpráv k propojení partnerů. To je vyčíslitelná únik výnosů.
2. Tyto zprávy mohou být zájem propojit partnery. Jejich zákazníci se mohou stěžovat na nevyžádaná obchodní sdělení jsou, nebo obsah zpráv může být politicky citlivé. Propojovací partneři mohou hrozit uříznout domácí sítě, pokud nápravu je realizován. Domů předplatitelé budou moci posílat zprávy do těchto sítí.
3. Zatímco podvodníci se obvykle používá falešné identity-posílat zprávy, je zde riziko, že tyto identity mohou odpovídat těm skutečným domovem předplatitelů. Riziko tedy vyplývá, že skutečná účastníků mohou být účtovány za roamingové zprávy, že neposlal. Pokud tato situace nastane, může integritu domovského operátora fakturační proces být ohrožena, což může mít obrovský dopad na značku. To je hlavní máselnice riziko.

Legitimní případy použití pro spoofing SMS patří:

1. Odesílatel vysílá SMS zprávy z on-line počítačové sítě pro menší větší cenová konkurence, a pro snadné zadávání dat z plné velikosti konzole. Musí spoof své vlastní číslo, aby se správně poznat sebe.
2. Odesílatel nemá mobilní telefon, a potřebují posílat SMS z čísla, které mají za předpokladu, že přijímač předem jako prostředek pro aktivaci účtu.

SMS falešného obsahu útok je často poprvé detekována zvýšení počtu chyb SMS setkal během účet-run. Tyto chyby jsou způsobeny falešné identity účastníka. Operátoři mohou reagovat tím, že blokuje různé zdrojové adresy v jejich Gateway-MSCs, ale podvodníci mohou změnit adresy snadno by-pass těchto opatření. Pokud se podvodníkům pohybovat s pomocí zdrojových adres na hlavní propojit partner, může se stát neproveditelné zablokovat tyto adresy, kvůli možnému dopadu na normální propojit služby. 

Legálnost

V roce 2007, Spojené království pojistné sazby regulátor, PhonepayPlus (dříve ICSTIS) dospěl k závěru veřejnou konzultaci o anonymní SMS, ve kterém oni říkali, že oni nebyli odpor k provozování těchto služeb. Nicméně, od roku 2008 PhonePayPlus se zaváděním nových nařízení pro anonymní SMS, které budou vyžadovat anonymní SMS služeb pro odeslání následná-up zprávy pro příjemce o tom, že falešnou SMS byla odeslána na ně, a provozovat stížnosti linku. To je nezákonné v Austrálii.

Chrání uživatele před SMS spoofing

Pokud se uživatel může prokázat, že jejich SMS zasedání byly falešné, měli by se obrátit vymáhání práva a jejich buněčné poskytovatele , kteří by měli být schopni sledovat, kde SMS zprávy byly skutečně odeslán z. Uživatel může také upravit nastavení telefonu tak, aby z povolených čísel je povoleno pouze zprávy. To není vždy efektivní, neboť hackeři mohou být zosobnění uživatele přáteli.

Příklady SMS spoofing

• Zprávy odeslané z Google jsou zasílány s Sender ID "Google".

• Skype odesílá zprávy od svých uživatelů s mobilním číslem, které při registraci. Všimněte si, že když se uživatel pokusí "odpověď" na SMS, může místního systému nebo nemusí povolit odpověď bude zpráva odeslána až po falešné "původu."

• Uživatel, který nemá mobilní telefon se pokusí přihlásit k účtu Foxytag, která vyžaduje SMS z telefonní číslo, které se uživatel zaregistruje se. Dynamicky přiřazené číslo od anonymní služby SMS nebude fungovat, protože uživatel není s ohledem na dynamický číslo v předem zaregistrovat.

Asijská škola Cyber ​​zákonů (Pune) nedávno pokusy v spoofing SMS na národní i mezinárodní úrovni. Oni byli schopni úspěšně spoof SMS zpráv a nutit je vypadat, že přijde z lidí mobilní jiných telefonů. Tito lidé byli pomocí GSM mobilního telefonu na základě služeb v různých částech Indie a dalších asijských i afrických zemí.

Nitesh Dhanjani objevil zabezpečení při odesílání SMS zprávy s falešnou identitou do Twitter . Twitter používá původce SMS k ověření uživatele. Nitesh používá hoaxMail spoof SMS zprávy, a proto by mohl přimět Twitter, abyste mohl psát zprávu o obětech Twitter stránka.

Flachback virus nyní s Twitter C&C

OS X malware rodina Flashback dělá zprávy znovu. Tentokrát antivirus prodejce Intego odhalila novou verzi Flashback, která bude používat Twitter jako velení a řízení kanálu [1]. Malware bude kontrolovat twitter pro každodenní změnu hashtags hledat příkazy.

Dnešní hashtag, # pepbyfadxeoa, již byla silně "zneužit" na twitter. Vzhledem k tomu všechny další příspěvky, není to jasné, zda skutečný příkaz bude zpracován správně bota.

Celkově je kanál Twitter není přesně provedena velmi silně.Například, Intego poukazuje na to, že bota bude používat specifické, ale střídající, uživatelské agenti skrývat. Nicméně některé z těchto uživatelských agentů docela snadné odhalit.Skrývá v očích pracuje pouze pokud jste skutečně snaží splynout, a ne osvětlení se s velkým světlici.

Zatím jsme neviděli žádné z první ruky zprávy o infekci. Pokud někdo přeběhne vzorku, dejte nám vědět. Chtěl bych vyzkoušet, zda Apple XProtect software přidá podpis, nebo pokud existující podpisy pokrytí tohoto jednoho. Apple neustále aktualizovat XProtect podpisy, ale to není vždy, pokud se vztahuje na verzi u jiných výrobců, jak pojmenování není vždy synchronizované.Podle mého sledování XProtect, byl naposledy aktualizován Únor 7th.

ANDROIDOS_FONCYSMS.A

To je AndroidOS malware s backdoor schopností. Klesne soubor, který vytváří spojení IRC, kde se dostává příkazy, což ohrožuje postiženého systému v oblasti bezpečnosti pro uživatele. To je také prémiová služba násilníka, který může vyústit v neoprávněné účtování poplatků za uživatele.

Tato aplikace pro Android zobrazí ikona, která je podobná "Madden NFL" hry. Nicméně, na provedení, to klesne a instaluje další škodlivé složky zobrazí chybu.

Tento trojský kůň může být nainstalovat ručně uživatelem.

Detaily

Tento trojský kůň může být nainstalovat ručně uživatelem.

Poznámky: 

Po instalaci této aplikace pro Android zobrazí ikona, která je podobná "Madden NFL" hry.

Nicméně, na provedení, to klesne a instaluje další škodlivé složky zobrazí chybu se zprávou:

"(0x14) Chyba - není registrovaným aplikace."

Vytváří následující složku a nastaví jeho oprávnění ke čtení, zápis a spouštění pro všechny:

• / Data / data / com.android.bot nebo soubory

To pak extrahuje svých souborů do vytvořené složky:

• header01.png - root aplikace
• footer01.png - IRC bot
• border01.png - prémiová služba násilníka

Chcete-li začít, provede header01.png. Pokud zakořenění je úspěšná, bude to běžet footer01.png, který je IRC bot. Snaží se vytvořit připojení k IRC serveru následující:

• {BLOKOVÁNA}.} {BLOKOVÁNA .196.198

Po připojení se napojuje na kanál # Andros, kde se čeká na příkazy přicházející z dálkového uživatele.

IRC bot provede border01.png .

border01.png je prémiová služba násilníka, který běží na OS Android. Získá umístění uživatele pomocígetSimCountryISO API. Premium číslo a zpráva, že používá lišit v závislosti na lokalitě.

fr (Francie) 
číslo: 81083 
zpráva: ALL

být (Belgie) 
číslo: 3075 
zpráva: CODE

ch (Švýcarsko) 
číslo: 543 
zpráva: gehen SP 300

lu (Lucembursko) 
číslo: 64747 
zpráva: Přístup SP

ca (Kanada) 
číslo: 60999 
zpráva: SP

de (Německo) 
číslo: 63000 
zpráva: SP 462

es (Španělsko) 
číslo: 35024 
zpráva: GOLD

GB (Velká Británie) 
číslo: 60999 
zpráva: SP2

ma (Maroko) 
číslo: 2052 
zpráva: CODE

sl (Sierra Leone) 
číslo: 7604 
zpráva: PASS

ro (Rumunsko) 
číslo: 1339 
zpráva: PASS

ne (Norsko) 
číslo: 2227 
zpráva: PASS

SE (Švédsko) 
číslo: 72225 
zpráva: PASS

us (Spojené státy) 
číslo: 23333 
zpráva: PASS

Je-li vrácená hodnota není jedním z výše uvedených zemí, pošle "WUUT" na 00000 .

Je také blokuje příchozí zprávy pocházející z výše uvedených čísel, pak se připojí na níže uvedené adrese s parametry:

• http:// {} BLOKOVÁNA. {} BLOKOVÁNA .146.102 /? = {sazba pojistného číslo} / / / {} zprávu tělo