Jak unieważnić temporary session token?

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 bez uwierzytelnienia i akurat nasza aplikacja podatna jest na atak typu SSRF. Jakkolwiek - atakujący w naszym scenariuszu po prostu znalazł poświadczenia.

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.

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

Identyfikatory kluczy AWS

W AWS klucze identyfikowane są prefiksem. Kompletną listę znajdziecie w dokumentacji AWS, a poniżej dwa najpopularniejsze:

• 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. Disabling permissions for temporary security credentials