Archive for the ‘Security’ Category

Startcom SSL cert importálása IIS alá

Friday, April 3rd, 2015

A Startcom SSL-lel ingyen lehet teljesen valid certificate-eket generálni. A generálás kimenete viszont nem egy Windwos által fogyasztható cert pár lesz, hanem egy cert kulcs nélkül és külön egy kulcs fájl.

Itt leírják, hogy lehet ezt az IIS által is ehetővé alakítani, a lényeg:

openssl pkcs12 -export -in foo.crt -inkey foo.key -out foo.p12

.NET fejtörő 6. – megoldás

Friday, February 27th, 2015

Feladat.

Nincs mit írnom a megoldásról, Varga Tamás kolléga (ezek köszönet érte) annyira részletesen, alaposan kielemezte a témát a kommentek között, hogy ennél én csak kevesebbet tudnék írni, övé a szó, olvassátok.

.NET fejtörő 4. – megoldás

Saturday, February 14th, 2015

Kérdés: miért nem jó, ha az ASP.NET Machine Key-emet Random.NextBytes()-szal generálom?

A Machine Key-t alapban viewstate validálásra használja az ASP.NET. HMAC algoritmussal csinál egy hasht, amihez a Machine Key-t mint kulcsot is felhasználja. Ez a kevésbé problémás dolog. Ami sokkal veszettebb, hogy amikor beléptetünk valakit az ASP.NET forms security-vel, akkor a beléptetett felhasználót azonosító adatot ezzel a Machine Key-jel titkosítják. Ha valaki megismeri ezt a kulcsot, akkor tud generálni kamu kukit, amibe azt a user id-t ír be, amit csak akar. Azaz meg tud személyesíteni másokat. Ebből aztán lesz spoofing, vagy akár elevation of privilege. Magyarul senki nem szeretné, ha bárki más beléphetne a nevében egy védett website-on. Például az internetes bankjába.

Szóval, talán most már érthető, a Machine Key-t nem szeretnénk, ha bárki megszerezné vagy kitalálná. Megszerezni csak a site feltörésével lehet, és admin jogokkal, tegyük fel ez nem történt meg. Ha azonban a véletlen sorozat generátorunk kiszámítható, akkor más is ugyanazzal az algoritmussal tud generálni egy olyan kulcsot, amit én is generáltam. És már jönnek is be más nevében.

A .NET Random pszeudo-random generátor, azonos seed-del mindig ugyanaz a sorozat jön ki belőle. Azt mondjátok de én ravasz vagyok, és beadom a DateTime.Now.Ticket neki inputként, az úgysem tudja a támadó. Nem tudja, de pörgetni ő is tudja ezt a számot addig, amíg ki nem találja a megfelelő seedet.

Mi a megoldás? Olyan random generátor kell, ami teljesen kiszámíthatatlan. Pl. a termikus zaj digitalizálva tökéletesen jó erre a célra. Ha ilyen modul nincs a gépben, akkor a Windows megpróbál valami nagyon randommal kijönni, például összerakva olyan vad perf counter értékeket, mint a proci ventilátor sebessége és egyebek.

A lényeg, hogy ha cripto szinten random érték kell, akkor az RNGCryptoServiceProvider típust kell használni erre a célra.

Egyébként meg IIS 7.5-től machine key-t tud generálni az IIS Manager GUI is. :)

HashCat

Sunday, January 18th, 2015

Kipróbáltam a GPU alapú HashCatet egy erős desktop gépen. A 6 karakteres, csak kisbetűs SHA1-gyel salt nélkül hashelt jelszavakat brute force módon kb. 1mp alatt töri meg. Ha még hozzávettem számokat a végére, xxxxxx12, azt 1 perc alatt törte meg.
Durva, MD5-ből 5 milliárdot tör meg 1 mp alatt. SHA1-ből is milliárd felett.

TDD emlékeztető.

XSS web security apróságok

Sunday, October 18th, 2009

Óriási a témakör, két infómorzsa:

AntiXSS, nem házibarkács ellenőrzés (tudomásom szerint MS is ezt használja belül).

HttpOnly cookie.

Hacktivity előadásom

Tuesday, September 15th, 2009

Hétvégén lesz a Hacktivity konferencia, ahol NEM arról fogok beszélni, ami ki van írva.
Gál Tamással ketten kaptunk 45 percet, amiben GT a VPN Windows7/R2 új alternatíváiról beszél, én pedig arról, hogy egy akkora cég, mint az MS hogyan képes felzárkózni a hekkerek generálta biztonsági kihíváshoz. Az előadásom fele érdekességekkel, történetekkel lesz tele, belső infók, mit tesz az ms a jobb kódminőség érdekében, a másik felében pedig konkrét példákat mutatok be, amelyek demonstrálják, hogy a különböző támadási típusok esetén (privilege escalation, stb.) hogyan zárkóztak fel a termékek, mint a Windowsok vagy az IIS.
Szeretettel várok mindenkit, aki ráér hétvégén hekkerkedni.

Az IIS7 secu mágia titka: Service SID

Monday, August 4th, 2008

Az IIS7-ben megoldották, hogy hiába egy account alatt fut sok worker processz, akkor SEM tudják egymás védett fájljait olvasni. Így el lehet szigetelni a webappokat annak ELLENÉRE, hogy egy account alatt futnak (még ha nem is a javasolt konfig hosztereknek). De hogy a csudába? Eddig nem tudtam, de most megtaláltam a választ: Service SID.

“Service SIDs protect access to resources owned by a particular service, but by default services still have access to all the objects that the user account in which they run can access. For example, a service running in the Local Service account might not be able to access resources created by another service running as Local Service in a different process that has protected its objects with permissions referencing a service SID, however, it can still read and write any objects to which Local Service (and any groups to which Local Service belongs, like the Service group) has permissions.

Windows Vista therefore introduces a new restricted service type called a write-restricted service that permits a service write access only to objects accessible to its service SID, the Everyone group, and the SID assigned to the logon session. To accomplish this, it uses restricted SIDs, a SID type introduced back in Windows 2000. When the process opening an object is a write-restricted service, the access-check algorithm changes so that a SID that has not been assigned to a process in both restricted and unrestricted forms cannot be used to grant the process write access to an object. ”

Már csak az nem vili, hogy ezt hogyan használják fel az IIS wp-ek esetén, azok ugyanis nem szervizek. Ha egyszer megtalálom a választ, leírom.

Script Elevation PowerToys for Windows Vista

Monday, February 18th, 2008

Hogy én ezt eddig nem láttam. Pedig jó az UAC ellen. :)

Vista WIC piszkálgatása

Monday, October 29th, 2007

Aki nem tudja mi ez, itt nézhet utána.

Nézegetni a perzisztált IC-t:
accesschk.exe -v c:\Users\zsolt.soczo\AppData

c:\Users\zsolt.soczo\AppData\Local
Medium Mandatory Level (Default) [No-Write-Up]
c:\Users\zsolt.soczo\AppData\LocalLow
Low Mandatory Level [No-Write-Up]

Látható, hogy a AppData\LocalLow-hoz van joga a Low integrity levelű folyamatoknak is, így az IE protected mode-jában futó Addineknek is.

Registryre egy példa:

accesschk.exe -vk “HKEY_CURRENT_USER\Software\
Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\S-1-5-21-1912844993-3
366795750-3477756003-1000\Software”

HKCU\Software\Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\S-1-5-2
1-1912844993-3366795750-3477756003-1000\Software
Low Mandatory Level [No-Write-Up]

A WIC jogokat fájlrendszerben állítani a icacls képes.
Ennek hibáit küszöböli ki a chml.
Processzek WIC-ét a Process Explorer mutatja meg.
Registry WIC állító warét még nem láttam, ha valaki tud ilyet, please. Addig is, programból állítom.

UPDATE: SQL Injection? – NEM

Saturday, October 27th, 2007

http://www.cegtudor.hu/Alkategoria.aspx?varos=%C3%89rd&alkategoriaid=232&alkategorianev=kis%20%C3%A9s%20nagyker

Kimenet:
Input string was not in a correct format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.FormatException: Input string was not in a correct format.

Source Error:

Line 28: mySqlCommand2.CommandText = “UPDATE kategoria SET latogatok = latogatok + 1 WHERE (kategoriaid LIKE @kategoriaid);”;
Line 29: mySqlCommand2.Parameters.Add(“@kategoriaid”, SqlDbType.Int);
Line 30: mySqlCommand2.Parameters[“@kategoriaid”].Value = Convert.ToInt32(LabelKid.Text);
Line 31: mySqlCommand2.ExecuteNonQuery();
Line 32: mySqlConnection2.Close();

Fura, mik vannak még a mai világban. Persze, mivel a paraméter int, nem egyszerű a dolog, de valószínűleg a többi rész is így van programozva.

UPDATE: baromságot beszéltem. Paraméteres a lekérdezés, teljesen jól van megcsinálva, így nem lehet injektálni. Elnézést, hogy pellengérre állítottam, szólok az ikreknek, hogy adjanak több időt aludni, addig is, nem blogolok több hülyeséget. :) Sorry.

Egy, ami nem szép, hogy debug módban van a kód, és a részletes hibaüzenetek látszanak kifelé. Ez is kiindulási alap lehet egy hacker részére.

Obfuscation + strong name == feltörésbiztos program?

Thursday, August 16th, 2007

Nem hiszem, hogy volna ember a szakmában, akinek az astalavista neve ismeretlen volna (akinek az, az most úgyis megnézi googlelel :).
Mi a helyzet a managed kódok feltörésével? Az összezagyváló programok nehezítik a feltörést? A strong name megvéd a törés ellen?

Nem és nem. Érdemes megnézni ezt a két cikket.

Főleg az első tanulságos, a második annak való, aki azt hiszi a strong name véd az assembly módosítás ellen.

Privbar IE-hez és Explorerhez

Friday, July 6th, 2007

Ha valaki rendszeresen dolgozik sok felhasználóval, annak must have. Régi, de ügyes eszköz, mellyel látszik, admin futtatja-e az adott explorer példányt.

Web.config olvasás medium trust esetén

Thursday, July 5th, 2007

Internetszolgáltatók shared hosting esetén általában medium trustra állítják be a webappokat, így azok nem tudják szétbabrálni a gépet, az nt secu mellé még a .NET CAS secu is besegít.
Néha ez gondot okoz, pl. a log4net se tudja kiolvasni a konfigját, mert a CAS megakadályozza ebben. Pedig ez nem olyan vészes dolog.

ASP.NET 2.0-ban már meg lehet mondani, hogy egy szekció olvasása okozzon-e CAS Demandot, magyarul, kell-e hozzá erősebb jog, vagy sem. Erről szól a konfig szekció requirePermission attributuma. A háttérben ez a ConfigurationPermission új 2.0-s permissionre épít. A reflector analyze funkciójával megnézve látható, hogy a BaseConfigurationRecord.CheckPermissionAllowed metódus intézi el a kérdést:

[source:c#]
private void CheckPermissionAllowed(string configKey, bool requirePermission, bool isTrustedWithoutAptca)
{
if (requirePermission)
{
try
{
UnrestrictedConfigPermission.Demand();
}
catch (SecurityException exception)
{
throw new SecurityException(SR.GetString(“ConfigurationPermission_Denied”, new object[] { configKey }), exception);
}
}

}
[/source]

Spc és pvk cert import a cert store-ba

Tuesday, June 26th, 2007

Ha ezekben a fájlokban laknak az aláíráshoz szükséges kulcsok, akkor ez a kis program segíthet az importban, mert a sima certificate guik nem tudják a fenti formátumú fájlokat importálni.

Power Userből Administrator

Friday, June 22nd, 2007

Mark Russinovich cikke, érdekes.

Michael Howard Crypto review makrója

Friday, June 15th, 2007

A jóemberre figyelni kell, okosakat mond. Többek között neki köszönhető, hogy pl. az IIS6-ban nem volt még kritikus hiba a kiadása óta. Ez kibaszott nagy dolog, apacs ide, apacs oda.
Ő a cég secu expertje. Lsd. Writing Secure Code.
No, írt egy egyszerű kis makrót, ami rákeres a VS-be betöltött doksikban a bűnös szavakra, amelyeknek nem kellene ott lennie, mert elavultak vagy nem biztonságosak: CALG_DES, BCRYPT_RC2_ALGORITHM, stb.

A makró code review-khoz készült, egyszerűen végigkeresi a forráskódokat a beteg szavakra, és a Task Listába berakja a talált potenciálisan problémás pontokat. Nem egy atomkód, nem egy PreFast, de az ötlet nem rossz: szedjük össze a könnyen azonosítható, gyakran rosszul használt kóddarabkákat, és keressünk rájuk. Pár percet segíthet a kódátnézésben.

Nyilván managed kódban FxCop szabályt lehetne erre írni.

Default ACLs on Windows Event Logs

Tuesday, April 24th, 2007

A devportálon kérdeztek egyet, és ennek kapcsán találtam meg ezt a bejegyzést, ahol leírják, melyik event log ág milyen ACL-ekkel rendelkezik alapban, még hasznos lehet.

Vista zárolt admin account

Monday, April 23rd, 2007

Ha valakinek annyi esze van, hogy kiveszi magát az admin csoportból, majd elfelejti az administrator account jelszavát, és azzal kilockolja az egyetlen admin accountot (illetve már eleve is ki van, by default), akkor melege lesz. :)

Szerencsére safe módban a lockolt admin ellenére is be lehet lépni.

Vista Protected mode

Friday, November 10th, 2006

Huncut dolog ez az IE7 védett mód, illetve a mögötte levő technológiák (csak Vistán, XP-n nem).

Ha egy process Integrity Levelje mondjuk 100, pl. egy protected módban futó IE7-ben futó kódé ennyi, akkor az hiába ír ki OutputDebugStringgel valamit, nem látszik a DebugView-ban, mert a debugview 200-as szinten fut. Minden user processz, amit az explorer indít alapban ezen a szinten fut, mert a child processzek öröklik a szülő integrity leveljét.

Nem tudom az OutputDebugString illetve a DebugView belül hogyan működik (pont most jól jött volna a DebugView forráskódja…), de a jelek szerint messagekkel, mert pont azokat blokkolják az integrity levelekben különböző processzek között.

Ezért ha Low Integrity alatt futó folyamat OutputDebugStringjét akarom megnézni, akkor Low-ban indítom el a Debugview-t. De hogyan? A korábbi cikkben van egy kis kódrészlet, ami megmutatja hogyan kell Low-ban elindítani egy új processzt. Az ott található kódot beraktam egy kis console appban, így LI ize.exe-vel máris bármit el tudok indítani low integrity levelen.
Pontosan a következőket befolyásolja a protected mód a User Interface Privilege Isolation (UIPI)-re építve:

A lower privilege process cannot:

  • Perform a window handle validation of higher process privilege.
  • SendMessage or PostMessage to higher privilege application windows. These application programming interfaces (APIs) return success but silently drop the window message.
  • Use thread hooks to attach to a higher privilege process.
  • Use Journal hooks to monitor a higher privilege process.
  • Perform dynamic link library (DLL)–injection to a higher privilege process.

With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels.

  • Desktop window, which actually owns the screen surface
  • Desktop heap read-only shared memory
  • Global atom table
  • Clipboard

Szóval a clipboard még oszott, szép is lenne, nem lehetne másolni az IE-ből pl. notepadba kopipasztával.

Ez úgy néz ki, hogy ha létrehozol pl. egy megnevezett mutexet egy 200-as szálban, és azt el akarod érni egy 100-as integrity levelű kódból, akkor access denied-ot kapsz. Azért, mert ha nincs ACL az erőforráson, akkor azt úgy értelmezi a Vista, mitha egy 200 vagy e fölöttieket beengedő ACL lenne rajta (részben írtam már erről).
Csak úgy férhet hozzá a 100-as szál a 200-as által létrehozott globális erőforráshoz, ha az erősebb szál kézzel rárak egy olyan ACL-t, ami beengedi a 100-asokat. De miféle ACL ez, hisz tudjuk, hogy csak DACL van, ami Józsinak ad read jogot mondjuk egy file esetén, vagy az SACL, ami az auditok igényét tárolja. Nos, az SACL-t bővítették ki, az Integrity leveleket itt tárolják.

Szopatós a Vista, beleköp több ponton az appok életébe, de jól teszi, végre látszik, hogy komolyan vették a secut az msnél. Persze, a Windows 2003 az XP SP2 már jól láthatóan ebbe az irányba ment el, de most befoltoztak olyan arhitekturális likat is, mint amilyen a mindenki küldhet mindenkinek üzenetből fakadt.

Ja, és még egy tapasztalat. Low, azaz 100-as Integrity level esetén virtualizálják a file és reg hozzáférést is, ezért számít, hogy ha neked csak read jog kell valamihez, akkor tényleg azt kérj, ne read write-ot. Gyakori, hogy az ember lazán lekér egy all accesses handle-t, pedig csak read kellett volna. Az ilyen akciók könnyen büntivel végzik Vistában. Még jobban észnél kell lenni programozáskor, ez a secu ára. De legalább precízebb munkára kényszerít.

SQL Server 2005 titkosított objektumok visszafejtése

Tuesday, September 26th, 2006

Nemrég a TFS tárolt eljárásai között kellett kicsit szétnéznem, de azok titkosítva voltak. Ez igen kellemetlen, nem szeretem az ilyet. Ezért visszafejtettem őket, az alábbi scripttel (nem ide a blogba raktam a kódot, mert itt még nincs fenn a kódformázó komponensem). Eredetileg itt találtam meg a kódot, csak nem volt teljesen korrekt benne pár oszlopnév a végleges server verzióhoz.

Gonoszul nem írtam bele a tudástáras cikkbe, de a példa csak DAC-ról működik, simán elindítva nem talál egy rendszertáblát. Aki nem tudja mi az a DAC, az ne kísérletezzen vele. :)