Prüfungsprotokoll/Braindump mündl. Prüfung vom 2012-03-13

Alle Angaben ohne Gewähr.
„Angewandte IT-Sicherheit“ AppITSec WS 2011/2012, Vorlesung & Uebung
Prüfung oder benoteter Leistungsnachweis zu IT-Sicherheit (5 ECTS)
Tennenlohe, Am Wolfsmantel 46, mittlerer Eingang, innen hängen Wegweiser-Zettel; siehe auch:

• http://www1.informatik.uni-erlangen.de/reach-us.html
• http://www1.informatik.uni-erlangen.de/filepool/tennenlohe-anreise-deutsch-komplett.pdf
• http://www1.informatik.uni-erlangen.de/courses/show
• https://fsi.informatik.uni-erlangen.de/forum/thread/8231-Angewandte-IT-Sicherheit-WS2011-12

Dauer: ~ 30 min.
Prüfer: Prof. Felix Freiling
Beisitz: (nicht ganz sicher, aber wahrsch.) Michael Spreitzenbarth
Papier + Stift bereitgestellt

• Ich verwende manchmal englische Wörter aus Bequemlichkeit.
• „P:“ Frage/Erklärung vom „P“rüfer
• „S:“ Antwort/Erklärung vom „S“tudent
• „note:“ persönl. Hinweise, nicht aus Prüfungs-Gespräch

P: (sicherheitshalber) Prüfung für „IT-Sicherheit“ korrekt?
schon mal mündl. Prüfung gehabt?
Wenn Frage nicht verstanden, nochmal nachfragen.
Wenn Wissenslücke bei best. Frage/Gebiet, zwar mögl. alles relevante das man weiß sagen, aber dann lieber sagen, wenn einem nichts mehr einfällt, statt lange rumzuraten.
Dann gehts schnell zur nächsten Frage, bei der man evtl. mehr punkten kann.

P: Mit welchem Gebiet beginnen?
S: Softwaresicherheit
P: Haben versch. Schwachstellen kennengelernt. Welche hat ihnen am besten gefallen?
S: Stack-Overflow
P: Klassiker. Erklären, was ist ein Stack-Overflow, wie kann Angreifer das nutzen?
S: Prinzipiell Versuch, mit schlecht geprüften Eingaben/Parametern z.B. durch Buffer-Overflow Stack-Frame zerstören, dabei RIP überschreiben mit Speicher-Adresse von eigenem Code im Heap/Stack.
Bei return aus aktueller Funktion wird dann zu Adresse in RIP gesprungen.
P: Skizze auf Papier.
S: Zeichnung vereinfachter Stack (max. bis 0)

Erklärung: je nach Architektur, hier x86
|max.(oben)|...|params|RIP|old ebp-addr.|local vars|buf|...|...|0(unten)|
                                        ^                  ^
                                     new ebp              esp
Angreifer kann buf z.B. mit "strcpy" ohne "n" befüllen
	=> mit bel. Daten "local vars" überschreiben, dann noch "old ebp-addr." z.B. bei 32-bit-Addr. 4 Byte  
Dann RIP überschreiben => Pfeil irgendwo unten in Adr.-Raum
	note: hier könnte man noch genauer sein, wenn "attacker code" in HEAP => unter esp, in STACK => über esp

P: …(überlegt nächste Frage)
S: noch was eingefallen:

• wenn „attacker code“ auf Stack ⇒ Stack ausführbar machen z.B. gcc flag
• evtl. Address-Space-Randomization ausschalten
• evtl. canaries(stack-guards) berücksichtigen

P: Warum Stack-Overflow schwerer mit Address-Layout-Randomization?
S: genau weiß ichs nicht, aber prinzipiell werden Adressen/virtuelle Adressräume von Prozessen wohl zufällig verteilt und nicht etwa linear z.B. nach PID.
P: hmm ungefähr. Wichtig v.A., dass Adressen vom selben Programm auf eigenem Rechner nicht gleich sind auf anderem Rechner.

note: TODO:
gilt das nur fürs Neu-compilen(=> Adress-Änderungen bei compiler-assembler-linker)
oder auch auch für fertige binaries(=> Adress-Änderungen bei loader)?
      //Anmerkung: ASLR setzt den Start des Stacksegments (und auch Heap (mmap)) bei **jedem** ausfuehren eines Programmes zufaellig (im Rahmen der Moeglichkeiten, bei Linux ca. 19bit Entropy). Der Sinn dahinter ist das man somit nicht weiss wo der Stack liegt und man in seinem Exploit nicht einfach mit einem Stackoverflow Code in den Stack schreiben kann und dann in diesen Code springen kann. Waehrend ohne ASLR man ja einfach einmal herausfinden muss wo der Stack und somit auch der Exploit-Code liegt und man dann einfach die Ruecksprungaddresse mit dieser **statischen** Addresse ueberschreiben kann. Mit ASLR liegt der Exploit-Code immer an rand() und somit kann man dort nicht mehr (so einfach) hin springen.//\\

P: Was wenn Intel damals Architektur anders entworfen hätte? z.B. RIP am unteren Ende des Stack-Frames oder Schreibrichtung Speicher von max.2min.
Hätte man Problem, in aktueller Funktion eigenen RIP zu überschreiben?
S: Prinzipiell kann man rel. zum ebp/esp alle Adressen auf Stack ansprechen.
(war etwas verwirrt, hab gezögert und nochmal nachgefragt und nicht gleich gerafft worauf Prüfer hinaus wollte)
P: Wie würde man denn buf bei normaler Architektur konkret überschreiben?
Schreiben sie mal so ein minimal-sicheres Programm hin. (note: gemeint war, Programm anfällig für Stack-Overflow)
S:

int main(... argv, ... argc){
	... buf[const_int];
	strcpy(argv[1], buf);
}

P: genau. Wie könnte man aus strcpy heraus RIP von strcpy überschreiben, wenn z.B. andere Schreibrichtung? buf wird ja an strcpy übergeben. (hint hint :P)
S: achso, wenn buf call-by-ref übergeben wird, kann buf den RIP von der anderen Seite aus überschreiben.

note: egal wie genau eine Architektur jetzt schreibt oder den Stack-Frame zusammensetzt,
man muss v.A. den belegten Speicher z.B. durch lokale Var. kennen
und das ABI der Architektur (z.B. CDECL c calling convention wird vom gcc verwendet)
z.B. Reihenfolge die Parameter-Ablage, Stack-Frame-Aufbau, ...

P: Haben sie Erfahrung aus der Praxis, sind Stack-Overflows immer noch relevant?
S: Hmm nicht sicher, aber ich glaub die LSASS-Schwachstelle in einer der Windows-DLLs war einer?
note: und afaik war auch der vom Sapphire genutzte Exploit im MS-SQL-Server einer

P: Wenn sie so eine Schwachstelle entdeckt haben, wie können sie das zu Geld machen?
S: Mehrere Wege.
Erstmal grob entscheiden ob auf „Angebot“-Seite oder „Nachfrage“-Seite. „Angebot“-Seite ⇒ mittels der Sicherheitslücke z.B. wertvolle Daten sammeln (z.B. username+password) und an jemand verkaufen, der daraus Geld macht.

note: hab blöde Beispiele genommen.
Alles nur zur Sammlung von wertvollen Informationen/Daten.
Andere Bsp. wär DDoS mit nem Bot-Netz zur Erpressung "anbieten".
In der Vorlesung steht dazu bestimmt noch mehr.

Mit ner vulnerability ist man erst mal auf der „Angebot“-Seite, aber man kann sie ja auch ohne Vermittler selbst zu Geld machen. Aber spezialisierter ist es wahrsch. effektiver.
„Nachfrage“-Seite: Hmm, kann ich hier mit der Sicherheitslücke Geld machen? ja, doch z.B. wenn ich von der „Angebot“-Seite wertvolle Daten kaufe
und dann mittels einer Sicherheitslücke z.B. Geld von Konten mit ausgespähtem Login an mein schweizer Konto überweise.

note: wie gesagt, das passt so noch nicht.

P: Ja, das war jetzt schon eher in die Richtung, was sie mit der Schwachstelle anfangen. Wenn sie nur Schachstelle entdecken, gibts Parteien, die ihnen für diese Information Geld geben würden?
S: Ja, z.B. das SW-Unternehmen, von dem die SW stammt. Oder Agenturen, die Informationen über solche Exploits sammeln und an ihre Kunden verkaufen z.B. SW-Unternehmen, Regierungen oder wichtige Persönlichkeiten. Gibt auch Agenturen, die extra solche Exploits suchen.
P: Ja, das war jetzt sozusagen die „legale“ Seite.

note: Erpressung hatte ich nicht explizit erwähnt

Aber wichtige Persönlichkeiten oder Privat-Leute wollen doch eher wissen, wie sie sich schützen und nicht wie der Exploit geht?
S: Natürlich kaufen das auch Leute um illegales zu tun.
P: Genau, also z.B. Kriminelle aber auch Geheimdienst-Mitarbeiter

P: Wir haben auch Gesetzgebung angeschaut. Haben sie Lieblings-Paragraph z.B. „Hacker-Paragraph“ und können sie den Paragraph nennen und was ungefähr drinsteht?
S: Leider nicht so genau. Aber grundsätzl. wichtig war Unterscheidung, dass man sich nicht nur strafbar mach, wenn man eine Schwachstelle wirklich ausnutzt oder eine Malware wirklich anwendet,
sonder schon wenn man das vorbereitet/plant, die Malware entwickelt und Malware/Exploit verbreitet. Weiß nicht obs jetzt im „Hacker-Paragraph“ war oder irgendwo anders.
P: OK. Aber wenn sie jetzt z.B. eine Sicherheitslücke finden und an so eine „Agentur“ weiterverkaufen, ist das für sie intuitiv legal oder nicht und ist das evtl. nach dem Wortlaut eines Gesetztes strafbar?
S: Hmm, also im Graubereich ist es auf jeden Fall. Intuitiv wärs für mich schon eher illegal. Aber nach Wortlaut eines Paragraphen weiß ich nicht.

P: Bereich Authentifikation, …

• Authentizität einer Nachricht m
• gemeinsames Geheimnis k
• Haben Message Authentication Codes kennen gelernt.
• Was ist das und wofür ist das gut?

S: kryptographischer Hash abhäng. von symm. Schlüssel und Nachrichten-Inhalt. Unklar ob immer mit oder ohne plain-text von m. Glaub mit.
P: Mal aufschreiben. Warum wird authenticity gewährleistet?
S:

A->B
A authentisiert sich bei B
Tupel ( m, h_k(m) )
h_k() abhäng. von k
	nicht invertierbar
	nicht fälschbar z.B. hard/weak collision resistance
=> authentisch, wenn nur A & B "k" kennen  
Zusätzlich integrity von m.

P: Was, wenn nicht h_k() verwenden sondern h()?
A: am einfachsten z.B. k konkatenieren mit h(k||m)
P: Zwar authenticity, aber noch replay-anfällig. Schutz-maßnahme?
A: Mehrere Mögl., prinzipiell muss man MAC zustands-abhäng. machen.

B passiv, A wählt Zufallszahl r, schickt h_k(r||m)

=> B muss Buch-führen über verwendete r  
Problem: r können sich theoret. irgendwann wiederholen.

B aktiv ⇒ challenge-respone-Protokoll

B wählt Zufallszahl r, merkt sich r, schickt r an A
A schickt h_k(r||m)
=> kein Buch-führen  
Problem wiederholende Zufallszahlen auch eig. gelöst.
	note: FALSCH !! B hat zwar jetzt kein Problem mehr, wenn r sich zufällig mal wiederholen sollte.
	Aber es ist theoret. aber SEHR unwahrsch. mögl.,
	dass Angreifer z.B. mit MITM bei einem wiederholten r ein altes h_k(r||m) "replay"t.
	Aber klappt nur wenn A nicht nur "h_k(r||m)" schickt, sondern "( r, h_k(r||m) )", also r in plain-text.
	Noch unwahrsch. ist dann noch, dass m beim Replay für B grade in den Kommunikations-Kontext passt.

B passiv, A schickt Hash-Kette.

Problem: Replay zwar nicht innerhalb der Kette mögl.
	Aber replay der gesamten Kette mögl.

P: Moment. Hash-Kette mal genau erklären.
S: Zuerst irgendwie vertraulicher Austausch neues gemeinsames Geheimnis h_n

note: h_n = h( h_n-1 )

A→B A hat komplette Hash-Kette ausgerechnet. Hash-Werte einfach rekursiv verschachtelt berechnen. note: das hat ich nicht mehr so genau im Kopf. Siehe pdf S.6f

A rechnet ZUERST Hash-Kette aus.
DANACH Senden von h_n an B.

P: Nachfrage (weil zu schwammig. Weiß nicht mehr was genau, was gefragt wurde.)
P: Genau, also als Einmal-Passwörter.
Und wenn sich B die Kette merkt (note: oder wars nur h_n oder h_1? Würde evtl. schon ausreichen), ist auch Replay von B erkennbar

note: und Änderung der Sequenz-Reihenfolge

S: Mit der rekursiven Verschachtelung kann man auch MAC-Ketten berechnen (siehe pdf S.13)

note: dann ist replay erkennbar und Manipulation des Inhalts oder der Reihenfolge einer Message-Sequenz.
	Vorteil ist hier auch, dass die Kette (theoret.) beliebig lang sein kann.

P: Das hatten wir aber nicht in der Vorlesung dran?
S: Nein , nur in der Übungs-Lösung.
P: Zwar authenticity und integrity der Nachricht gegeben, aber immer noch gemeinsames Geheimnis k. Um auch das Problem zu lösen, braucht man z.B. Zertifikate. Erklären bitte …
S: rein mathematisch:

encr_CApriv( h( ID_A || key_Apub ) )
asymm. Schlüssel
CA Certification Authority
hier wird "ID_A || key_Apub" verschlüsselt, man kann aber auch andere Daten so verschlüsseln z.B. Nachricht m
note: z.B. Signaturen vom e-mails etc.

P: Vor- & Nachteile von Zertifikaten gegenüber Ansätzen mit symm. Verschlüsselung?
S:

• Vorteile: kein shared key
• Nachteile: man muss CA vertrauen
  

Problem: A und B vertrauen verschiedenen CAs, z.B. lokale CAs die für vertrauenswürdig und kompetent halten
Lösung:

• verteilt ⇒ Problem: CAs müssen sich n² Zertifikate ausstellen
  
• zentral ⇒ eine zentrale root-CA ⇒ Problem: Flaschenhals
  

⇒ hierarchisch root-CAs in PKI, trotzdem Problem, dass CAs evtl. vertrauens-unwürdig werden können.
⇒ versch. Auswirkungen auf Zertifikate

note: siehe "revoked" Zertifikate (vergleiche Abfrage-möglichkeiten vergangener Zertifikats-Status bei OCSP und SCVP)\\ 
note: noch ein wichtiger Nachteil:
Man braucht key_CApub (zur Prüfung de Zertifikats mit asymm. Verschlüsselung)
Durch Veröffentlichung leichtere Erkennbarkeit gefälschter öffentl. Schlüssel.  (siehe pdf S.5)

Bewertung/Note

Im Bereich 1.0 bis 3.0 Sehr zufrieden

Feedback

Im Detail/Technischen teilweise sehr gut, teilweise v.A. bei der Übersicht/Einordnung der Techniken zu viel handwaving. Grad bei Nachteilen von Zertifikaten hätt ich noch mehr rausholen können (siehe note oben). note: war oft unsicher/unklar/spekulativ bei Erklärungen und hab ab und zu Fragen-irrelevante oder eher spekulative Bemerkungen eingeworfen.