Kriptográfia és Adatbiztonság SAML 2.0 mérés

Átírás

1 Kriptográfia és Adatbiztonság SAML 2.0 mérés Módli Hunor Dániel(HHW6Q9) Pázmány Péter Katolikus Egyetem Információs technológiai és Bionikai Kar 219. PC labor

2 Bevezetés A Biztonságellenőrzési jelölőnyelv (Security Assertion Markup Language - SAML) egy XML-alapú OA- SIS szabvány a felhasználó azonosságának és a biztonsági attribútumok információinak kicseréléséhez. A mérés folyamán SAML szabvány által megvalósított single-sign-on (SSO) rendszereket vizsgáltunk. Minden oldalon három különböző esetet szimuláltunk a mérési feladat alapján: Bejelentkezés helyes adatokkal Bejelentkezési kísérlet helytelen felhasználói adatokkal Kijelentkezés Az ügyfélazonosítás során használt protokollok elemzését a Fiddler Packet Analyser szoftverrel végeztük, amely egy man-in-the-middle támadást megvalósító alkalmazás, amellyel egy adott kliens gépről küldött, és fogadott HTTP, és HTTPS csomagokat lehet dekódolni, és elemezni (miután jóváhagytuk hogy a Fiddler által szolgáltatott, nem elfogadott tanúsítványt hagyja figyelmen kívül a számítógép). A Fiddler az elfogott kommunikációt.saz kiterjesztésű állományba menti, melyet így utólag is ki lehet elemezni. Mérő partnerem, Petrovicz Benedek, akinek a gépén végeztük a mérést utólag megtisztította a kimentett.saz állományokat az irreleváns session-öktől, így csak a mérendő információ található meg bennük. 1

3 1. Feladat A feladat leírása: A weboldal vizsgálata A Feladat megvalósítása: 1 Előzetesen megvizsgáltuk az azonosítás folyamatát a KIB 21. ajánlásában. Az azonosítás folyamatát az alábbi ábra mutatja: 1. ábra. Szakrendszer és Ügyfélkapu közötti kommunikáció Bejelentkezés A található Belépés gombra kattintva a böngésző egy HTTP GET metódust küld el a szervernek, mely esetünkben a következő: GET Mivel a magyarorszag.hu-nak a gate.gov.hu az Identity providere (ez az ügyfélkapu), ezért ez a kérés átirányít minket az ügyfélkapus bejelentkezésre. A GET metódus végén szerepló partnerid=mohu a szak rendszer azonosítója, ez jelzi az IDP felé, hogy melyik oldalról kértünk azonosítást. 1 Mellékelt fájlok: Sikeres bejelentkezés: mo_login_good.saz Sikertelen bejelentkezés: mo_login_wrong.saz Kijelentkezés: mo_logout.saz 2

4 Válaszként a szerver egy HTTP/ as OK kódú üzenetet küld, tehát a szerver teljesíti a kérésünket, és az üzenet törzsében meg is kapjuk az oldal forrás kódját. Ezen kívül egy Cookie-t, is beállít melyre a parancs: Set-Cookie: JSESSIONID=90E9BD4C05C AEDA6050A2B97.sso4; Path=/ Ez később a mi session-ünk azonosítójaként fog szolgálni. Ekkor az Ügyfélkapus bejelentkezési képernyőn vagyunk, ahol felhasználónevet, és jelszót megadva azonosíthatjuk magunkat. Az oldal forráskódjából is látszik, hogy felhasználónév, és jelszó beírása után a Belépés gombra kattintva egy POST metódussal fogja elküldeni a kérést a szervernek: <form id="frmuklogin" action="apservlet" method="post">... HTTP GET, és POST metódusok A HTTP Hypertext Transfer Protocol szabvány egy információátviteli protokoll elosztott, kollaboratív, hipermédiás, információs rendszerekhez, melyet a 2616-os RFC ír le. a. A GET, és a POST metódusokat lekérésekre használjuk, általában kliens oldalról a szerver felé. Lényegi különbség, hogy míg a GET metódus az URL-ben küldi az egyes adatmezők értékét, addig a POST a csomagtörzsben teszi ugyanezt. Nem kell képzett biztonságtechnikai szakértőnek lenni ahoz hogy lássuk: miért lehet problémás a GET metódussal autentikációs adatokat küldeni (cachelés, böngészési előzményekben nyoma marad, stb...) Emiatt a GET metódust általában egy oldal tartalmának lekéréséhez, a POST metódust pedig adat küldésre használjuk. A két metódus lényegi különbségeit az alább látható 1. táblázat tartalmazza. a 1. táblázat. My caption GET POST Data will be re-submitted (the browser BACK Harmless should alert the user that the data are button/reload about to be re-submitted) Bookmarked Can be bookmarked Cannot be bookmarked Cached Can be cached Not cached Encoding type application/x-www-form-urlencoded application/x-www-form-urlencodedor multipart/form-data. Use multipart encoding for binary data History Parameters remain in browser history Parameters are not saved in browser history Yes, when sending data, the GET method Restrictions on adds the data to the URL; and the length data length of a URL is limited No restrictions (maximum URL length is 2048 characters) Restrictions on data type Security Only ASCII characters allowed GET is less secure compared to POST because data sent is part of the URL No restrictions. Binary data is also allowed POST is a little safer than GET because the parameters are not stored in browser history or in web server logs Visibility Data is visible to everyone in the URL Data is not displayed in the URL 3

5 2. ábra. Az ügyfélkapus bejelentkezés oldala A Belépés gomb megnyomása után a POST metóduson keresztül elküldi a szervernek a belépési adatainkat. Ezeket a csomagtörzs partnerid=mohu&target=&felhasznalonev=culaboy&jelszo=mostmarjovagy11 sorában találjuk. A 3. ábrán ez látszik a Fiddler-ben is, hogy az üzenet mellé a korábban beállított Cookie adatait, illetve a felhasználónév (culaboy), és jelszó (MostMarJoVagy11) párost is elküldjük a csomagtörzsben (illetve azt, hogy a magyarorszag.hu-ról voltunk átirányítva megjelenik itt is a csomagban). Érdekesség, hogy ezek a személyes adatok mindenféle titkosítás nélkül, egyedül a HTTPS szabvány szerint védett módon kerülnek elküldésre. 3. ábra. A bejelentkezés adatai Válaszként a szervertől egy HTTP/ Moved Temporarily üzenet érkezett. Elsőre rendkívül furcsának tűnhet ez az üzenet, mivel az üzenet törzsében megjelölt Location: URL pont az, ahonnan érkeztünk. Valamint a 302-es üzenet a HTTP szabvány hivatalos ajánlása szerint már nem használandó, helyette POST kérés esetén 303-as parancsal kellene tovább irányítani, de valószínűleg az elavult rendszerek, és böngészők miatt maradt ez így. 4

6 Redirect után egy HTTP/ OK üzenetet küld a szerver, tehát sikerült az autentikáció. Az üzenettörzsben elküldi a céloldal forráskódját a szerver, amit betölt a böngészőnk. A forráskódban lévő <meta http-equiv="refresh" content="3;url=../intersitetransfer?target=&partner=mohu"/> sor miatt 3 mp-en belül át leszünk irányítva a cél címre. A cél címen egy HTTP/ es "InterSiteTransfer" üzenettel átirányít a 4. ábrán látható címre. Ebben a címben lévő lényeges adat a linkben a SAMLart=J5xaw%2FsCgMibaiJEarM05bNtpLV4yFXjVt1smlNQUQu375omueG7Q&TARGET= érték. Ez az a token, amelyet az Identity Provider (esetünkben az Ügyfélkapu) küld a szakrendszer felé (esetünkben magyarorszag.hu). Ez egy ember által értelmezhetetlen BASE64 kódolású üzenet. 4. ábra. A HTTP/ es üzenetben található SALMart érték Erre a szerver küld még egy HTTP/ átirányítást közvetlenük az ugyfelkapu.magyarorszag. hu címre, valamint két Set-Cookie parancsot: Set-Cookie: sso_auth=akccaiwn4nhjme8bpochffcmzuyzql6f6qxtwi6nyga=; Domain=magyarorszag.hu; Path=/; Secure Set-Cookie: JSESSIONID=C99D6F694F91A0AF755D850ABABA3C88.portal1; Path=/; Secure Erre érkezik még egy HTTP/ átirányítás a Location: oldalra. Ez az átirányítás nem része az azonosításnak, valami más funkciót tölt be. Ahogyan a KIB 21. ajánlásában szerepel (1. ábra), eközben a szakrendszer a küldött artifactot leellenőrzi az ügyfélkapuval, és csak úgy ad hozzáférést a szolgáltatáshoz hogyha rendben találta azt, de ez a kommunikáció számunkra láthatatlan. Érdekesség, hogy az artifact ismeretében timeout-ig többször, több eszközről is fel lehet használni. Ezt a laborban ki is próbáltuk, és a SAMLart-ot tartalmazó link segítségével mindenféle autentikáció nélkül be tudtunk jelentkezni másik gépről is a magyarorszag.hu-ra. Ez nyilvánvalóan biztonsági rés, hiszen az artifact "elfogásával" korlátlanul hozzáférhetünk a felhasználó által igénybe vehető szolgáltatásokhoz. 5

7 Bejelentkezés hibás adatokkal Hibás adatok megadásánál a HTTP POST metódus után nem irányítódunk át, hanem újraküldi a bejelentkezési űrlapot, kiegészítve információval, hogy sikertelen volt a bejelentkezésünk. Az alábbi csomagtörzset küldtük el: partnerid=mohu&target=&felhasznalonev=culaboy&jelszo=ezegyrosszjelszo Melyre az alábbi választ kaptuk: 5. ábra. Az újraküldött űrlap HTML kódja Az oldal forráskódjából nem derül ki hogy számolná a próbálkozásokat, így gyakorlatilag próbálkozásos úton is lehet felahsználót törni (habár a folyamatos kommunikáció miatt elég lassú). Kijelentkezés Kijelentkezéskor a magyarorszag.hu-ra a kliens küld egy GET metódus, melyre válaszként egy HTTP/ átirányítás történik a gov.hu/sso/ap/logout?partnerid=mohu&target= címre. Ezt az URL-t lekérve irányítódunk át az IdP-hez, hogy az ügyfélkapun is megtörténjen a kijelentkezés. Ennek a kérésnek a szövege: GET HTTP/1.1 A lekért HTML-ben szintén van egy meta-refresh, mely biztosítja, hogy 3 mp-en belül tovább leszünk irányítva az ügyfélkapus kijelentkezéshez: <meta http-equiv="refresh" content="3;url= mohu_portlet_frame/auth/ssologout"/> Ezután egy 302-es redirect-el megérkezünk a címre, kijelentkezett állapotban. 6

8 2. Feladat A feladat leírása: A weboldal vizsgálata A Feladat megvalósítása: 2 Bejelentkezés Ennél az oldalnál hasonlóan történik a bejelentkezés mint a magyarorszag.hu-n, azzal a különbséggel, hogy itt a bejelentkezési oldalnál előre kapunk egy generált azonosítót SAMLRequest néven. Ez egy jó hosszú, BASE64 kódolású üzenet, amely tartalmaz minden adatot a kérésről. Az átirányításnál a POST metódussal küldjük az adatot az IdP felé (jelen esetben a hu/proxy/saml/authnrequest?lang=hu oldal) 6. ábra. A POST metódus tartalma Itt az IdP már a HTTP szabvány ajánlásának megfelelő HTTP/ See Other üzenettel irányít tovább arra az oldalra, ahol kiválaszthatjuk az autentikáció módját. Itt az ügyfélkapu lehetőséget választva (egyéb opciók itt az eszemélyi, illetve telefonos azonosítás) egy POST metódussal elküldjük a kérelmünket a szervernek, amely egy átirányítási oldalon keresztül továbbít az idp.gov.hu oldalra. Itt az űrlapot kitöltve a bejelentkezési adatokat egy POST metódussal küldjük el a szervernek, itt szintén a csomag törzsben utazik a felhasználó név, és jelszó páros, amint az alábbi képen is látható. 7. ábra. A POST metódus tartalma 2 Mellékelt fájlok: Sikeres bejelentkezés: ugyseged_login_good.saz Sikertelen bejelentkezés: ugyseged_login_wrong.saz Kijelentkezés: ugyseged_logout.saz 7

9 Erre a szervertől kapunk egy SAMLResponse választ, mely elméletileg a további azonosító adatainkat tartalmazza. Azonban a SAMLResponse értékét akárhogyan is próbálkoztam nem sikerül BASE64-ről, a korábbiakban tapasztalt, értelmezhető XML faszerkezetbe átvarázsolni. Az eleje még jól látszik, aztán valamiért elcsúszik, és nem találtam sem online, sem az általam telepített szoftverekben megoldást a problémára. 8. ábra. A dekódolt BASE64 üzenet A bejelentkezési folyamat lezárásaként a SAML 2.0-ás szabványnak megfelelően egy POST metódussal átküldjük a megadott átirányítási oldalra a titkosított belépési adatokat, mely jelen esetben a oldal. Ez pedig egy HTTP/ Found üzenettel küld a bejelentkezett felületre, itt zárul a bejelentkezési folyamat. Bejelentkezés hibás adatokkal Hasonlóan mint a esetében hibás bejelentkezéskor újra letöltődik a bejelentkező oldal, (a hibás bejelentkezésre utaló kiegészítéssel) és nem kapunk átirányítást. A különbség az, hogy itt egy számláló mutatja közben, hogy az öt lehetőségből eddig hányszor próbálkoztál. 9. ábra. A belépési felület az első próbálkozás után 8

10 Ha mind az öt próbálkozást elhibáztuk akkor egy HTTP/ Found üzenettel továbbküld a oldalra. 10. ábra. A 302-es Redirect tartalma 11. ábra. A hibás bejelentkezés után feldobott oldal Érdekesség, hogy miután átirányított a Nyilvántartó Error oldalára, ha visszaléünk az idp.gov.hu-ra a böngészőben az alábbi kép fogad minket: 12. ábra. A szerint valami szörnyű dolog történt. Kijelentkezés A Kilépés gombra kattintva elküldésre kerül egy POST metódus az alábbi címre: POST HTTP/1.1 valamint elküldésre kerül a korábbi SAMLRequest kódunk is, és beállítódik az alábbi Cookie: Set-Cookie: IDS_SSO_ID=""; Expires=Thu, 01-Jan :00:10 GMT; Path=/proxy; Secure; HttpOnly Erre érkezik egy automatikus SAMLResponse válasz, mellyel törlődnek a korábban beállított Cookiek is. Egy HTTP/ OK kíséretében megkapjuk az oldal forráskódját, majd egy HTTP/ Found átirányítással átkerülünk a címre, kijelentkezett állapotban. 9

11 3. Feladat A feladat leírása: A weboldal vizsgálata A Feladat megvalósítása: 3 A PPKE belső weboldalaihoz SAML 2.0 alapon épülő Shibboleth SSO rendszeren keresztül tudunk hozzájutni. A laboron a Wiki oldalhoz való hozzáférést vizsgáltuk. 13. ábra. Az SAML 2.0 bejelentkezési folyamat A bejelentkezés folyamatát a 13. ábrán is látható folyamatábrán is nyomon lehet követni, az egyes lépéseket a jegyzőkönyvben is nyomon fogom követni. Jelen esetben a felosztás: Service Provider: PPKE Wiki oldala, User Agent: a böngészőm, Identity Provider: a PPKE identity provider rendszere (idp.ppke.hu). Bejelentkezés Amikor beütjük a wiki.itk.ppke.hu URL-t a böngészőnk elküld egy GET metódust a címre GET HTTP/1.1 3 Mellékelt fájlok: Sikeres bejelentkezés: wiki_login_good.saz Sikertelen bejelentkezés: wiki_login_wrong.saz Kijelentkezés: wiki_logout.saz Ezek már nem a Petrovicz Benedek által generált.saz fájlok, hanem az én általam, a későbbi vizsgálódáskor felvett fájlok. 10

12 Ezen kívül beállításra kerül egy _shibstate_ azonosítójú Cookie is _shibstate_1f627747=https%3a%2f%2fwiki.itk.ppke.hu%2ftwiki%2fbin%2fview%2fppke Ez a shibstate Cookie, ahogy a neve is mutatja, a Shibboleth bejelentkezési állapotot mutatja. Életútja a böngésző bezárása után véget ér, mint ahogy a 15.ábrán látható is. Maga a shibstate Cookie egy korábbi belépés során lett a böngészőben eltárolva. A 14. ábra. Az első GET metódus Cookie-ban szereplő 1f kulcs az SAML requestben lévő Relay State paraméter értéke. A A Ez a Cookie azonban nem frissül vagy törlődik, hanem egy új Cookie jön létre a bejelentkezett állapot tárolására, viszont a régi, 1f kulcsú megmarad a böngészőben, és mint a későbbiekben látni fogjuk minen kéréskor el is küldi a szervernek. Mindkét Cookie a session végéig él (Böngésző bezárása). 15. ábra. A shibstate Cookie a Chromeban kérésre érkezik egy HTTP/ Found üzenet, mely átirányítást tartalmaz a Location: oldalra. Ez a belső Wiki kezdőoldala, melyet autentikáció után látni fogunk. Az átirányított oldal lekérése a GET HTTP/1.1 kéréssel történik meg. Erre a szerver válasza egy HTTP/ OK üzenet, mely lényegi része egy Set-Cookie parancs, és egy POST-metódussal küldött HTML form, mely az egyetemi IdP SSO feldolgozó rendszerére irányít át. 16. ábra. A kérésünkre kapott válasz a szervertől Látszik hogy új shibstate Cookiet állított be f113dd99 értékkel, mellyel azonosítja a jelenlegi login folyamathoz tartozó állapotot. A HTML form tartalma pedig egy JavaScript segítségével, betöltés után automatikusan elküldött űrlap: 11

13 17. ábra. Az űrlap tartalma Itt megjelenik a RelayState paraméter, méghozzá a fentebb említett, új Cookie-val (f113dd99), valamint egy SAMLRequest mező, mely egy BASE64 kódolású üzenetet tartalmaz. Az üzenet dekódolva: 18. ábra. A SAMLRequest mező dekódolt tartalma Ebből ki lehet olvasni a lényeges részeket: AssertionConsumerServiceURL=" a Wiki SP SAML 2.0 feldolgozó rendszere, az IdP ide irányít vissza az autorizáció után. Destination=" rendszere az IdP SSP feldolgozó ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST": ez mutatja, hogy az IdP az SAML választ egy HTTP-POST metódusban fogja visszaküldeni az SP-nek. <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion"> Kibocsájtóként pedig a Wiki Shibboleth rendszere van megadva. Az átirányított űrlap-ot egy POST metódussal küldük el a szerver felé: POST HTTP/1.1 Az üzenetben még érdekesség a két Cookie tartalma is: Cookie: JSESSIONID=1vk4z19llwap0y3b4o6r0a51q; _idp_authn_lc_key=51e6d80ad21c5a981b646843ac9d4f7d54db8e8cb65a b6e267d4c8f9 Ez a két Cookie szintén korábban az IdP-hez beállított Cookie. 12

14 Az üzenet törzsében találhatóak a fent részletezett paraméterek az SAMLRequest mezőben. Erre érkezik egy HTTP/ Found üzenet: 19. ábra. A szerver válaszüzenete Az átirányítás címe pedig a cím. A válaszban kapunk még egy Set-Cookie parancsot, ekkor a _idp_authn_lc_key Cookie értéke felülíródik az új munkamenetre. A böngészőnk ezután lekéri a hivatkozott Authorization Engine oldalt egy GET HTTP/1.1 parancsal. A GET metódushoz mellékeli a Cookie-kat is, az új értékekkel: JSESSIONID=1vk4z19llwap0y3b4o6r0a51q; _idp_authn_lc_key=1dd7afee4fe22ddb0cc28fac67f9ede04188d9afe1c502b79c1b b38a7 Válaszként kapunk egy HTTP/ Found üzenetet a szervertől, amely átirányít a idp.ppke.hu:443/idp/authn/userpassword oldalra. Itt fogjuk tudni felhasználói azonosító, és jelszó segítségével azonosítani magunkat az IdP-nek. Ezután a böngészőnk egy GET HTTP/1.1 parancsal lekéri a bejelentkező oldalt. Válaszként egy HTTP/ OK üzenetben meg is kapja a kér oldal HTML kódját. 20. ábra. A bejelentkezési oldal forráskódja Az üzenet törzsrészében található kommentből (20.ábra) kiderül hogy SAML PasswordProtectedTransporttal fog történni az azonosítás. A képen látjuk, hogy az űrlap egy POST metódussal fogja küldeni az adatainkat. Ezt meg is teszi a böngészőnk, az alábbi POST üzenet formájában: 13

15 21. ábra. Az elküldött felhasználói adatok Látszik, hogy a felhasználónév, és jelszó a POST metódus csomagtörzsében utazik: j_username=modhu&j_password=itkpwtest_33 Válaszként a szervertől egy HTTP/ Found üzenet érkezik a címre, mely az IdP SAML SSO kezelő rendszere. Emellett egy Set-Cookie: _idp_session=?tky... parancsal beállításra kerül egy Cookie, mely az IdP-n futó processt azonosítja. A böngésző elküldi egy GET metódussal a megadott címre az _idp_session Cookie-t. A kérésre jön egy HTTP/ OK válasz: 22. ábra. A szerver válasza A 22. ábrán látszik, hogy a válaszban a szerver küldött egy Set-Cookie parancsot, mellyel elküldi az IdP Session Cookie-t. Ekkor az _idp_authn_lc_key Cookie törlésre kerül, ekkorra ugyanis az autentikáció befejeződött. A letöltött HTML-ben van egy form, ami automatikusan továbbküld minket a Wiki oldalára. <form action=" SAML2/POST" method="post"> A Formnak két paramétere van: name="relaystate" value="cookie:f113dd99" name="samlresponse" value="pd94bwwgdmvyc2lv..." Ennek az SAMLResponse-nak a BASE64 dekódolt tartalma: 14

16 23. ábra. A SAMLResponse dekódolt tartalma Ebből a SALMResponse mezőből kiolvasható nagyon sok adat: kezdve a cél címtől (Wiki SAML kezelő felülete), a kibocsátó IdP címén át, digitális aláíráson át, InResponseTo mezőig, ami a korábban küldött SAMLRequest ID attribútuma. A formot egy POST metódussal küldi el a böngésző: POST HTTP/1.1 Erre érkezik egy HTTP/ Found üzenet, mely átirányít a Wiki főoldalára, valamint beállítja a Cookie-kat. Kijelentkezés Mivel a PPKE SSO rendszerben nincsen ilyen funkció, ezért ezt nem tudtuk kipróbálni. Bejelentkezés hibás adatokkal Hasonló analógiával, mint az előző két feladatban amikor megpróbáltunk hibás adatokkal belépni akkor a felhasználói adatokat küldő POST metódusra érkező válaszban jött ugyanaz a form, kiegészítve egy Sikertelen belépésre figyelmeztető sorral. Mint a magyarorszag.hu esetén itt sem számolta hogy hányszor próbálkoztunk sikertelenül. 15

17 24. ábra. A hibás bejelentkezés sorral kiegészült HTML kód 16