SEGA Europa's AWS-inloggegevens waren voor iedereen toegankelijk

De AWS-inloggegevens van SEGA Europa waren tot voor kort publiekelijk beschikbaar waardoor kwaadwillenden malware hadden kunnen verspreiden via onder andere websites voor games van het bedrijf. De kwetsbaarheden zijn gedicht.

Onderzoekers wisten bij SEGA Europa toegang te krijgen tot onder andere de Steam-developersleutel, database- en forumwachtwoorden en de api-sleutel van MailChimp. Vooral de publiekelijke toegang tot de credentials voor Amazon Web Services had grote impact kunnen hebben, aldus beveiligingsonderzoeker Aaron Phillips op VPNGids.

Deze inloggegevens gaven lees- en schrijftoegang op AWS S3-buckets van SEGA Europa. Bij negen publieke domeinen van het bedrijf was het mogelijk om malware te uploaden en inhoud aan te passen. Bij onder andere downloads.sega.com, cdn.sega.com en bayonetta.com ging het om kritieke kwetsbaarheden.

Met de verkregen AWS-credentials konden de onderzoekers SEGA’s omgeving voor online opslag scannen op verdere toegang. De onderzoekers troffen de eerste kwetsbaarheden op 18 oktober aan. Ze hebben hun bevindingen gedeeld met SEGA Europa, die de laatste kwetsbaarheden eind oktober heeft verholpen.

Reacties (32)

[Jay-v]

Om je hier als organisatie tegen te beschermen kan je meerdere dingen doen. Belangrijk om te weten is dat Public s3 access by default geblokkeerd is. Je moet meerdere waarschuwing negeren om dit aan te zetten via de console.

Via Terraform or CloudFormation vangen linters dit af. Mocht een gebruiker dat toch negeren zijn er nog de volgende opties:

• Ten eerste, zet niet alle buckets in een enkel account. Er hoort ook geen account zijn wat cross-account toegang heeft tot al deze buckets. (reduce blast radius)
• Security Keys sla je niet op in s3 maar in Secrects Manager. Of een 3rd party password vault.
• Encryption op s3 via KMS.
• Dit kan gedetecteerd worden via AWS Config, Guardduty en talloze andere tools.
• Service Control Policies kunnen die op org niveau blokkeren
• Trusted Advisor flagged dit

Paar linkjes:

• https://docs.aws.amazon.c...blic-read-prohibited.html
• https://aws.amazon.com/pr...am-permission-boundaries/
• https://aws.amazon.com/bl...-protect-your-s3-buckets/
• https://docs.aws.amazon.c...account-landing-zone.html

[Reactie gewijzigd door Jay-v op 27 juli 2024 13:04]

[cork87]

Waar ik niet bij kan is dat dit soort bedrijven niet de juiste kennis in huis hebben of het niet op orde hebben om dit soort zaken te regelen.

Credentials/secrets plain text in een S3 bucket terwijl er services als KMS en Secretsmanager zijn in AWS laat mij denken dat het cloud platform wordt behandeld als een last in plaats van een toegevoegde waarde.

Het per ongeluk publiekelijk open zetten van een S3 bucket is inderdaad niet heel eenvoudig op te lossen maar hier zijn zeker wel mogelijkheden voor om dit in kaart te krijgen al dan niet met third-party oplossing.

[Keypunchie]

Ben wel benieuwd welke tool jij hebt die menselijke dommigheid kan voorkomen.

Ik zet hem graag ook in.

[Sypher]

Voorkomen is beter dan genezen.

Qua infra kom je een heel eind met tools als Checkov en tfsec. Deze kunnen je IaC code checken op misconfiguraties.

En sowieso ook handig om te voorkomen dat er secrets in je git repos terecht komen met gitleaks.

Dit alles zou een mooie plaats moeten hebben in CI/CD pipelines en/of je precommit hooks.

[djwice]

Waarom ga je er van uit dat ze TerraForm gebruiken? Je hebt ook AWS CDK en Cloudformation. Dus wellicht AWS Guard gebruiken? Dan zijn je rules ook veel makkelijker leesbaar en te onthouden en kun je de output human readable laten zijn: "bestand h heeft resource x met property y met waarde z welke niet in lijst q van toegestane waarden zit / niet voldoet aan het toegestane patroon R". En AWS Config / ControlTower, want ook grote bedrijven hebben nog afdelingen die handmatige aanpassingen doen.

Maar al die tools kijken niet naar de geüploade content in een S3 bucket.
En zouden dus dit probleem niet voorkomen.

Je kunt ook https://www.clamav.net/ in een lambda container draaien en deze automatisch draaien bij elk nieuw of gewijzigd bestand. Via tags en AWS iam kun je zorgen dat alleen ok bevonden bestanden publiek toegankelijk zijn.

Zo voorkom je ieder geval de potentiële impact van een aanval. Maar dan nog controleer je niet of er credentials staan in de bestanden op S3.

Je kunt nog bekende bestandsextensies blokkeren (idem via tagging), en eventueel naast een virusscanner een patroon herkenning toevoegen (zoals die gitleaks maar dan voor je nieuwe / geüpdate S3 file), maar het houdt ook ergens op.

[Reactie gewijzigd door djwice op 27 juli 2024 13:04]

[InjecTioN]

De combinatie van goede voorlichting en (social engineering) pen-tests werken best goed.

Daarnaast blijven password managers met 2FA wel echt een must have voor ieder bedrijf. Ondermijning daarvan zou imho bestraft moeten worden.

Er bestaan ook nog handige tools zoals Git-secrets: https://github.com/awslabs/git-secrets

[R4gnax]

Ben wel benieuwd welke tool jij hebt die menselijke dommigheid kan voorkomen.

Ik zet hem graag ook in.

In dit geval: auditing.
Credentials op onveilige manieren configureren is gewoon iets wat bij een audit naar boven zou komen.

[cork87]

Helemaal voorkomen is lastig maar het is wel te detecteren en binnen korte tijd op te lossen. Een tool als Prisma van Palo Alto kan hier zeker wat in betekenen en de IAC checks zoals aangegeven door Sypher.

[killerbie]

Het is niet dat je een spel kan ontwikkelen dat je iets van netwerken of security kent hé, als de manager er niemand voor wil inhuren heb je gewoon een barslechte security.

[david-v]

Als je een spel ontwikkeld en je weet niks van netwerken of security dan kom je echt nergens. Elk (online) spel zou dan een trojan horse zijn als je dat installeert.

Bij een bedrijf als Sega moet netwerken en security een integraal deel zijn van het ontwikkelproces.

[david-v]

Helemaal mee eens. Het doet me gewoon denken aan de postits van medewerkers die te lui waren om hun wachtwoord te onthouden en dat maar op hun scherm plakten. Wachtwoorden in excel bestanden die dan ergens op een netwerk schijf stonden, of uitgeprint in de kast. Private keys van SSLs die ook zomaar overal worden bewaard en tig keer gebackuped zonder maar één moment na te denken over het beveiligen ervan.

Dit heeft niks meer met goeie beveiliging te maken, dit is pure nalatigheid.

Het is wat je zegt, er wordt niet eens gekeken naar de mogelijkheden die je hebt, zoals de kluizen die je als service kan afnemen bij de cloud leveranciers. Onbegrijpelijk.

[Dracoz]

Ik vraag me af hoe dit de laatste tijd telkens kan.

[HADES2001]

laatste tijd? zie al briefjes op schermen geplakt met login wachtwoorden sinds de jaren 90. Het is met name luiheid dat mensen de makkelijkste weg kiezen. Een txt bestand opent makkelijker dan een password manager voor de gemiddelde digibeet

[madcon]

Wat jij luiheid noemt, zouden andere mensen kunnen bestempelen als efficiëntie. Door niet met elkaar in gesprek te gaan en te luisteren waarom een persoon kiest voor optie x terwijl vanuit beveiliging optie y veiliger zou zijn, zal hier ook geen verandering in op treden.

Echte digibeten tref je niet meer aan op de werkvloer. Als iemand kan werken in Excel dan komen zij ook wel uit een password manager.

[supersnathan94]

Nou als iemand goed kan werken met excel dan is een pw manager geen issue lijkt mij.

Het probleem met wachtwoord managers is ook een issue mbt usability en compatibility.

Ik werk met name in een Apple Ecosysteem, dus dan is iCloud keychain gewoon dikke prima. Als wat je zou willen hebben zit daar in. Maar ik heb ook 1 windows bak voor werk. Enige optie die je dan hebt zijn plugins voor edge en chrome. Dus niet voor native apps.

[mduijm]

Er is nu een Apple password app voor Windows. Super handig. Nu helemaal over op iCloud passwords.

De password tool mist 1 ding. De 2fa support. Hopen dat dat nog komt.

[supersnathan94]

Hee kijk. Helemaal top. Dankjewel die wist ik nog niet.

Edit:

Wacht ff. Als ik een beetje google dan kom ik gewoon uit op de iCloud app. Die heb ik nu ook draaien. Is er nog een andere applicatie? En zo ja waar haal ik die?

[Reactie gewijzigd door supersnathan94 op 27 juli 2024 13:04]

[cable_son]

ik vind deze:
nieuws: Apple geeft Windows-versie van iCloud-app functie om wachtwoorden te ....

[mduijm]

Check Idd.

Laatste versie iCloud en dan vindt je de tool in je startmenu.

[Lennyz]

Ja of de netwerkbeheerder die iedere 3 maanden verplicht om een nieuw wachtwoord te kiezen. Waardoor iedereen het oude wachtwoord met 1 cijfer omhoog plust. Vervolgens worden de briefjes met wachtwoorden op het beeldscherm gehangen. Maar daarbij geen 2fa implementeren, want dat is te moeilijk voor de medewerkers.

Dit gebeurde bij mijn laatste werkgever. Ik kan het de medewerkers niet eens kwalijk nemen. Het is bijna niet meer te onthouden.

[Reactie gewijzigd door Lennyz op 27 juli 2024 13:04]

[orvintax]

Dat is imho ook een idiote policy. Het is al zo vaak bewezen dat dit niet het gewenste effect heeft.

[PolarBear]

laatste tijd? zie al briefjes op schermen geplakt met login wachtwoorden sinds de jaren 90.

Dat is misschien niet de beste optie, maar het vereist in ieder geval nog fysieke toegang tot het briefje wat op het scherm is geplakt.

[oef!]

Omdat cloudgebruik/devops enorm toegenomen is de afgelopen jaren. Het beheer hiervan is radicaal anders dan dat van traditionele infra. Het gevolg is dat er meer fouten worden gemaakt.

[TimDJ]

Eerder ander soort fouten. Fouten worden overal gemaakt. Helemaal bij personeels tekort of tijdsdruk

[oef!]

Klopt, een ander soort fouten. Maar vroegah maakte je die fout op een intern netwerk en was je nog enigszins afgeschermd. Tegenwoordig staan de logins op github en in buckets.

[Keypunchie]

Het is niet dat dit de laatste tijd veel gebeurd. Dit gebeurde altijd al, recent zijn er wat zaken met meer publiciteit.

[stefan-tweakers]

Dit is overigens wel makkelijk af te vangen en op te lossen door SEGA. Oa Service Control policies, S3 public access blocks, config rules, cloud trail....

Dat mis ik hier: De weg naar hoe het zou moeten. Dit is simpel de vinger wijzen naar nu een organisatie maar wie weet is jouw organisatie de volgende.

[david-v]

De weg hoe het zou moeten is al minstens 20 jaar hetzelfde. Het probleem is dat mensen het allemaal te ingewikkeld vinden en Welkom01 of 1234567890 nog steeds prima vinden als wachtwoord.

Het is echt niet ingewikkeld. Een secret moet je alleen in je hoofd bewaren of op een locatie die daar voor bedoeld is. Keyvaults, secret managers enz.... Het woord geeft je al een hint.... Zo moet je dat dus doen. Een tekst bestandje ergens pleuren is nog nooit de juiste oplossing geweest, al werd het wel door iedereen gegaan.

Daarnaast heb je nog alle mogelijke beveiligingen die dit ondersteunen, zoals 2fa, auditing, privileged identity management ... noem maar op.

Ik blijf het nalatigheid noemen als je de fouten maakt die Sega heeft gemaakt. Dan heb je nog een hele lange weg te gaan als je dit soort basale beveiliging niet eens op orde hebt.

[Reactie gewijzigd door david-v op 27 juli 2024 13:04]

[iApp]

Veel bedrijven waar ik mee werk gebruiken de standaard Google Chrome wachtwoord manager. Moeten ze 2FA instellen, dan is ineens het hek van de dam. Ze snappen er niks van! Ik raad ze dan aan om in ieder geval de authenticator app, of beter: LastPass of 1Password te gebruiken.

Wat - denk ik - bij SEGA mist, is een ‘integraal’ beleid dat een centraal systeem als plek toewijst voor het opslaan van kritische informatie - zoals wachtwoorden, credentials en API keys. Dat valt goed in te regelen, maar er moet eerst over worden nagedacht (= iemand moet uren krijgen) en goedgekeurd worden (door het topmanagement). Daar loopt het vaak stuk: dat topmanagement weet helemaal niets van beveiliging; die S3 bucket is namelijk toch ook veilig? Ja, dat is wel wat AWS beweert; zolang je hem niet public maakt. En dat klopt: als alleen de juiste mensen de juiste permissies krijgen, en je af en toe een bash script draait dat de permissies controleert, kom je een heel eind. Maar ook dat kost tijd (en geld). Dus dan val je tussen wal en schip en ontstaan half afgemaakte situaties zoals in dit artikel.

Ach ja, als ze hun Cloud strategie net zo ontwikkeld hebben als hun games, is het bij versie v1.4 op redelijk niveau.

[Reactie gewijzigd door iApp op 27 juli 2024 13:04]

[david-v]

Even een kritische feedback op jouw verhaal. Als je voor het goed beveiligen van secrets het akkoord nodig hebt van het top management dan ben je als organisatie al heel fout bezig. Top management moet alleen een beleid vastleggen (bijvoorbeeld secrets moeten altijd veilig bewaard worden, 2fa is waar mogelijk verplicht). Dat is niet iets wat het topmanagement bepaald, maar de security afdeling. Top management is alleen om het door te drukken in de hele organisatie, niet om elke keer toestemming te geven als je iets veilig wilt opslaan.

Het is niet alsof je toestemming nodig hebt van top management om goeie software te schrijven, toch?

Edit:typos

[Reactie gewijzigd door david-v op 27 juli 2024 13:04]

[HerrPino]

Ik verwacht persoonlijk dat dit ook een stukje overblijfsel is van een transitiefase naar de cloud toe. Hebben we bij ons ook gezien. Eerst as-is overstappen. Daarna moeten de mensen nog overtuigd raken van bepaalde AWS services voordat ze durven af te stappen van tooltjes die net niet helemaal lekker integreren, maar wel functionaliteit bezitten die ze veelal niet nodig zouden moeten hebben/niet gebruiken. En waarvoor er gewoon een AWS oplossing is. Zoals de Secrets Manager of Certificate Manager.

[stefan-tweakers]

Wat bedoel je precies?

Dat organisaties en mensen fouten maken is al enkele duizenden jaren aan de gang. Dat is niet van de laatste tijd.