Wyciek poświadczeń - i jak sobie z nim poradzić?

Skoro już tu jesteś, zakładam, że pojęcie Secure Token Service (STS) nie jest Ci obce. Zakładam też, że szukasz sposobu na unieważnienie sesji używającej tymczasowego klucza (AKIA), którego nie ma przecież jak unieważnić, skoro nie mamy do niego dostępu (wygenerowany klucz nie jest przechowywany po stronie AWS).

O co właściwie chodzi?

Osoba/usługa nabywa tymczasowych uprawnień wykonując tzw. sts:AssumeRole, otrzymuje tymczasowe dane logowania, które wygasają dopiero wtedy, gdy skończy się ich czas życia i otrzymuje uprawnienia zgodne z Policy podłączonym do tej Role.

Kilka informacji, zanim pójdziemy dalej

• Role może być “assumowana” przez wiele tożsamości/aktorów;
• w ramach tej samej Roli, otrzymujemy te same uprawnienia;
• tymczasowe poświadczenia (ang. credentials) nie mogą być unieważnione (no, bo jak?);
• Poświadczenia będą ważne tak długo, na jak długo ustawiony został czas życia w obrębie roli. Nie mamy możliwości zdalnego, ręcznego odwołania tymczasowych poświadczeń.

Załóżmy zatem, że atakujący w jakiś sposób uzyskał poświadczenia, np. poprzez źle skonfigurowany debug mode aplikacji, który pokazuje tymczasowe klucze ASIA* całemu światu. Być może nasze EC2 nadal pozwala na pobranie metadanych (sprawdź wersję serwisu metadanych) bez uwierzytelnienia i akurat nasza aplikacja podatna jest na atak typu SSRF. Jakkolwiek - atakujący w naszym scenariuszu po prostu znalazł poświadczenia, co więcej, nie jest też w stanie sam ich wygenerować. Jeśli nie naprawimy miejsca wycieku, atakujący nadal będzie w stanie je otrzymać, gdy te wygasną.

Jak to naprawić?

• Zmiana “Trust policy” w obrębie Roli jest zapewne konieczna, jednak nie będzie miała efektu na obecnie istniejących, prawidłowych poświadczeniach, które atakujący przecież posiada.
• Zmiana “Permissions”, wraz z użyciem akcji Deny zadziała, jednak jeśli Rola używana jest przez wielu aktorów (klaster serwerów), wtedy zabronimy dostępu wszystkim aktorom w jednym czasie.

Mam jednak inną opcję

Gdy naprawimy już nasze Trust policy, a zanim naprawimy samą aplikację, możemy użyć inline policy, której nadamy nazwę AWSRevokeOlderSessions, z akcją ustawioną na DENY. Spowoduje to unieważnienie wszystkich sesji, które zostały nawiązane do tej pory, a upoważnieni aktorzy mogą nadal odnowić, bądź pobrać nowe poświadczenia.

Jak to zrobić?

Możemy utworzyć nową Inline policy i umieścić poniższy kod. Potrzebne są uprawnienia PutRolePolicy na tej Role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "*"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "DateLessThan": {
          "aws:TokenIssueTime": "[policy creation time]"
        }
      }
    }
  ]
}

[policy creation time] - tutaj podajemy datę w formacie:

np. 2020-12-01T16:04:12.670Z

Możemy też zalogować się do konsoli AWS i po wybraniu Role, która nas interesuje, przejść do zakładki Revoke sessions i kliknąć przycisk Revoke active sessions, gdzie po potwierdzeniu (musimy zatwierdzić akcję, zaznaczając odpowiednie pole), polisa zostanie utworzona jako Inline policy w obrębie naszej Role.

Ta akcja nie powiedzie się dla tzw. service-linked role.

Jak widać w przykładzie, odbieramy wszelkie uprawnienia dla sesji, które rozpoczęły się przed datą/godziną wystawienia tokena.

To działanie naprawcze, jednak problem leży gdzie indziej i warto się nim zaopiekować na poważnie.

A co, jeśli mamy stały klucz (AKIA), który wyciekł?

Należy go jak najszybciej unieważnić. Pozostaje pytanie: jak wyciekł? Samo unieważnienie nic nie da, jeśli atakujący jest w stanie otrzymać nowy zestaw poświadczeń w ten sam sposób, co poprzednio.

Jeszcze jedna sprawa.

AWS__ACCESS__KEY

W powyższym przykładzie użyłem nazw kluczy, które rozpoczynają się identyfikatorem typu klucza. Zatem - jakie inne nazwy identyfikatorów kluczy są wykorzystywane w AWS? Kompletną listę znajdziecie w dokumentacji AWS, a poniżej podaję dwa najbardziej popularne.

• AKIA - standardowe poświadczenie tworzone w ramach użytkownika,
• ASIA - tymczasowe poświadczenie wykorzystywane wraz z dodatkowym tokenem.

Odnośniki:

1. Revoking IAM role temporary security credentials
2. Configuring the instance metadata service
3. AWS service-linked role
4. Disabling permissions for temporary security credentials

Zdjęcia:

1. Unsplash