Lieber Zuschauer, dieser Untertitel wurde automatisch generiert von YouTube und dementsprechend (sehr) fehlerhaft. Wenn du kannst, hilf uns bitte gute Untertitel zu erstellen: https://c3subtitles.de/talk/2399 Danke!
diesen t geht über logrotten eine
Sicherheitslücke die gefunden werde beim
Log rotate Wolfgang hwagner ist research
engineer in Cyber Security Research
teamost Institute of
Technology wir werden gleich
verschiedene Szenarien erleuchtet
bekommen wie Log rotate auf eine
gefährliche Art und Weise konfiguriert
werden kann viel
Spaß hallo und herzlich Willkommen zu
lockrotten not the
bug und ich werde euch heute ein
spannendes Feature oder ein spannendes
Verhalten von locrodate
zeigen für alle die locrate nicht
kennen locrate ist ein Tool für Unix
artige
Betriebssysteme das lckfiles managed so
dass die lockfiles nicht zu groß werden
und die Festplatte zumüllen Loog rotate
rotiert dabei diese loogfiles und löscht
dann immer nach einer bestimmten Zeit
eine gewisse Anzahl die Logs können
anhand der Größe rotiert werden aber
auch anhand von einer bestimmten Periode
einmal am Tag oder täglich wöchentlich
monatlich und so weiter was viele nicht
wissen jedoch ist dass wenn man es nicht
richtig verwendet kann es auch eine
rootell geben
2018 beim 35
C3 gab es eine ein wundervolles CTF wo
man wo eine Challenge war dass man Lock
rotate dass man eine Race conondition
gegen locrotate gewinnt und dabei war es
so dass man lockrotate als
unprivilegier unprivilegierter Benutzer
ausführen konnte als Rud das heißt es
war quasi sudo oder so und dabei
versuchen konnte dass lockrotate einfach
eine Flag
ausspuckt dabei kam mir aber die Idee
dass ich diesen Exploit der hier ja in
einem unrealistischen Szenario ist weil
auf normalen Systemen kann man lockrate
nicht ausführen als rot manuell ständig
tausend Mal hintereinander
öfters deswegen ist mir die Idee
gekommen diesen Exploit in irgendeiner
Form stabil zu machen sass wenn
lockrotate automatisch einmal pro Tag
läuft
man das ausnutzen kann wir reden hier
von ein sogenannten time of check to
time of use Exploit oder
vulnerability wo quasi loogrotate sich
ein ein pile checkt und bis es dann
dieses File dann benutzt vergeht eine
bestimmte Zeit wo Angreifer bestimmte
Dinge mit dem PIL machen können in der
Zwischenzeit oder mit dem
Directory und Loot ist
das heißt lockotate ist von Haus aus
nicht verwundbar erst wenn man es falsch
verwendet und es wird eine privilege
escalation wenn man es schafft diese
diesen Fehler
auszunutzen wie funktioniert loogoten
jetzt lockate läuft einmal pro Tag s wir
einmal pro Tag als rot mitrob gestartet
und prüft das
fil diesesile ist unter Kontrolle von
einem Angreifer bzw nicht das File
sondern das Log Directory und nicht
einal das logdory selbst sondern das Log
Directory das Directory über dem Log
Directory also hier in unserem Fall hat
haben unsere
Angreifer die Möglichkeit Temp zu
beschreiben und können dadurch einfach
das Log dieses logdory
austauschen so jetzt nach unserem Check
können die Angreifer einfach
templock austauschen durch einen simlink
und der simlink zeigt dann einfach auf
ein auf ein Directory z.B etc B
completion und der nchste schr wäre wenn
dann log rotate herkommt und das Logfile
erstellt und die Benuter ändert oder bzw
den Owner ändert von diesem log file
dann das File nicht unter
tempog verändert sondern unter etc B
completion
D wo ein Angreifer dann oder wo unsere
Angreifer dann einen payout
reinschreiben können da loogrotate ja
das ch durchgeführt
hat etc B completion die wird dann
aufgerufen oder wird immer dann
aufgerufen wenn sich ein ein Benutzer
anmeldet am System und wenn der Payload
so aussieht
D dass er prüft ob der Benutzer root ist
kann er gezielt eine root Shell als
reversell starten das schaut dann in dem
Fall aus root logt sich ein und
automatisch wird eine reverse Shell zu
den Angreifern
aufgebaut und die Angreifer sind im
System nun habe ich versucht den Fehler
zu beheben in irgendeiner Form und habe
ein P request ein mal aufgemacht und
einfach einmal ein issue aufgemacht und
das das Problem angesprochen dass wir
hier jetzt einen stabilen Exploit gegen
locrate haben und nachdem mein fix zum
einen das Problem nicht gelöst hat zum
anderen ein Memory leag geschaffen hat
war die Gesprächsbasis nicht zu meinem
Vorteil aber nichtsdestotrotz die
Entwickler meinten ja wir haben da jetzt
ein Konfigurationsproblem und wir
sollten das einfach in die Dokumentation
schreiben und aufnehmen dass möglichst
die Leute wenn sie wenn sie
loogrotate so verwenden dass es in einem
Benutzerverzeichnis rodert
dass man dann einfach die sudirektive
verwendet so dass lockrate mit mit mit
niedrigen Privilegien ausgeführt wird
also quasi nicht wirklich nicht wirklich
ein
Fehler wenn ich jetzt sag nicht wirklich
ein Fehler meine ich nicht wirklich ein
Security nicht wirklich ein Security
Problem jetzt bin ich noch mal
zurückgegangen und habe mir das Problem
noch mal angeschaut ist es wirklich so
dass man die Verantwortung auf die
Benutzer schieben kann ist es wirklich
so wenn es wirklich so einfach ist
dann ist es ja vielleicht okay aber ich
habe mehrere Szenarien gefunden die
nicht sehr offensichtlich sind dass man
hier lockradate
gefährlich
verwendet als erstes Beispiel möchte ich
hier mal zeigen dass zum dass auch wenn
create nicht im in der Konfiguration
drin ist man mit compress
ähnliches Verhalten hat das heißt das
Slink wird gemacht äh neues Logfile wird
zwar nicht erstellt aber es wird das
alte Kf logfil einfach komprimiert und
damit wird wieder ein neues File
erstellt und wir haben hier das gleiche
Problem nur mit kompress ST statt
create ein weiteres Szenario wäre wenn
wir zwar owner und Group root hätten am
Log Directory und auch am log file aber
bei beiden einfach ACS in Verwendung
sind acels sind nicht so offensichtlich
man man hat nur diesen Indikator am Ende
das das Plus dass hier erweiterte ACLs
zum Einsatz kommen und man muss sich die
dann explizit anschauen um zu sehen dass
hier auch Benutzer drauf Zugriff haben
und wenn dem so ist kann lockrotate
wieder schon wieder gefährlich verwendet
werden also nicht sehr offensichtlich in
dem Fall ein weit ein weiteres Szenario
wäre wenn zwar das Lock Directory rot ör
und das übergeordnete Directory root
gehört aber das überübergeordnete
Directory wie hier project war WW
project einfach einen Benutzer gehört
dann würde der dann dann würden die
Angreifer nicht
unbedingt nicht unbedingt das Log
Directory direkt auswechseln sondern
einfach das übergeordnete
Directory auch nicht offensichtlich
dieser
Fehler und das nächste ist wir sagten ja
dass die sudirektive das Problem löst
nicht in jedem Fall es kann es es gibt
natürlich Möglichkeiten dass man auch
mit der
sudirektive L lograte falsch verwenden
kann oder gefährlich verwenden kann
dann dann werden die Privilegien
vielleicht nicht zu root erhöht aber zu
einer anderen Benutzerin oder Benutzer
wenn man beispielsweise in einer Gruppe
ist mit dem mit diesem Benutzer
mit diesem Wissen
äh habe ich mir dann verschiedenste
Repositories angeschaut ich hab mal
Davin Repositories durchgeschaut ich
habe die redad Repositories durchgewühlt
ich habe die AR Linux Repositories so
viel ich weiß durchgewühlt und haben
einfach angeschaut ob wirklich alle
maintainer sich dem bewusst sind weil
viele Pakete kommen mit einer Lock
rotate configuration
und ich wollte einfach nur wissen sind
die auch wirklich optimal verwendet und
eingesetzt und die Antwort ist
klarerweise nicht
alle ich habe eine Sicherheitslücke in
grunger gefunden grunger ist mit einer
schwachen lockrotate Konfiguration
kommen und ich habe das gemeldet über
den davan bugtacker die D der davan
maintainer hat sich ziemlich schnell
gemeldet hat das als Sicherheitslücke
erkannt hat die
äh hat sogar eine CV äh beantragt hat es
relativ flott gefixt hat das
Hoch gemeldet zum Upstream zum zu den zu
den kunger Leuten und es wurde schnell
gefixt es war kein wirkliches kein
wirkliches damdam es war schnell gefixt
und Problem behoben sie haben das als
Fehler einfach
erkannt als nächstes habe ich die
omnibuspakete von gitlab gefunden die
omnibuspakete von gitlab die ja direkt
von gitlab glaube ich auch geschnürt
werden hatten
ebenfalls fehlerhafte Loog rate
configurations im Paket drin und als ich
das melden wollte sah ich dass
das für gitlab auch back Bounties gibt
hab das Ü
program reportet und sogar eine die
kassiert also ja ist ein
Bug als nächstes habe ich ein redhead
Paket gefunden free Radios habe das auch
gemeldet ich habe das redhead gemeldet
über das redhead BU Bug
Tracking Programm und die haben das auch
als Sicherheitslücke gesehen und haben
und haben das sofort sich drum bemüht
eine CV zu zu requesten und haben das
auch den den maintainer bzw den den
Developer geschrieben und der war
dadurch ein bisschen entzürt dass sie
zuerst eine CVE requested haben bevor
sie mit ihm gesprochen haben und das
ganze wurde
dann nicht so angenehm aufgenommen und
disputed sein Argument war dass man
zuerst einmal free Radios in irgendeiner
Form hacken muss um überhaupt
dieser Radi Benutzer zu werden und das
ist gar nicht so einfach und damit ist
es keine
Sicherheitslücke kein
Fehler also bin ich hergegangen und habe
mein Lock rotten Exploit genommen und
bei der Exploit DB hochgeladen die haben
das sofort angenommen also Offensive
Security hat hat hat sich dem angenommen
und hat das schön eingepflegt in die
Exploit
und als back
angesehen und kurz nachdem ich das
hochgeladen habe es gibt natürlich die
ganzen die ganzen Feeds und RSS Feeds
die einfach zeigen wenn in explob was
eingepflegt wird woraufhin dann Leute
angefangen haben bei Hack the
box Maschinen zu machen und challenges
zu machen wo der Entgegner dann
lockrotten ist
also die haben das schon als als super
nützlich
angesehen bald darauf nachdem auf heckte
Box dieser diese diese Box gegeben hat
hat's nicht mehr lang dauert bis auch in
linpce ein Tool zum für prileg
escalation zum Scannen eines Hosts nach
privage escalation
vulnerabilities da wurde Lock rotten
einfach eingepflegt das heißt limpies
scannt auch nach diesen lockrotten nach
lockrotten vulnerabilities in einem
System also der die haben das auch ganz
gut als Sicherheitslücke
angesehen der gleiche der gleiche
Developer der limpies entwickelt oder
pflegt hat auch ein tolles Buch namens
oder tolle Ressource namens hactrixs wo
man so pentest payloads wiederfindet und
auch da wird man wenn man nach privilage
escalation sucht privage escalation für
Linux findet man auch
lockrotten ja auch da ist es als sehr
nützlich angesehen
worden
nachdem sind dann einfach einmal
eineinhalb Jahre vergangen wo ein Pull
Request von mir offen war der der das
hätte fixen sollen der besser war der
diesmal wirklich alle äh der diesmal
wirklich den ganzen Pfad gecheckt hat
alle möglichen Dinge gecheckt hat und
lockrotate nur ausgeführt wird wenn die
Checks alle in Erfüllung gehen und
passen nur das war den Entwicklern ein
bisschen zu gefährlich weil dieser
dieser Fix würde quasi viele
Installationen brechen und viele neue
Probleme vielleicht ins Leben rufen also
haben es vorherst einmal gesagt schauen
wir mal warten es einfach einmal ab was
genau da jetzt passiert mit diesem
Exploit und jetzt 2022 habe ich mir
einfach die Problematik noch einmal
angesehen es ist einfach irgendwie jetzt
gewisse Zeit vergangen und schauen wir
einfach noch mal in die Repositories ob
sich etwas gebessert hat und
aktuell gibt's einen Bug Report von mir
in
debien wo snord eine gefährliches eine
gefährliche lockrotate Konfiguration
verwendet da Benutzers Nord ist da in
der Lage die privilege escalation
auszunutzen und root zu werden ich habe
das überprüft mit den source files von
von snord selbst wo eine lockrate
Konfiguration mitkommt und das kommt da
schon fehlerhaft mit ich habe das
gemeldet und die der davan maintainer
meinte das ist nicht wirklich
sicherheitskritisch hat die severity auf
Normal zurückgestuft was bedeutet dass
dieser Bug erst gefixt wird in davan
unstable und im aktuellen davan bullsai
ist diese Lücke quasi noch offen dieser
Bug ist
offen
ja und lockrotate hat in der
Zwischenzeit einen eigenen fix einen
Entwickler von lockrotate hat einen
eigenen fix eingepflegt der prüft nicht
den ganzen Pfad durch sondern prüft nur
die letzten Stellen durch ob da
irgendwelche simlinks sind verwendet
fileskriptoren um das
weiterzugeben und
Lock rotten funktioniert damit nicht
mehr ob das Problem wirklich behoben ist
bin ich mal noch nicht hundertprozentig
sicher denn es gibt immer noch ein
rename am Ende und bei rename kann man
keinen fileskriptor mit übergeben das
heißt
wäre möglich rein theoretisch dass man
in rename noch eine Race condition
ausnutzt ob es dafür allerdings einen
praktikablen Exploit
gibt möchte ich im Moment noch
bezweifeln somit ist kein back
mehr und jetzt kommen wir zum Demo ich
habe eine Demo
vorbereitet wo wir einfach auf einem
aktuellen gepatchten bullsai mitnord uns
anschauen können wie wie Lock roton
funktioniert
dazu starte ich hier meine meine mein
Demo und wir können da
sehen links oben ist der Administrator
rot mit Lock rotate mit einem offenen
lockrotate
dieses dieses diese Shell ist eigentlich
nur da damit ich manuell loogrotate
ausführen kann weil sonst müssten wir
jetzt warten bis lockate einmal am Tag
läuft und um das ein bisschen ab kürzen
gibt's die obere Shell wo ich später
dann manuell Loog rotate ausführen werde
als
root rechts gibt's einen ncat Listener
das ist quasi der Listener wo die
Angreifer auf eine root reverse Shell
warten und unten im großen Fenster sehen
wir ein unser unser Zielsystem wo ein
Angreifer schon als Nord angemeldet ist
als Benutzers Nord wie auch immer ihr
wie auch immer die Benutzer das die
Angreifer das geschafft haben und
äh ja wir werden jetzt sehen wie dieser
Exploit jetzt funktioniert ich zeige
jetzt dann noch oben im oberen Fenster
wo die rootell ist wie die snord
configuration aussieht damit man sieht
wie diese wul wie diese angreifbare
lockrate Konfiguration im Detail
aussieht und da kann man jetzt sehen
wenn man
hochsrollt dass hier das Warlock Nord
mit Stern sternlock drin ist und die
neuen fils als Nord angelegt
werden jetzt schauen wir uns die
Berechtigungen von warlog Nord an gehört
snord das heißt snord hat da
Schreibrechte das heißt wir können da
jetzt einfach ein ein locktier Anlegen
dadurch dass das in der Config mit Stern
angegeben ist kan können wir irgendein
ein Directory angeben nennen wir Hacky
und wir legen da jetzt auch noch ein
Logfile an das einfach nur die Endung
Lock haben muss wenn wir oben das
Vergleichen irgendewche der Daten drin
damit es auch wirklich rotiert wird das
reicht ja und damit haben wir die Basis
geschaffen für unseren Exploit schauen
wir uns noch den payload an hier sehen
wir nur wenn root sich einloggt wird die
Reverse Shell
aufgemacht jetzt führen wir den Exploit
aus
wunderbar und sobald sich root noch mal
anmeldet im System sollte
sich die Reverse
Shell schauen wir noch einmal rein ja
genau das PIL ist angelegt worden und
sobald sich rot jetzt noch mal anmeldet
sollte die Reverse Shell automatisch
aufgehen und wir sollten root
sein ja wir sehen die Connection schon
auf der rechten Seite prüfen das wir
sind rot
oscb man muss einen Proof abgeben also
einmal einmal die ipcig ansehen damit
man wirklich sieht wir sind auf diesen
Host und jetzt schreiben wir noch einen
pile damit wir das vergleichen können
mit den mit mit dem rechten mit mit der
Rechten
Session
und hier der proof wir sind da
tatsächlich drauf und haben diese
Fleck
okay jetzt ist es aber so dass ich nicht
glaube dass dass das große Risiko bei
bei bei snord und bei Free Radios und
bei gitlab und so weiter sind weil wir
da ja wirklich zuerst einen
Exploit brauchen um als dieser Benutzer
überhaupt ins System zu kommen und diese
Exploits sind meiner Meinung nach nicht
so wahrscheinlich wie irgendwelche Web
Exploits und wenn wir jetzt in dieser in
dieser slide auf der rechten Seite
schauen ich habe einfach einmal gesucht
nach nach
indexof/log auf Google und man kann
sehen dass es tatsächlich in Logfiles
die rotiert werden in webrroots gibt
wenn die jetzt noch die falschen
Berechtigungen haben und als rot rotiert
werden sind das
potenzielle sind das
potenzielle Ziele für eine
lockrotten für ein lckrotten
Exploit die Wahrscheinlichkeit initial
fothold zu bekommen über eine
Webanwendung ist natürlich sehr hoch
oder wesentlich höher als bei
irgendwelchen anderen Programmen und
wenn man es einmal schafft über ein
keine Ahnung vulnerables Plugin oder
ähnliches einmal fothold zu haben und
darin dann diese Logfiles findet ist da
sind die Angreifer dann automatisch
rot ein weiteres Szenario oder ein
weiteres highrisk Szenario sind
usershells bei Universitäten oder sonst
irgendwo wo einfach irgendwelche
Benutzer sich anmelden können um Ihre
Tasks auf einem Server zu machen die
sind natürlich
genauso ein potenzielles Ziel für für l
roten Exploit wenn in home directory des
Benutzers vielleicht die Logs rumliegen
die da rotiert werden als
rot welche lessens habe ich da
rausgelernt weil ich meine das sind
jetzt keine Ahnung paar
Jahre da ist zum einen ein großer da ist
ein ein ein ein großer Unterschied in
der Wahrnehmung was hier ein vulnerabel
ist und was nicht für die einen ist es
ganz klar eine Sicherheitslücke Zahl mal
vielleicht sogar noch BU Bounties oder
sonst irgendwas und für andere ist es
ganz klar das ist kein Bug das ist kein
Sicherheits relevantes
Thema dann gibt's da halt auch
verschiedene Umgebungen also in manchen
Umgebungen wie webumgebungen kann das
sehr kritisch sein und in manche anderen
Umgebungen ja nur ein ein ein ein
wirklich minimales Risiko
nichtsdestotrotz layers of security sind
ist einfach unser Ding in den 90er
Jahren hofften wir dass eine Firewall
uns beschützt und das war's und in in
innerhalb von dieser von diesem Netzwerk
sind wir dann sicher weil wir haben je
die Firewall davor aber jetzt wissen wir
wir brauchen mehrere Schichten an
Security und es ist sehr wichtig dass
man auch hinter unseren Barrieren
Security aufziehen und wirklich in allen
layers security
behandeln was ich noch gelernt habe ist
einfach zuzuhören die Entwickler
zuzuhören und nicht einfach auf meine
Meinung bestehen sondern einfach auch
ein gewisses Verständnis zeigen um
einfach offen zu sein für das Thema es
ist leichter in in der Kommunikation und
es ist genauso
gut um einfach selbst zu lernen in
diesen und sich weiter zu entwickeln in
diesem
Thema und mein größtes lessons learned
ist einfach Code checken bevor man einen
pquest sendet weil mit dem habe ich mir
sehr viel eingetreten schon an der
ersten Stelle damit will ich mich ein
Mal verabschieden und sagen mal Danke
Schön falls noch irgendwelche Fragen
gibt ich habe hier auch noch eine slides
für den contat und stehe jetzt noch für
Fragen offen danke schön vielen Dank
Wolfgang für dieses spannende Talk jetzt
gibt's eine
q& haben noch ein bisschen Zeit über
Twitter IC oder mestedon eure Frage
einzureichen bitte den #fchance benutzen
auf Twitter im mestedon auf ERC kan ihr
fchance 22
verwenden so ich habe erstmal ein paar
Fragen den erste
ist also ist das Fehler jetzt
behoben ich habe mal ich habe mal l ich
habe mal lckrate zu das die aktuelle das
aktuelle Release von
lockroate kurz angeschaut es scheint
sehr elegant behoben worden zu sein aber
nicht vollständig es schaut für mich so
aus als wäre zum Schluss noch ein
kleiner GAP offen so so ein ein kleines
Fenster wo eine Race condition passieren
kann nämlich im rename ob das
praktikabel ausnutzbar ist bezweifle ich
aber also ich denke es ist geschlossen
na alles klar ähm und ich wollte dich
auch fragen ob erstmal haben diewickel
von logro Zeit das sicherheitslüche
nicht erkannt aber haben die vielleicht
nach ihen ein nach dass von so viele
andere Quelle haben das erkannt haben
sie sich ihrer Meinung dazu geändert ja
ich denke auf jeden Fall weil sie haben
das letztendlich dann doch gefixt
äh nur das große Problem war sie wollten
nichts mit dem Fix kaputt machen
deswegen sind sie sehr sehr vorsichtig
damit um gegangen und haben es sehr
lange offen
lassen alles klar sie haben auch erwähnt
in den Talk über den dass die Lucke gar
nicht so leicht ausnutzbar ist im Docker
Container oder lxc
ktainer und was ist eigentlich die Grund
dafür warum ist es denn
unterschiedlich also ich vermute dass es
daran liegt dass im im im lxc Container
oder in ein Overlay FS ist und ich
verwende einotify und um zu erkennen
wann quasi ein bestimmter Part im Code
getriggert wird und mach dann meine
Aktionen um das Race zu gewinnen und ich
vermute dass das eine leichte
Verzögerung hat mit so einen Overlay FS
ich kann es nicht prüfen aber es sieht
so aus
okay alles klar wenn sie noch noch mal
kurz für uns erläuten was sind
also im das ist vielleicht ab aufgehoben
ist ist das Problem aber was sind die
Best Practices beim Log rotate gerade Z
Zeit das Best Practice bei lockrotate
ist lockrotate wenn man wenn man es
rotiert in einem in einem oder in einem
logverzeichnis die Files rotiert das
unter Kontrolle von einem Benutzer ist
dann sollten sollte man lockrate
möglichst als als dieser Benutzer
ausführen äh die sudirektive wäre
natürlich ein eine Möglichkeit oder
einfach einen grundjob machen als dieser
Benutzer der genau dieses loogrotate
dann in diesem Verzeichnis ausführt das
wäre das Beste weil da dadurch können
keine Privilegien verändert werden alles
klar also solange der Root in den Fall
sich äh nicht daran geht soll es
eigentlich alles in Ordnung sein genau
oder ein anderer Benutzer es muss ja
nicht unbedingt ein ausnutzen von von
User zu root sein es kann ja auch sein
rer zu einen anderen User also man
sollte möglichst Logfiles mit den
Berechtigungen des gleichen Users
ausführen wenn Sie in einem wenn die
logfils in einem Verzeichnis sind das
einem bestimmten Benutzer
quört alles klar ich gucke mal noch kurz
ob in der Zeit mehrere Frage
reingekommen
sind ich glaube die ich habe den alle
also vielen Dank noch mal für den Talk
wurfgang ich habe auf jeden Fall was
gelernt würd mir aufpassen in die
Zukunft und ähm genau wir bedanken uns
bei alle die möglich gemacht haben heute
bei alle Engeln Elfen Übersetzerinnen
und alle die hinter die Kulissen
arbeiten
ه