image

Ernstig SquirrelMail-lek kan aanvaller toegang tot server geven

maandag 24 april 2017, 10:03 door Redactie, 16 reacties

Er bevindt zich een ernstig beveiligingslek in de webmailsoftware SquirrelMail waardoor een aanvaller op afstand de server waar de applicatie op draait kan overnemen. Er is nog geen update beschikbaar. De software blijkt gebruikersinvoer niet goed te "escapen" als Sendmail wordt gebruikt voor het versturen van mail. Een aanvaller die over inloggegevens beschikt kan hiervan misbruik maken en het systeem waarop SquirrelMail draait compromitteren.

"Een succesvolle aanval geeft een remote aanvaller toegang tot de aangevallen server in de context van het webserveraccount dat tot een volledige compromittering van de webapplicatie kan leiden", aldus onderzoeker Dawid Golunski. Hij waarschuwde de SquirrelMail-ontwikkelaars al op 4 januari van dit jaar. Het ontwikkelteam vroeg Golunski vanwege privéredenen om meer tijd. Een andere onderzoeker ontdekte het probleem echter ook en maakte het deze maand via de Full Disclosure-mailinglist bekend. Daarop besloot Golunski ook zijn details vrij te geven. Beheerders kunnen als tijdelijke oplossing voor "SMTP based transport" kiezen in plaats van Sendmail.

Reacties (16)
24-04-2017, 15:50 door Anoniem
Maakte Sigaint ook geen gebruik van SquirrelMail? Zou dit lek dus de reden kunnen zijn dat Sigaint al enige tijd down is?
24-04-2017, 17:31 door karma4
Waarom draait dat squirelding met die hoge rechten dat zo'n escape kwaad kan. Meerdere verdedingslinies zijn effectiever dan een enkele. De obscurity van enkel code is op de lange termijn nooit veilig.
24-04-2017, 20:30 door [Account Verwijderd]
[Verwijderd]
24-04-2017, 20:42 door linuxpro
Gelukkig al tijden geleden van Squirrelmail afgestapt. Moet zeggen dat Roundcube, jaja, ook PHP enzo, toch na de laatste major update aardig m.b.t. de code is opgeschoond.
24-04-2017, 20:43 door karma4
Door 4amrak: antwoord op de vraag: squirrel is gemaakt mbv php dus wordt het gerunt met dezelfde context als apache draait. daar is niet eenvoudig iets aan te doen als zodanig: httpd (apache) moet de php code draaien -> httpd moet de files kunnen lezen en de php code zal als die www / apache user draaien.
.....
security by layers en design dus.

Kortom, de bug is serieus, moet aangepakt worden, maar het is niet reden tot PANIEK.
wat dat betreft is SELinux op RHEL erg fijn; vrijwel geen last van shellshock gehad en een dagje later een patch als update:
Eens. Het was meer een vraag waarom dat niet zo ingevuld is als gangbare werkwijze.
Selinux schermt in ieder geval het webserver (proces-gebonden) deel af van de rest op de machine. Het wordt vaak als complex moeilijk dus niet doen afgeserveerd.

Voor de Http apache https://httpd.apache.org/docs/2.4/invoking.html Je kunt de daemon gewoon een eigen service account geven. Dan doe er een eigen container voor dat deel bovenop. (desnoods ngroups als docker toepassen).

Die shellshock werd in ieder geval fraai voor een webserver met selinux dicht gehouden. Ik ha liever gezien dat er geen complete shell voor het doorgeven van web-verkeer (context root naar webserver) gebruikt was maar dat er meer codeerwerk in gestoken was om enkel de parameterstring schoon door te geven gestoken was. Kwestie van veilig ontwerpen en niet bang zijn voor extra werk.
24-04-2017, 21:02 door [Account Verwijderd]
[Verwijderd]
25-04-2017, 07:21 door karma4
Door 4amrak:
Ik snap je niet geheel... eens met input sanity checking voordat je een commando op basis van user input construeerd (de basis van bijna elke sql injectie ook), maar het heeft niets met een context die als root draait te maken volgens mij.

httpd draait niet als root, dus de php code ook niet en dus het commando dat geconstrueerd wordt en niet goede escaping heeft ook niet. Staat dus lost van SELinux / Apparmour contexten.

Mooi dat het niet als root staat. Zet de docuroot ook naar een specifiek eigen veilig deel en haalt de grootste angel van path traversal er ook uit. Als je als service account iets gebruikt met zeer veel onnodige rechten lijkt het te veel op root. Zie je te vaak gebeuren omdat het anders veel accounts worden.

Die context switching met de shellshock zit er in omdat poort 80 onder root draait alle poorten onder de 1024 hebben die eigenschap. Het binnenkomend verkeer van de tcpip poort onder root wordt interessant proces doorgegeven aan de http demon niet onder root. Met dat doorgeven van root naar httpd daar zit het gebruik van de Shell.
Met een handige string ging die Shell onder root leuke dingen doen. Met confinement kon hij in ieder geval niet daar buiten komen. Zonder confinement ligt het systeem open.

Dat de sheet leuke onverwachte dingen kon/kan doen kan geen kwaad als het onder de beperkte rechten draait .
Ga eens kijken naar de exec en setenv functies voor forensische spawner processes. Dan zie je dat een complete Shell van root naar beperkt niet noodzakelijk is.

Je zou ook porten kunnen gebruiken die niet aan root vast zitten dan moet er wel een vertaalslag ergens gemaakt worden om de gangbare nummers naar buiten te tonen.
25-04-2017, 07:59 door [Account Verwijderd]
[Verwijderd]
25-04-2017, 11:29 door karma4
Hi 4amrak ik heb het je duidelijk proberen uit te leggen. Aangezien je het beeld gaf niet thuis te zijn in kernels. Verdiepen in sysinternals van een os en tools is er tegenwoordig niet meer bij. Nope ik niet enkel een windows achtergrond, meer een ander os. Ik geef dus repliek omdat de linux aanhang zoals je zelf beschrijft : snel de fix downloaden en dat is het dan. Heb je naar die c lib functies gekeken? Kennelijk niet

Als het met de shellshock de escap, niet onder root was terechtgekomen dan was er niet zo'n ophef over geweest.
Als de verdere Webserver omgeving veilig was opgezet ook minder. Omdat vele systemen toen zonder de sel versie werkten was de paniek nog groter.
Het verbaast me nog steeds eigenlijk toch niet, dat linux aanhang zo vaak de fout in gaat en vervolgens naar anderen gaat wijzen. Die houding is een probleem voor behoorlijke secùrity invulling.
25-04-2017, 15:33 door Anoniem
Door karma4: Hi 4amrak ik heb het je duidelijk proberen uit te leggen.
Duidelijk? Lees zelf dit nog eens:
Die context switching met de shellshock zit er in omdat poort 80 onder root draait alle poorten onder de 1024 hebben die eigenschap.
Wat bedoel je met "die context switching met de shellshock"? De rest van de zin refereert aan het feit dat poorten onder 1024 privileged zijn. Dat is geen eigenschap van shellshock, dat was een bug in bash om code te injecteren, en bash doet op zich zelf niets met HTTP-poorten, daar heb je webservers en dergelijke voor. Niet duidelijk.
Het binnenkomend verkeer van de tcpip poort onder root wordt interessant proces doorgegeven aan de http demon niet onder root.
De zin loopt tot en met het woord "interessant", maar vanaf "proces" blijkt hij grammaticaal zodanig te ontsporen dat ik geen idee heb wat er staat. Niet duidelijk.
Met dat doorgeven van root naar httpd daar zit het gebruik van de Shell.
Welk doorgeven van root aan httpd? Hoezo wordt root ergens aan doorgegeven? Bedoel je misschien dat httpd onder root draait en meerdere processen afsplitst die dat niet doen? Suggereer je dat daar shell-code (bash, shellshock) een rol in speelt? Dat klopt niet, hoor. Wederom: niet duidelijk.
Met een handige string ging die Shell onder root leuke dingen doen. Met confinement kon hij in ieder geval niet daar buiten komen. Zonder confinement ligt het systeem open.
Je lijkt inderdaad te denken dat shellshock onder apache gevaarlijk was omdat data uit requests al in bash terechtkomt nog voor het bij processen die met minder rechten draaien terechtkomt. Je kan apache natuurlijk zo configureren dat alles onder root draait, maar dan zit je wel de defaultconfiguratie zoals ik die bij Linux-distro's heb gezien actief om zeep te helpen.

Apache/httpd draait typisch alleen een eerste proces als root. Dat opent logbestanden, opent poorten 80/443 (of andere) om nieuwe verbindingen op te ontvangen, maar handelt die niet zelf af. Het creëert andere processen die die open file descriptors erven, waaronder de TCP-sockets, en die kunnen vervolgens zelfstandig requests die daarop binnenkomen afhandelen. Ze laten echter eerst de root-rechten vallen en draaien onder een user met beperkte rechten die bijvoorbeeld "nobody" of "www-data" heet. Als er (potentieel gevaarlijke) data zelfs maar een proces binnenkomt zijn de root-rechten al niet meer beschikbaar.

Het openen van een listen-socket is niet gevaarlijk, met die handeling ontvangt een proces nog geen data. Dat kan veilig met root-rechten uitgevoerd worden. Zoals gezegd erven afgesplitste processen die open socket, en die gaan pas handelingen doen waarmee data binnen kan komen nadat ze hun rechten hebben verlaagd.

"Met het doorgeven van root naar httpd daar zit het gebruik van de Shell", schreef je. Los van dat er helemaal geen root aan httpd wordt doorgegeven, wat betekent dat überhaupt, komt er bij die hele rechtenverlaging geen shell-code kijken. Pas in de afhandeling van requests met lagere rechten komt mogelijjk bash om de hoek kijken, maar alleen bij verouderde CGI-applicaties of als ontwikkelaars zo naïef zijn om externe programma's via een shell aan te roepen, iets wat altijd te vermijden is.

Nee, Karma, je was niet duidelijk.
25-04-2017, 18:24 door Anoniem
Veelal zie je ook dat exploits voor dit soort lekken als eerste een wget of curl opstarten om een fatsoenlijke hoeveelheid
exploit code op te halen en deze dan vervolgens gaan runnen evt zelfs na compileren.
Wat je daar tegen kunt ondernemen:

- zorg in de firewall dat je webserver niet naar buiten kan connecten, zeker niet naar heel internet.
(een uitgaande connect naar poort 25 van je mailserver zal nodig zijn)
- zet geen onnodige software op de webserver, zoals de C compiler, python, perl, wget, curl e.d.
- als dergelijke software nodig is om bijvoorbeeld het systeem te onderhouden of te updaten, zorg dan in ieder geval
dat het account waaronder de webserver draait deze spullen niet kan uitvoeren

Hiermee zorg je in ieder geval dat je de standaard exploits de deur houdt, met weinig moeite.
25-04-2017, 22:30 door [Account Verwijderd]
[Verwijderd]
26-04-2017, 20:47 door karma4
Door 4amrak: .....
https://fedoramagazine.org/shellshock-how-does-it-actually-work/
...
http://mashable.com/2014/09/26/what-is-shellshock/#PT43wSMV9aqG
4amrak dat zijn beide de populistische verhalen over hoe bash reageert met parameters. De kern waarover ik het heb is dat die bash niet in de poort doorgave naar het httpd proces hoort te zitten. Dat is system programming proces manipulatie.
Google eens.
http://www.thegeekstuff.com/2012/03/c-process-control-functions/
https://linux.die.net/man/3/exec Stel dan nog eens de vraag waarom er een complete bash ingezet wordt waar een beperktere set exec/check zou moeten kunnen volstaan.

In jou links lees je toch echt dat de string vanuit de buitenwereld uitgevoerd gaat worden onder root met bash.
Noodzaak om bash daar in te zetten is nada nada. Leg nu eens uit waarom een string vanuit een poort via bash naar de http demon moet. Als je niet zover kunt of durft te gaan ben je enkel een "believer"/volger.
26-04-2017, 21:29 door [Account Verwijderd] - Bijgewerkt: 26-04-2017, 21:58
[Verwijderd]
27-04-2017, 08:28 door karma4 - Bijgewerkt: 27-04-2017, 08:32
Door 4amrak:
zo zit het ook niet. je snapt er volgens mij echt niets van.
....
Het is duidelijk dat het technische allemaal een brugje te ver voor je is. Zullen we het er maar bij laten? Het wordt langzaamaan een beetje embarrassing namelijk...
Inderdaad embarassing die blokkade om goed te onderzoeken en zelf na te denken.
https://www.us-cert.gov/ncas/alerts/TA15-314A Beschrijft wat er speelt duidelijker. Ik houd niet pleisters voor het snel verbergen. zo'n string hoort niet actief in een shell te worden. Het speelt vrij algemeen.
27-04-2017, 12:13 door [Account Verwijderd] - Bijgewerkt: 27-04-2017, 12:53
[Verwijderd]
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.