Pokračovat ve čtení »]]> Také se Vám po poslední aktualizaci rozbil Lastpass?

Lastpass měl poslední dobou máslo na hlavě, kdy opravoval každý týden nějakou zásadní chybu. Je dobře, že to aspoň přiznali a konali.

Nicméně zřejmě v tom fofru neměli moc času na testování a tak se stalo, že zatímco verze

4.1.45.84 (z 23.3.2017)  na  Win32bit / Chrome 49.0.2623 je funkční bez problémů,

tak následující verze 4.1.45.87 (z 3.4.2017) už ne

s touto verzí totiž .js hází chybu

onloadwff.js: Uncaught SyntaxError: Identifier ‘is_watermark‘ has already been declared

Tato chyba zdá se je jen ve starém chromu 49 (poslední verze pro XP), u novějších verzí jsem na tuto chybu nenarazil a zdají se být funkční.

Řešením je buď použít novější verzi chrome a nebo  – pokud třeba máte windows XP a nemůžete chrome upgradovat –  nezbývá než Lastpass dočasně downgradovat ( a doufat, že to autoři s vydáním příští verze snad opraví )

Pokud se rozhodnete pro to druhé řešení, tak zde naleznete upravený (viz níže) Lastpass verzi 4.1.45.84 ke stažení

abyste zabránili  automatické aktualizaci pluginu na novější verze, tak

1.obsah archivu rozbalte do složky,

2. poté aktivujte v chrome://extensions vývojářský režim a

3. zvolte načíst rozbalené rozšíření

Tímto způsobem zajistíte, že se Lastpass nebude již nadále aktualizovat a zůstane ve Vašem Chromu zakonzervován v této poslední funkční verzi.

Nebo si také můžete stáhnout originální neupravený archiv Lastpass 4.1.45.84 a přepsat jím obsah složky aktuální verze , např

%USERPROFILE%\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions\hdokiejnpimakedhajhdlcegeplioah\4.1.45.87_0

samozřejmě, pokud bude zlobit v budoucnu nějaká novější verze, stačí obsah složky nahradit, ale přitom zachovat  číslo nejnovější verze v názvu této složky

Toto je však nutno s každým dalším vydáním nové verze zopakovat, neboť se rozšíření automaticky aktualizují.

Pokračovat ve čtení »]]> Při dění kolem Bashe v nedávné aféře jsem byl donucen aktualizovat všechny svoje nainsatalované distribuce od Mandrivy po Ubuntu. Ty novější  (např Ubuntu 12.04 LTS a samozřejmě nejnovější 14 ) šly aktualizovat automaticky z repozitářů.

Ale u některých postarších (konkrétně třeba Mandriva 2010, Ubuntu 13.04) už jejich tvůrcům na bezpečnosti asi tolik nezáleží , takže nezbylo než v těchto případech kompilovat ze zdrojového kódu 

Pominu fakt, že patche přibývaly téměř každým dnem po dobu zhruba dvou týdnů. Když už tahle zranitelnost vydržela více jak 10 let, potom myslím, že ten týden zdržení na vydání jedné kumulativní záplaty by se asi dal vydržet ale budiž…

Zaujalo mne však, že ani po aplikaci všech záplat jsem se s verzí 3.2.57 nedostal přes všech 5 testů bez ztráty květinky. Zkrátka mi na jednom stroji zranitelnost 7187 (nested loops) stále zůstává a nejde opravit.

Toto jsem vyřešil tak, že jsem vyměnil shelly a místo bashe mám teď pro všechny defaultně sh. Jediný účet s bashem používám jenom já pro správu. Mohl jsem si to dovolit, protože se jedná o backend server bez lokálního přístupu běžných uživatelů .

Nicméně, zjistil jsem, že se mezi sebou verze BASHe poměrně zásadně liší i mezi dvěma minoritními verzemi, konkrétně neopatchovaná 3.2.48 vs 3.2.57:

Totiž původní neopatchovaná verze byla benevolentní co se týče deklarace funkcí, zatímco opatchovaná je v tomto striktní. Vzhledem k povaze objevených zranitelností by se to dalo očekávat, nicméně pro nepřipravené to znamená komplikace a nepříjemnosti spojené s laděním nutným po opatchování.

Skripty odladěné na přechozí verzi po opatchování začaly najednou kravit a vyhazovat chyby, které jsem nikdy předtím nezaznamenal. Poněkud mne zarazilo že to nedělaly ani tak moje vlastní skripty, ale často i poměrně zásadní součásti systému, zejména rd (init) skritpy.

Zjistil jsem, že zatímco původní neopatchovaná verze bashe umožňovala deklarovat funkci minimálně třemi způsoby:

standartně:

function function_name {
command…
}

 zkráceně ( C++ like ):

function_name () {
command…
}

a navíc také tolerovala sémanticky chybný zápis ve formě:

function function_name () { 
command… 
} 

což už ale opatchovaná striktní verze nezkousne !!  

Bylo nutné tyto nestandartní zápisy ručně opravit. 

Nejsem odborník na nastavení bashe, možná že by se dala pomocí nějaké proměné nastavit citlivost parseru na takto chybné zápisy. Vzhledem k aféře se zranitelností shellshock si ale spíš myslím, že zpřísnění a “striktní mód” je na místě. Myslím, že jinak než úpravou kódu se těmto nepříjemnostem asi nelze vyhnout.

Pokračovat ve čtení »]]> XSS znamená cross-site scripting. Je to velmi často používaná metoda útoku, kdy útočník propašuje škodlivý kód do PHP či jiné aplikace. Docílí tak toho, že uživatel či správce, který aplikaci použije, aniž by to spozoroval spustí kód z jiného umístění.

Tato metoda předpokládá, že buď má útočník přístup pro zápis do nějaké části (souboru) aplikace (špatné zabezpečení, bezpečností díra, chyba v kódu) a injektuje tak odkaz např. do css.

Nebo je tam tento backdoor už od začátku a třeba několik měsíců o sobě nedá vědět, dokud se útočník nerozhodne útok provést (samozřejmě – to se nás netýká, my stahujeme všechny pluginy pro wordpress z ověřených zdrojů a kontrolujeme všechny řádky jejich kódu!)

Asi nejčastější případ je, že se útočníkovi povede tento škodlivý kód dostat do dat, které se cílené osobě zobrazují. Toto je možné provést libovolnou akcí, která předpokládá zobrazení infikovaných dat v prohlížeči administrátora či osoby, na níž je útok veden.

Asi nebude problém nalézt nějakou akci uživatele, jež vyžaduje zobrazení v prohlížeči např. administrátora – takové přidání nového příspěvku do diskuze, zadání nové objednávky v e-shopu, žádost zadaná přes kontaktní formulář, a spousta dalších jiných akcí toto předpokládá.

Je to velmi jednoduché – útočníkovi stačí najít neošetřené textové či jiné uživatelské vstupy, přes které krom standardního textu projdou také znaky <> :/”

schválně si zkuste, kolik diskuzních fór či e-shopů dovolí registrovat uživatele s adresou dejme tomu

Tonda Novak

<script src=”http://www.bouska.biz/public/xsstest.js”></script>

Praha 1

(Můžete si vyzkoušet – soubor xsstest.js z příkladu v případě spuštění vyvolá popup okno s varováním.)

Samozřejmě, že toto ještě neznamená, že potenciálně škodlivý skript xsstest.js se skutečně SPUSTÍ

Pokud programátor odvedl svou práci v přijatelné kvalitě, budou buď tagy zcela vypuštěny a nebo budou převedeny opisem  na neškodný textový řetězec, který nezpůsobí spuštění tohoto kódu ale pouze zobrazení uvedeného textu. Text pak např. místo znaku  < obsahuje řetězec &lt který prohlížeč interpretuje jako text a nikoliv jako začátek tagu. Filtrování je možno provézt minimálně na dvou místech: při přijímání dat z formuláře a nebo až při jejich zobrazování v pohledu. Důsledný programátor použije pro jistotu filtrování na obou místech.

Pokud však programátor byl lempl, tak se filtrování neprovede, data se v nezměněné podobě uloží a při dalším zobrazení se prohlížeči pošlou opět v nefiltrované podobě.

Tak schválně… kolik běžně používaných diskuzních fór, CMS, ERP, seznamek,  bazarů, eshopů a jiných běžně dostupných aplikací nefiltruje data a dovolí Vám registrovat se s výše uvedenou adresou (přezdívkou, poznámkou, vzkazem pro administrátora)

Tak to by bylo pro tentokrát vše, v příštím dílu si povíme, jak může vlastně škodit ten škodlivý kód.