September 2009 - Posts

Ukoliko ste zainteresovani za jednodnevni kurs Windows Server hardeninga, javite se na email: office{at}netsec.rs ili ostavite komentar.

Teme:

  • role
  • servisi
  • network security
  • registry settings
  • audit policy
  • patching
  • dozvole
  • UAC i MIC

 

Više o kursu na:
http://www.netsec.rs

Juče oko 11h pre podne, albanska hakerska grupa pod imenom KHG je defaceovala sajt B92. Mirror možete videti ovde.
Sajt je ubrzo vraćen u normalu, ali detalji napada nisu poznati.
Inače, sajt  B92 je nažalost poznat po brojnim bezbednosnim propustima, čak postoje forumi na kojima se može videti istorija ranjivosti nekoliko godina unazad sa sve SQL injection propustima koji i dalje funkcionišu, preuzetim shadow fajlovima sa servera i slično.  Pored ostalih, i kolega Ivan i ja smo ih nekoliko puta upozoravali na očigledne "rupe" u sistemu, neke su čak i zakrpljene, ali redovno bi izostao bar kurtoazni mejl sa magičnom, nama Srbima prilično nepoznatom rečju - hvala. U ostalom, kad može Yahoo tako da se ponaša, zašto ne bi i B92 :)

Kolege developeri, obratite paznju na:

http://blogs.msdn.com/ace_team/archive/2009/09/17/anti-xss-library-v3-1-released.aspx

 

Da ne bi bilo:

xss

Pozdrav!

 

.

Laurent Gaffié je otkrio gorenavedeni propust u SMB2.0 NEGOTIATE PROTOCOL REQUEST-u i okarakterisao ga kao  Remote B.S.O.D. Međutim postoje indicije da je u pitanju RCE, a ne ‘samo’ BSOD.

Neverovatno je u celoj priči to što Microsoft očigledno nije kvalitetno odradio fuzzing svog proizvoda i to protokola koji inače ima čitavu istoriju bolesti. Prilično sam razočaran.

 

Više o tome na:
http://g-laurent.blogspot.com/2009/09/windows-vista7-smb20-negotiate-protocol.html

 

Hvala Nenadu Vijatovu (http://blog.vijatov.com/) na informaciji.

 

[!] EDIT: Što se tiče Win7 izgleda da je ranjiv samo RC, a ne i RTM.

[!] EDIT II: Ko ima TMG u produkciji, bezbedan je k’o polarni medved u kavezu :)
http://blogs.technet.com/isablog/archive/2009/09/10/forefront-tmg-network-inspection-system-gets-its-first-0-day-signature-release.aspx

Za spajanje više binarnih fajlova u jedan fajl, uglavnom koristimo neki od zgodnih GUI alata dostupnih na Internetu. Priznajem da do danas nisam znao da to isto može da se izvede i direktno iz CMD-a:

 

copy /b *.avi  JedanVelikiFajl.avi

Pre nekoliko dana sam sa kolegom imao nekonstruktivnu raspravu na temu CDP u root (self-signed) sertifikatu - da ili ne?

 

cdp

 

 

 

 

CRL Distribution Point (CDP) je ekstenzija koja omogućava pronalažanje CRL listi od strane klijenata (aplikacija) u toku provere validnosti sertifikata. Certificate Revocation List (CRL) sadrži spisak sertifikata povučenih iz opticaja i taj spisak, odnosno sama CRL lista mora biti digitalno potpisana od strane CA servera da bi joj klijenti verovali.

Po preporukama Microsofta, root sertifikat ne treba da sadži CDP. Međutim, kao što znamo, Microsoft nije jedini igrač na terenu, pa prema tome neko može sa punim pravom da primeti da ga ni najmanje ne interesuju preporuke iz Redmonda.

Dakle, treba nam fundamentalniji pristup problemu da bi smo objasnili gore navedenu dilemu i u krajnjoj liniji stavove Microsofta po ovom pitanju. U tom cilju, posegnuću za dva načina objašnjavanja istog pitanja, tj. zašto root cert ne treba da sadrži CDP.

 

 

 

 

1. Logika

  • Root CA server je koren cele PKI infrastrukture, te iz toga sledi da iznad njega nema nikoga ko bi mogao da povuče njegov sertifikat iz opticaja i da ga ubaci u CRL listu, te nema potrebe da root cert sadrži CDP lokaciju kao putokaz do CRL liste na kojoj je možda objavljeno da je povučen iz opticaja.
  • Provera self-signed CRL liste u odnosu na self-signed sertifikat je besmislena u bezbednosnom pogledu jer ukoliko neko uspe da dođe do root ključeva može da nastavi da piše šta hoće u CRL i ne postoji način da se to proveri kod nekog autoriteta iznad (Bog je jedini autoritet iznad self-signed  sertifikata, ali mislim da on ne radi support za PKI :) )
  • Root CA server (možda) može da povuče svoj sopstveni sertifikat iz opticaja i da ga upiše u CRL listu koju sam objavljuje, ali onda dolazimo do sledećeg problema:
    • Ukoliko sam uspeo da root sertifikat upišem u CRL, to znači da isti već nije validan, kako ću onda da ga koristim da bih potpisao datu CRL? Da li mogu da koristim nevalidni sertifikat za potpisivanje CRL kojoj treba da se veruje? To će celu CRL učiniti nevalidnom, samim tim sertifikat će i dalje biti validan (ili možda neće :) )?
    • Kada bih uspeo da objavim  CRL potpisanu sertifikatom koji je na spisku iste CRL kao nevažeći, kako će reagovati klijenti  - razne aplikacije, email klijenti, browseri različitih vendora?
      • Prihvatiće CRL kao validnu i neće više verovati onome ko je potpisao?
      • Odbaciće CRL kao nevalidnu i nastaviće da veruju root sertifikatu?
      • Aplikacija će krahirati? (ovo je verovatno najbolja i najbezbedija opcija pod uslovom da to ne dovodi do drugih problema tipa BoF i slično)

Da se pozovem i na Microsoft:
http://technet.microsoft.com/en-us/library/cc780454%28WS.10%29.aspx

“A root CA certificate should have an empty CRL distribution point because the CRL distribution point is defined by the certificate issuer. Since the roots certificate issuer is the root CA, there is no value in including a CRL distribution point for the root CA. In addition, some applications may detect an invalid certificate chain if the root certificate has a CRL distribution point extension set.”

 

 

2. RFC 3280

Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile

<quote>

...the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates)  satisfies the following conditions:

(a)  for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1;
(b)  certificate 1 is issued by the trust anchor;
(c)  certificate n is the certificate to be validated; and
(d)  for all x in {1, ..., n}, the certificate was valid at the time in question.

   When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

</quote>

 

U prevodu, self-signed sertifikat (root cert) se ne proverava jer nema u odnosu na šta da se proveri. RFC ne kaže eksplicitno da to nije moguće izvesti, ali ako pogledate gornji algoritam videćete da path validation počinje/završava se sa brojam 1, gde u tački (b) piše da je to: certificate 1 is issued by the trust anchor, a ne sam self-signed cert.
Dakle, možda i može ali nije po RFC-u.

Zamena/Povlačenje Root sertifikata iz bilo kog razloga je (bar kod Microsofta, ispravite me ako grešim) zapravo zamena PKI infrastrukture.

 

 

Reference:

http://www.ietf.org/rfc/rfc3280.txt 

http://www.microsoft.com/pki

http://www.imc.org/ietf-pkix/old-archive-02/msg02465.html

http://www.amazon.com/Windows-Server-Certificate-Security-PRO-Other/dp/0735625166

 

Vrlo sam rad čuti vaše komentare na ovu temu.

Hvala i pozz!

https://blogs.apache.org/infra/entry/apache_org_downtime_initial_report