WebGoat / Spoofing an Authentication Cookie

첫 번째 문제 - Bypass the authentication mechanism by spoofing an authentication cookie.

첫 번째 문제를 번역기로 해석해 보니
로그인 시스템에 대한 참고 사항

인증 쿠키가 전송되면 해당 쿠키가 유효한 경우 시스템이 사용자에게 직접 로그인합니다.

쿠키가 전송되지 않고 제공된 자격 증명이 올바른 경우 시스템은 인증 쿠키를 생성합니다.

다른 경우에는 로그인이 거부됩니다.

공격 중에 받게 될 피드백 메시지에 주의하세요.

알려진 자격 증명:

user name	password
webgoat	webgoat
admin	admin

목표
인증 쿠키가 어떻게 생성되는지 이해했다면, 쿠키를 스푸핑하고 Tom으로 로그인해 보세요.

요약
1. 인증 쿠키를 우회하여 다른 사용자로 로그인해 보자.

Step 1 - webgoat 사용자로 로그인해 보기

먼저 문제에서 주어진 ID와 PW를 가지고 로그인을 시도해 보겠습니다. 이후 응답으로 어떤 값들이 보내지는지 확인해 보겠습니다.

Request

요청에는 위와 같이 ID와 PW에 webgoat를 넣어서 전달하였습니다.

Response

응답에서는 요청에서 온 자격 증명(ID와 PW)을 통해 새로운 쿠키값인 spoof_auth가 생성되는 걸 볼 수 있습니다. 그런데 생성된 쿠키값이 뭔가 낯이 익네요? 여러분도 그렇게 느껴지시나요?

Step 1.1 - Base 64 Encoding

혹시 여러분도 저처럼 생성된 쿠키값을 보고 Base64인코딩이 생각나셨나요? 모르셨어도 상관없습니다. 지금부터 간단하게 설명해 드리겠습니다.

Base64 개념

Base64는 8비트 이진 데이터(예: 이미지, 실행 파일 등)를 64개의 문자로 구성된 ASCII 문자열로 변환하는 인코딩 방식입니다.

Base64 작동 원리 (Encoding Process)

Base64는 데이터를 3바이트(24비트)씩 묶어서 처리하며, 이를 6비트씩 4개로 쪼개어 각각을 미리 정의된 64개의 색인표(A-Z, a-z, 0-9, +, /)에 매핑합니다.

• 2진수 변환: 원본 문자열을 8비트 2진수 데이터로 바꿉니다.

• 6비트 분할: 24비트 단위로 묶은 뒤, 이를 다시 6비트씩 4개로 나눕니다.

• 색인 매핑: 각 6비트 묶음을 10진수로 변환하여 Base64 색인표에서 해당 문자를 찾습니다.

• 패딩(Padding): 만약 원본 데이터가 3바이트 단위로 딱 떨어지지 않으면 부족한 부분을 0으로 채우고, 결과물 뒤에 = 기호를 붙여 데이터의 끝임을 알립니다.

제가 왜 생성된 쿠키값을 보고 익숙하다고 느껴진다고 그랬는지 이제 감이 오시나요? 쿠키값 "spoof_auth=NDY0YjRmNzA2ZTZhNTU3NjdhNzQ3NDYxNmY2NzYyNjU3Nw==" 확인해 보면 마지막 끝에 "==" 이렇게 부등호가 존재하죠? 보통 base64인코딩 과정에서 마지막 바이트에서 000000(6비트씩)으로 떨어진 값은 부등호로 표시하기 때문입니다. 그렇다면 해당 해시값이 base64인코딩 되어있다는 걸 알았으니, 디코딩도 한번 시도해 봐야겠죠?

Step 2 - Decoding

첫 번째 사진은 webgoat의 쿠키값입니다. 이제 해당 값을 base64디코딩하여 풀어보겠습니다.

base65 디코딩 => NDY0YjRmNzA2ZTZhNTU3NjdhNzQ3NDYxNmY2NzYyNjU3Nw==

두 번째 사진은 base64디코딩하여 나온 값입니다. 글씨가 작아서 잘 안 보이실 수 있으실 텐데 이 부분은 이해해 주시기 바랍니다.

base64 디코딩 결과값 => 464b4f706e6a55767a7474616f67626577

값을 확인해 보니 이번에는 기호가 없는 걸 보니 디코딩된 값이 16진수로 구성되어 있는걸 볼 수 있습니다. 이번에는 ASCII를 사용하여 16진수를 풀어보겠습니다.

ASCII 디코딩 => FKOpnjUvzttaogbew

값을 확인해 보니 FKOpnjUvzttaogbew 라는 값이 나왔는데요. 자세히 보니 뭔가 자주 사용했던 단어가 보입니다. 해당 문자열을 뒤에 자리 7자리를 뒤집어서 봐보니 webgoat라는 단어가 보이네요. 나머지 부분은 무작위 값인 거 같습니다. 그렇다면 여기서 쿠키값이 만들어지는 알고리즘을 유추를 해볼 수 있습니다. 아마도 앞에는 무작위 문자열을 넣고 뒤에는 해당 계정의 ID 값을 뒤집어서 같이 저장해서 먼저 16진수로 인코딩하고 그다음 base64 로 인코딩을 끝낸 거 같습니다. 아직 확실하지는 않으니, 마지막으로 admin 계정으로 로그인을 시도해 보겠습니다.

Step 3 - admin으로 로그인 및 디코딩

Request

마찬가지로 admin 계정으로 로그인을 요청했습니다.

Response

admin 계정도 쿠키값이 생성되었습니다. 이제 해당 값을 가지고 디코딩 해보겠습니다.

Decodig

admin 쿠키값 : NDY0YjRmNzA2ZTZhNTU3NjdhNzQ2ZTY5NmQ2NDYx

base64 디코딩 값 : 464b4f706e6a55767a746e696d6461

16진수 디코딩 값 : FKOpnjUvztnimda

역시 예상대로 FKOpnjUvztnimda 마지막 부분을 보면 해당 계정의 ID를 뒤집어서 사용한 모습을 확인할 수 있습니다.

요약
1. webgoat => webgoat + tzvUjnpOKF
2. admin => admin + tzvUjnpOKF
3. ID와 무작위 문자열을 합친 뒤 뒤집어서 인코딩하여 쿠키값을 만들었습니다.

그렇다면 이제 문제에서 Tom의 계정으로 로그인하고 싶으면 Tom + tzvUjnpOKF 값을 뒤집은 다음 FKOpnjUvztmoT 첫 번째로, 16진수로 인코딩합니다. 464b4f706e6a55767a746d6f54 마지막으로 base64로 인코딩합니다. NDY0YjRmNzA2ZTZhNTU3NjdhNzQ2ZDZmNTQ= 이제 해당 인코딩된 값을 쿠키에 담아 요청을 보내면 Tom 계정으로 로그인이 될 것입니다.

결과

Request

Response

이렇게 해서 해당 문제가 해결되었다.

마무리

이번 실습은 사용자의 쿠키값을 만들 때 유추가 가능하게 만든 알고리즘을 사용하면 어떤 문제점이 발생하는지에 대한 공격 방법을 알아보았습니다.