BrowserStack: hacker kwam binnen op oude testmachine via Shellshock-bug

BrowserStack heeft een toelichting gegeven over hoe een hacker e-mailadressen van gebruikers heeft kunnen bemachtigen. Volgens de browsertestdienst wist de aanvaller dankzij de Shellshock-bug een verouderde server op Amazon Web Services binnen te komen.

In de excuusmail beschrijft BrowserStack de vermoedelijke werkwijze van de hacker. De aanvaller zou via de Shellshock-kwetsbaarheid in Bash toegang hebben verkregen tot een oude, uitgefaseerde server binnen de gevirtualiseerde omgeving die BrowserStack bij Amazon Web Services draait. Zo kreeg de hacker de api-sleutels voor AWS in handen. Met behulp van deze informatie wist hij een eigen virtuele server in te richten en zich voor te doen als een legitieme BrowserStack-beheerder.

De aanvaller begon volgens BrowserStack persoons- en inloggegevens uit een database te kopiëren. Hierop sloegen de monitorsystemen alarm, waarna de hacker werd geblokkeerd. Hij was volgens de browsertestdienst in staat om in korte tijd naar schatting circa vijfduizend accountgegevens te kopiëren, om vervolgens deze gebruikers een e-mail te sturen waarin onder andere ten onrechte was geschreven dat BrowserStack zijn deuren zou gaan sluiten.

BrowserStack biedt zijn excuses aan voor het incident maar stelt dat de schade relatief beperkt is gebleven. Niet alleen zou minder dan 1 procent van de actieve accountgegevens zijn gekopieerd, ook benadrukt het bedrijf dat er geen creditcardgegevens zijn buitgemaakt. Ook zijn wachtwoorden niet alleen hashed, maar ook salted op basis van het sterke bcrypt-algoritme en alle productiesystemen van BrowserStack zouden tijdig van een Shellshock-patch zijn voorzien. Verder claimt het bedrijf extra beveiligingsmaatregelen te hebben getroffen, zoals het versleutelen van back-ups en het laten uitvoeren van een beveiligingsaudit op de AWS-infrastructuur door een externe partij.

Reacties (33)

[kritischelezer]

Goed dat het bedrijf met een uitleg komt!

[totaalgeenhard]

Uhm, hadden ze vooraf iets minder tijd en energie gestoken in beheer, hadden ze dit achteraf niet hoeven te doen.

Voorkomen is altijd beter dan genezen.

[jaapzb]

Aan de andere kant moet je er eigenlijk van uit gaan dat je een keer gehackt word en dat je veiligheidssystemen in plaats hebt om zo veel mogelijk de problemen die zich dan voor kunnen doen tegen te gaan. Uit hun uitleg blijkt dat ze zich daar goed op hebben voorbereid. Dat ze nog ergens een virtual machine hebben hangen die door menselijk falen niet geupdate is, is natuurlijk niet oke, maar wel begrijpelijk. Dat hun systeem zo ingericht is dat ze er relatief snel achter kwamen is natuurlijk erg goed.

[totaalgeenhard]

Als je gehacked word door een bekende vulnerability zijn er maar weinig valide excuses te vinden. Achterstallig onderhoud is daar niet één van.

Zero days ben ik het volkomen met je eens, daar kun je alleen strategische maatregelen tegen nemen en gevolg risico's indammen.

[[Remmes]]

Inderdaad. Open en duidelijk zijn over het gebeuren komt niet vaak voor. Wat ik wel jammer vind is dat men acties tegen shellshock bug had moeten nemen (updaten/patchen) hoe oud die server dan ook wel niet mag zijn. Als het op een netwerk aangesloten zit hoor je het zo goed mogelijk te beveiligen.

[Reactie gewijzigd door [Remmes] op 24 juli 2024 03:17]

[Thystan]

Is niet altijd mogelijk

[Verwijderd]

Zeker. Het is netjes en dat zie je niet vaak. Ook dat ze vertellen hoe hij is binnen gekomen. Wel slecht dat er nog een uitgefaseerde server aan stond. Maar toch weer netjes dat het monitorings- systeem 'zeer snel' reageerde.

[Verwijderd]

Ik snap het nut van de hele 'hacker' actie niet.

Heeft die eerst browserstack proberen af te knijpen, of meteen een dubeuze mail lopen sturen naar die paar duizend mensen?

Doorgaands zet je dat soort zaken online, als een bedrijf het besluit stil te houden / niks eraan doet.. maar het lijkt hierbij, alsof hij bij voorbaat een nep mailtje de deur uit heeft gedaan.
Zonder phishing zooi erin te zetten.. wat is het nut? (naast irritant zijn)

Ansich vind ik dat BrowserStack hiermee niet slechter in de boeken komt te staan, want menig ander IT bedrijf zal het anders aangepakt hebben.
Het nog open hebben staan van een server.. kan zoveel oorzaken kennen, maar is uiteraard niet netjes.
Slordig om niet de toegang afgesloten te hebben en/of niet geupdate te hebben, maar het valt in de relativiteit erg mee. (kennelijk had eigenlijk alleen die paar productie configuraties eraf gehaald moeten worden).

Slordigheidje, maar verder kennelijk structureel goed geregeld.. vind ik goed nieuws voor BrowserStack..
Irritante kindjes zullen er altijd zijn. (oftewel, lees: 'hackers')

[SacredRose]

ik denk dat je hier best bij kan zeggen dat de hacker het deed omdat het kan.

hij heeft een server gevonden en gehackt.volgens mij redelijk zonder de bedoeling daadwerkelijk creditcard gegevens of zoiets te stelen.

ik denk dat dit meer iemand is die wou weten hoe ver hij kon gaan voor ze hem opmerkte

[Verwijderd]

Nog steeds vind ik het frappant, dat er een mailing uitgestuurd is door die gast (of vrouw, maar dat zien we nog steeds weinig).

Ik vermoed, dat het inderdaad iemand was, die even uitprobeerde hoe ver hij kwam en waarschijnlijk negatieve ervaringen heeft gehad bij het bedrijf.
Anders.. annoy just to annoy.. gelukkig hebben we de Maas hier om dat soort kindjes in te gooien.

[ge-flopt]

Hij heeft toegang gekregen via een oude uitgefaseerde server?! Hoe doet hij dat dan, de server is toch uitgefaseerd, dat betekend in mijn boekje, hij staat uit. Als hij toegang heeft gekregen tot die server is hij dus niet uitgefaseerd.

[Tim.k]

De server was ook uitgefaseerd en zonder enige connectie met de service zelf, het ging hier echter om een testserver waaruit de hacker kennelijk API sleutels van Amazon heeft kunnen pluizen (waarom de service draait) en via die API sleutels heeft de hacker toegang kunnen krijgen tot Amazon instellingen waarbij hij zijn IP heeft gewhitelist en een nieuwe VM heeft gemaakt via een voorgebakken template, via die VM heeft hij toegang kunnen krijgen tot andere servers en zodoende de database met e-mailadressen.

[i-chat]

[...]
Dit was een IT site toch? Dit is ronduit bedroevend. Salten is *compleet* nutteloos als je niet hashed. Dan zou er dit in je database staan:
saltwachtwoord
Ipv iets als $6$saltwaarde$<hash van salt+wachtwoord>

even Goed leren lezen: er staat dat wachtwoorden salted en hashed zijn... de reden warom het zo uitelkaargerekt staat (en misschien aan je aandachtsspanne is ontsnapt ) is omdat men aangeeft wat voor soort hash er gebruikt is...

niet zomaar md5 of sh1 maar bcrypt... dat zijn maatredelen die heel veel andere partijen duidelijk niet nemen, ook de manier waarmee ze met deze hack omgaan laat wat mij betreft wel zien dat er beter om wordt gegaan met veiligheid dan bij veel andere diensten en dat geeft op het eerste idee een beter gevoel. en dat voor een platform waar geen productiemachines (van klanten) op draaien vind ik best netjes..

voelt toch een beetje aan als 'drive assist, winterbanden, abs en parkeer indicatie' in een goedkope huur auto

[Reactie gewijzigd door i-chat op 24 juli 2024 03:17]

[Whatts]

Er staat dan toch ook salted EN hashed?

@ freaky hieronder:
Het zijn ook 2 verschillende beveiligingen, die echter inderdaad bijna altijd samen gebruikt (moeten) worden.

[Reactie gewijzigd door Whatts op 24 juli 2024 03:17]

[freaky]

Ja, maar zo klinkt het alsof salten opzich al een oplossing was. En dat is het zeer zeker niet. Dit doet het overkomen als 2 lagen van beveiliging.

[totaalgeenhard]

En inderdaad het zijn geen 2 lagen van beveiliging.

Password files is de opslag van een beveiligingslaag (password/user authenticatie proces).

Dat je dezen hashed is vanzelfsprekend, echter sommige partijen gebruiken een reversible algortime ipv one-way- hash. Wat net zo handig is als niet hashen.

Salten betekend niets meer of minder dat er voordat wachtwoorden gehashed worden iets werd toegevoegd (het zout) waardoor de hash niet middels een rainbowtabel of bruteforcecracking te herleiden is.

bijvoorbeeld: EENWACHTWOORD = f2c1323d46cbd95ec72a6cebe1deaa1b (MD5)

Met salted hash: #EENWACHTWOORD = 64be96ded2151bd6927cf21062714c96

Dus bij bruteforcen of gebruik van rainbowtabellen, zul je nooit bij EENWACHTWOORD uitkomen.

Aan de andere kant als je password files kunt benaderen, zul je ook gebruikte HASH en SALT kunnen herleiden..... het houd dus alleen de luie, incompetente mensen tegen.

[Bacchus]

Dat je dezen hashed is vanzelfsprekend, echter sommige partijen gebruiken een reversible algortime ipv one-way- hash. Wat net zo handig is als niet hashen.

Gezien de frequentie van berichten over gelekte compleet onbeveiligde wachtwoord-databases, is het niet zo vanzelfsprekend.

Aan de andere kant als je password files kunt benaderen, zul je ook gebruikte HASH en SALT kunnen herleiden..... het houd dus alleen de luie, incompetente mensen tegen.

Dat valt wel mee met lui en incompetent: Ook slimme en hardwerkende aanvallers kunnen niet binnen redelijke tijd een niet-triviaal wachtwoord in correct toegepast bcrypt ontcijferen. Ook niet als je ze de salt kado geeft.

[totaalgeenhard]

Meeste OS'en komen standaard met hashed password files. Ik ken geen recente os waarbij het niet het geval is. Unixxen uit jaren '80 hadden dat niet standaard (IRIX, HP-UX, AIX etc..)

De incidenten waar we het meest overhoren zijn zogenaamde SQL-Injecties, waarbij het wachtwoorden betreft die voor e.a. webapplicatie unhashed zijn opgeslagen.
Dat o.a. PHP programmeurs daar voor kiezen is vaak onwetendheid, ze staan er simpelweg niet bij stil dat er iets als SQL-injecties en input-misbruik plaats zal vinden. Verder had je vroeger een ander argument encryptie gebruikte gewoon teveel CPU resources en daarmee was het een te duur proces om grootschalig toe te passen.

Wat is redelijk termijn. Het enige wat je ziet bij one-way-hash algoritmes dat de time-to-compute toeneemt. Stel dat bcrypt 2 keer zoveel tijd nodig heeft dan MD5 dan wil dat alleen zeggen dat het 2 keer zoveel tijd kost om die rainbow files te genereren, met steeds sneller wordende GPU's waarbij 60% toename in computing power in de 2 jaar regulier is geworden, is dat geen probleem.

SALT daar een tegen zorgt er daadwerkelijk voor dat brute-forcen en rainbow tables nutteloos worden ongeacht welke one-way-hash-algoritme je gebruikt. Je komt namelijk nooit uit bij de juiste HASH.

[Bacchus]

Wat is redelijk termijn. Het enige wat je ziet bij one-way-hash algoritmes dat de time-to-compute toeneemt. Stel dat bcrypt 2 keer zoveel tijd nodig heeft dan MD5 dan wil dat alleen zeggen dat het 2 keer zoveel tijd kost om die rainbow files te genereren, met steeds sneller wordende GPU's waarbij 60% toename in computing power in de 2 jaar regulier is geworden, is dat geen probleem.

SALT daar een tegen zorgt er daadwerkelijk voor dat brute-forcen en rainbow tables nutteloos worden ongeacht welke one-way-hash-algoritme je gebruikt. Je komt namelijk nooit uit bij de juiste HASH.

Het gebruik van bcrypt impliceert al het gebruik van een salt. Daarbij is bcrypt expliciet ontworpen om traag te zijn. Praktische implementaties ervan itereren ook nog een paar (duizend, tienduizend, die orde van grootte) keer. Hiermee is het berekenn van een wachtwoordhash niet een factor twee maar eerder tegen de vijf a tien ordes van grootte intensiever dan met MD5. Als je dat vanwege de salt ook nog voor ieder wachtwoord opnieuw moet doen, is het al snel niet meer de moeite waard.
Dat wil zeggen: de gebruiker ontvoeren en door pragmatische toepassing van een tuinslang overtuigen zijn wachtwoord te vertellen is minder duur.

[totaalgeenhard]

Vergeet niet tuinslang brute force is sneller...

Wel grappig dat je met dat voorbeeld aankomt, soms kom ik weleens wijsneuzen tegen die zeggen dat bij hun alles 100% veilig is.... waarop ik het voorbeeld geef dat geen enkele systeembeheerder zal toekijken terwijl vingers van zijn dochters worden afgeknipt. Mensen zijn dan onaangenaam verrast door het voorbeeld en realiseren zich vaak niet dat naar mate iets belangrijker is om te beveiligen, de kans dat iemand niet technische tegenmaatregelen zal nemen groter zal worden.

Overigens ik gaf aan "stel dat het twee keer langzamer is". Ik ken de specs van bcrypt niet t.o.v. md5.

Ik deel je mening niet dat een algoritme, salt impliceert, omdat het alleen als oplossing met elkaar te maken heeft maar niet als onderdeel van proces (door algoritme heen halen).
Het ligt immers aan de implementatie.

[tisvonkje]

> Unixxen uit jaren '80 hadden dat (hashed password files) niet standaard

Je hebt het mis. Al vanaf v7 unix (PDP11) werd voor het opslaan van wachtwoorden hashes gebruikt. Iets preciezer: het wachtwoord werd samen met een salt gebruikt als key. Als data werd een bericht van 0-en geencrypt via DES. De uitkomst werd opgeslagen. Hierdoor was het wachtwoord nooit meer te herleiden (behalve door te brute-forcen).
Grappig is wel dat er oorspronkelijk een fout zat in de salt generatie: hierdoor werden niet alle 4096 mogelijke salts gebruikt.

[totaalgeenhard]

Ik ken v7 Unix niet, als in nooit gebruikt.

Maar in de jaren '80 waren unsalted hashed password files gewoon.
Bovendien waren er bepaalde unixxen die gewoon toen nog plain ASCII password opslaan in dezelfde file.

[tisvonkje]

Ik daag je uit om met redelijke bronnen aan te tonen dat er unix versies waren met plain text wachtwoorden. Ik heb ze nooit gezien en betwijfel nog steeds je uitspraak omdat v7 gereleased is 1979

[Dorus]

Het hele punt van een salt is juist dat deze per gebruiker uniek is. Je kunt nog steeds een rainbow tabel maken voor de salt van gebruiker X, maar dan heb je nog geen rainbow tabel voor gebruiker Y, zelfs niet als het salt algorithme openbaar is.

Het is dus wel belangrijk dat je per user een unieke salt hebt. Bonus punten als je salt geheim is, maar dat is dus niet noodzakelijk. Als je salt niet uniek is, heb je effectief je hashing algorithme ietjes pietjes langzamer/non-standard gemaakt, maar dat voegt weinig toe.

[Haribo112]

Of de zin "maar ook hashed op basis van het sterke bcrypt-algoritme" legt de nadruk op het bcrypt deel? Dus wat men probeert te zeggen: de wachtwoorden zijn uiteraard gehashed, en 1) ook nog gesalt en 2) zeer STERK gehashed

[kwikstaart]

Dan is het nog de vraag hoe er gesalt is: een generieke salt voor alle accounts, of een unieke salt per gebruiker, bv de accountnaam en evt nog wat gegevens.

[Haribo112]

Ja maar daar ging deze thread niet over

[Verwijderd]

Het staat inderdaad een beetje vreemd in het artikel. Als ze het hashen en salten zouden omdraaien in de tekst, inclusief het stukje over de gebruikte hash methode, dan klopt het beter.

[XLord]

bij de eerste mail (waarin werd gezegd dat ze gingen sluiten) had ik al een vermoede dat er een hackertje bezig was geweest en het geen officiële mail van browserstack was.
maar het is goed dat ze snel hebben gereageerd op zijn acties.

[RobinJ1995]

Mooi! Bcrypt! Voor een keer eens geen plain text of MD5!

[xp65]

Ik zie veel comments over de salted wachtwoord (wat technisch trouwens zo te zien correct door hen werd uitgevoerd) Wachtwoord, Salted + Encrypted, maar voor AWS kenners is er 1 ander pijnlijk punt:

AWS raad aan om GEEN root keys te gebruiken op front end servers, met IAM, kan je per server policy's maken met aparte keys die enkel en alleen kunnen wat ze moeten doen. Elke functie van de API kan beperkt worden, zelfs in welke submappen er van S3 gelezen of geschreven mag worden, etc.

Een nieuwe EC2 server opstarten had nooit via die API op de webserver (of de hackable front end servers) geactiveerd mogen staan.

Voorbeeld: enkel delete en write voor submap backup.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SidNaam",
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:PutObject",
],
"Resource": [
"arn:aws:s3:::RepoNaam/backup/*"
]
}
]
}

Bijkomend waar het ook fout kan lopen is als wel de API beveiligd is, maar de security groups is niet goed beveiligd. Men kan backend servers in 1 of meerdere security groups zetten en zorgen dat ENKEL inkomende traffiek van deze servers mogen komen van erkende servers van erkende security groups backend & front end.

Veel weten namelijk niet dat ze niet enkel een IP adres kunnen invullen maar ook een andere security group als source, en alle andere servers blokkeren.
https://docs.aws.amazon.c...dding-security-group-rule (zie punt 6)

Dan kan men niet via extern (of andere ec2 servers) met de backend (database) server connecteren, en kan men ook niet met de API een eigen server opstarten.

Tussen de databank server en de front end servers kan indien gewenst (echte goede beveiliging) backend API servers zijn, die de echte berekeningen doen, om te voorkomen dat iemand custom queries kan schrijven. De API van front end (niet admin) servers kunnen dan zo gemaakt worden dat het als guest of als user onmogelijk is om de salted wachtwoorden etc op te vragen.

De Admin instances kunnen dan weer beveiligd worden zodat enkel en alleen het bedrijf zijn ip adressen gewhitelist zijn en al de rest geblokkeerd.

AWS kan heel veilig zijn, maar het nadeel aan eenvoud, is dat er ook te eenvoudige structuren in elkaar worden gestoken die niet veilig zijn. Enkel encrypted&salted wachtwoorden is dan ver van genoeg.

[Reactie gewijzigd door xp65 op 24 juli 2024 03:17]