Was passiert, wenn Sie AWS-Anmeldedaten preisgeben und wie AWS den Schaden minimiert

Ich habe mehrfach gehört, dass AWS öffentliche GitHub-Repositories nach AWS-Anmeldeinformationen durchsucht und seine Benutzer über die durchgesickerten Anmeldeinformationen informiert.

Ich war neugierig und beschloss, die AWS-Anmeldeinformationen absichtlich an ein öffentliches GitHub-Repository weiterzugeben. Und ich zeige Ihnen, welche Schritte ich unternommen habe und wie ich über die durchgesickerten Zugangsdaten informiert wurde.

Einrichten der Anmeldeinformationen

Ich habe in meinem AWS-Konto einen IAM-Benutzer mit dem Namen test-user erstellt und für diesen Benutzer einen Zugriffsschlüssel und ein Geheimnis generiert und diesem Benutzer eine sehr begrenzte Richtlinie zugewiesen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListBucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::aws-leaked-credentials"
        }
    ]
}

Dann habe ich den AWS-Zugangsschlüssel und das Geheimnis auf GitHub übertragen . Sehen Sie hier den Commit:

Nachdem ich die Anmeldedaten an GitHub übermittelt hatte, passierten sehr schnell verschiedene Dinge, die ich im Folgenden aufzählen werde.

Zeitstempel und Ereignisse nach der Weitergabe der Anmeldeinformationen an GitHub

Hier finden Sie alle Ereignisse, die nach dem Pushen auf GitHub eingetreten sind.

12:33:12 - Die Anmeldeinformationen an GitHub übertragen

12:34:19 - Die Richtlinie AWSCompromisedKeyQuarantineV2 ist mit dem IAM-Benutzer test-user von AWS verbunden.

12:34:32 - Verschiedene Listen- und Beschreibungsaufrufe werden mit den durchgesickerten Anmeldedaten getätigt

12:35:08 - Ich habe eine E-Mail von AWS mit dem Betreff 'ACTION REQUIRED: Ihr AWS-Zugangsschlüssel ist für das AWS-Konto offengelegt 12345678'

Wie Sie sehen können, hat AWS 1 Minute und 7 Sekunden nach dem Bekanntwerden der Anmeldedaten die Richtlinie AWSCompromisedKeyQuarantineV2 hinzugefügt. Da AWS IAM schließlich konsistent ist, konnte der böswillige Akteur verschiedene API-Aufrufe durchführen, auch nachdem die Richtlinie AWSCompromisedKeyQuarantineV2 hinzugefügt wurde. Glücklicherweise war dies nur von kurzer Dauer, da IAM nur eine geringe Verzögerung aufweist, bis Änderungen wirksam werden. 2 Minuten nach dem Bekanntwerden der Anmeldedaten erhielt ich eine E-Mail von AWS, in der ich über den Vorfall informiert wurde und Anweisungen zur Sicherung des Kontos erhielt.

Nachstehend finden Sie detaillierte Informationen zu jeder Veranstaltung.

Politik im Anhang von AWS

Die AWSCompromisedKeyQuarantineV2 ist mit dem IAM-Benutzer test-user verbunden. Diese Richtlinie verweigert die wichtigsten Aktionen. Aber wenn die durchgesickerten Anmeldeinformationen viele Berechtigungen haben, kann der böswillige Akteur immer noch Schaden an Systemen anrichten, die unter dem AWS-Konto laufen.

Siehe die Richtlinien unten:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:LookupEvents",
        "ec2:RequestSpotInstances",
        "ec2:RunInstances",
        "ec2:StartInstances",
        "iam:AddUserToGroup",
        "iam:AttachGroupPolicy",
        "iam:AttachRolePolicy",
        "iam:AttachUserPolicy",
        "iam:ChangePassword",
        "iam:CreateAccessKey",
        "iam:CreateInstanceProfile",
        "iam:CreateLoginProfile",
        "iam:CreatePolicyVersion",
        "iam:CreateRole",
        "iam:CreateUser",
        "iam:DetachUserPolicy",
        "iam:PassRole",
        "iam:PutGroupPolicy",
        "iam:PutRolePolicy",
        "iam:PutUserPermissionsBoundary",
        "iam:PutUserPolicy",
        "iam:SetDefaultPolicyVersion",
        "iam:UpdateAccessKey",
        "iam:UpdateAccountPasswordPolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateLoginProfile",
        "iam:UpdateUser",
        "lambda:AddLayerVersionPermission",
        "lambda:AddPermission",
        "lambda:CreateFunction",
        "lambda:GetPolicy",
        "lambda:ListTags",
        "lambda:PutProvisionedConcurrencyConfig",
        "lambda:TagResource",
        "lambda:UntagResource",
        "lambda:UpdateFunctionCode",
        "lightsail:Create*",
        "lightsail:Delete*",
        "lightsail:DownloadDefaultKeyPair",
        "lightsail:GetInstanceAccessDetails",
        "lightsail:Start*",
        "lightsail:Update*",
        "organizations:CreateAccount",
        "organizations:CreateOrganization",
        "organizations:InviteAccountToOrganization",
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration",
        "s3:PutBucketAcl",
        "s3:PutBucketOwnershipControls",
        "s3:DeleteBucketPolicy",
        "s3:ObjectOwnerOverrideToBucketOwner",
        "s3:PutAccountPublicAccessBlock",
        "s3:PutBucketPolicy",
        "s3:ListAllMyBuckets",
        "ec2:PurchaseReservedInstancesOffering",
        "ec2:AcceptReservedInstancesExchangeQuote",
        "ec2:CreateReservedInstancesListing",
        "savingsplans:CreateSavingsPlan"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

CloudTrail Ereignis

In den us-east-1 CloudTrail-Protokollen können Sie sehen, dass ein AttachUserPolicy API-Aufruf erfolgt, um die Richtlinie AWSCompromisedKeyQuarantineV2 anzuhängen. Im Ereignisprotokoll steht eindeutig, dass dies von AWS "invokedBy": "AWS Internal" aufgerufen wurde.

CloudTrail Ereignis:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAxxxxxxxxx",
        "arn": "arn:aws:iam::xxxxxxxxx:user/test-user",
        "accountId": "xxxxxxxxx",
        "accessKeyId": "ASIAxxxxxxxxx",
        "userName": "test-user",
        "sessionContext": {
            "sessionIssuer": {},
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2023-03-21T11:34:19Z",
                "mfaAuthenticated": "false"
            }
        },
        "invokedBy": "AWS Internal"
    },
    "eventTime": "2023-03-21T11:34:19Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "AttachUserPolicy",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "AWS Internal",
    "userAgent": "AWS Internal",
    "requestParameters": {
        "userName": "test-user",
        "policyArn": "arn:aws:iam::aws:policy/AWSCompromisedKeyQuarantineV2"
    },
    "responseElements": null,
    "requestID": "7b163d6c-xxxxxxxxx",
    "eventID": "c3eda312-xxxxxxxxx",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "xxxxxxxxx",
    "eventCategory": "Management"
}

Bösartiger Schauspieler?

Ich fand es überraschend, wie schnell der böswillige Akteur einige automatisierte API-Aufrufe mit den durchgesickerten Anmeldeinformationen gemacht hat. Das bedeutet, dass sie die öffentlichen Repositories von GitHub ständig nach durchgesickerten Anmeldeinformationen durchsuchen.

Der verwendete Benutzeragent war aws-sdk-go-v2/1.17.1. Sie haben also wahrscheinlich ein automatisiertes Tool, das durchgesickerte Anmeldeinformationen erkennt und das AWS-Konto nach Ressourcen durchsucht. In der Abbildung unten sehen Sie die verschiedenen API-Aufrufe, die sie getätigt haben, zum Glück ohne Erfolg, da sie nicht über die Berechtigungen für diese API-Aufrufe verfügten.

Nachfolgend finden Sie das CloudTrail-Protokoll des ListCertificates API-Aufrufs:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAxxxxxxxxx",
        "arn": "arn:aws:iam::xxxxxxxxx:user/test-user",
        "accountId": "xxxxxxxxx",
        "accessKeyId": "AKIAYUBS5O3BYC7WBJWO",
        "userName": "test-user"
    },
    "eventTime": "2023-03-21T11:34:36Z",
    "eventSource": "acm.amazonaws.com",
    "eventName": "ListCertificates",
    "awsRegion": "eu-west-1",
    "sourceIPAddress": "3.xxx.xx.xxx",
    "userAgent": "aws-sdk-go-v2/1.17.1 os/linux lang/go/1.18.10 md/GOOS/linux md/GOARCH/amd64 api/acm/1.15.2",
    "errorCode": "AccessDenied",
    "errorMessage": "User: arn:aws:iam::xxxxxxxxx:user/test-user is not authorized to perform: acm:ListCertificates because no identity-based policy allows the acm:ListCertificates action",
    "requestParameters": null,
    "responseElements": null,
    "requestID": "b83e5733-xxxxxxxxx",
    "eventID": "37d59144-xxxxxxxxx",
    "readOnly": true,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "xxxxxxxxx",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "acm.eu-west-1.amazonaws.com"
    }
}

E-Mail von AWS

Innerhalb von zwei Minuten nach dem Bekanntwerden der Zugangsdaten erhielt ich eine E-Mail von AWS, in der mir mitgeteilt wurde, dass die Zugangsdaten geleakt wurden. Sehen Sie den ersten Teil der E-Mail unten:

Hallo, Wir haben festgestellt, dass der AWS-Zugangsschlüssel AKIAYUBS5O3BYC7WBJWO , der dem IAM-Benutzer test-user gehört, zusammen mit dem entsprechenden geheimen Schlüssel online unter https://github.com/tiborhercz/aws-leaked-credentials/blob/33b4d387e94e16b1c8b9277056299bdb02de3a4b/credentials.txt öffentlich zugänglich ist. Ihre Sicherheit ist uns wichtig, und die Offenlegung der IAM-Anmeldedaten Ihres Kontos stellt ein Sicherheitsrisiko für Ihr AWS-Konto dar, könnte zu überhöhten Gebühren aufgrund unbefugter Aktivitäten führen und verstößt gegen die AWS-Kundenvereinbarung oder eine andere Vereinbarung mit uns, die Ihre Nutzung unserer Services regelt. Um Ihr Konto vor übermäßigen Gebühren und unbefugten Aktivitäten zu schützen, haben wir die AWS Managed Policy "AWSCompromisedKeyQuarantineV2" ("Quarantine Policy") auf den oben aufgeführten IAM-Benutzer angewendet. Die auf den Benutzer angewendete Quarantäne-Richtlinie schützt Ihr Konto, indem sie den Zugriff auf Aktionen mit hohem Risiko wie iam:CreateAccessKey und ec2:RunInstances verweigert. Sie können alle Aktionen, die von der Richtlinie verweigert werden, hier einsehen: https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCompromisedKeyQuarantineV2$jsonEditor?section=permissions.

In der E-Mail finden Sie auch eine Anleitung, wie Sie Ihr Konto sichern können. Sie tun dies in vier Schritten: 1. Drehen und löschen Sie den exponierten AWS Access Key AKIAYUBS5O3BYC7WBJWO 2. Überprüfen Sie Ihr CloudTrail-Protokoll auf nicht genehmigte Aktivitäten 3. Überprüfen Sie Ihr AWS-Konto auf nicht autorisierte AWS-Nutzung 4. Sie müssen auf den bestehenden Support-Fall reagieren oder einen neuen erstellen, um die Durchführung der oben genannten Schritte zu bestätigen, damit der Zugriff auf Ihr Konto wiederhergestellt, die Sperrung verhindert und gegebenenfalls eine Rechnungsanpassung beantragt werden kann.

Wie erreicht AWS dies?

Wie AWS so schnell reagiert, wenn Anmeldeinformationen durchgesickert sind, weiß ich nicht genau, denn ich habe keine Bestätigung von AWS selbst.

Sie könnten dies erreichen, indem Sie den GitHub-Dienst "Secrets Scanning" nutzen und die Option "Secret scanning alerts for partners" verwenden. GitHub meldet dann durchgesickerte Geheimnisse an diese Partner. Wenn diese Meldung eingeht, verfügt AWS über ein automatisches System, das die Richtlinie AWSCompromisedKeyQuarantineV2 hinzufügt, die E-Mail versendet und ein Support-Ticket eröffnet.

Fazit

Wenn AWS-Anmeldeinformationen an GitHub weitergegeben werden, verfügt AWS über Sicherheitsvorkehrungen, die Sie schützen. AWS und die böswilligen Akteure reagieren beeindruckend schnell auf die durchgesickerten Anmeldeinformationen und ergreifen beide sofort Maßnahmen. AWS benachrichtigt den Root-Benutzer und fügt dem IAM-Benutzer eine Verweigerungsrichtlinie hinzu. Der böswillige Akteur beginnt, das Konto nach Ressourcen zu durchsuchen, die er ausnutzen kann.

Es ist sehr schön, dass AWS seine Benutzer auf diese Weise schützt, aber wir könnten das Durchsickern der Anmeldeinformationen besser verhindern. Es gibt verschiedene Möglichkeiten, das Durchsickern der Zugangsdaten zu verhindern. - Sie könnten einen lokalen Pre-Commit-Scan nach Geheimnissen durchführen, bevor Sie sie an GitHub pushen - Fügen Sie einen Geheimnis-Scanner in Ihre CI/CD-Pipeline ein - Das GitHub Geheimnis-Scanning für Benutzer Konfigurieren des Geheimnis-Scannings für Ihre Repositories