(WebGoat) A1. Broken Access Control - Spoofing an Authentication Cookie

이번 퀴즈는 인증쿠키 스푸핑을 통한 인증우회 방법에 대한 내용이다.

주어진 내용은 webgoat, admin 계정과 패스워드를 제공해주고 있으며, 이때 Tom 계정으로 스푸핑을 진행하는 것이다.

 

 

우선 주어진 계정정보를 통해 어떤 쿠키가 생성되고 있는지 확인해보자

webgoat 계정

admin 계정

 

다음으로 로그인 시 다른 계정의 인증토큰을 함께 넣었을 때, 어떻게 반응하는지 확인해보자

admin 계정으로 로그인 시도

admin 로그인 요청 패킷에 webgoat의 인증토큰을 추가하여 요청 진행

위 스크린샷을 보는 것처럼, 전달한 계정정보와 상관없이 인증쿠키가 있을 경우, 인증쿠키를 통해 로그인이 진행된 것을 확인할 수 있다.

그렇다면 퀴즈의 의도는 인증쿠키의 값에 계정정보 등이 포함되어 결정되고 있어, 해당 패턴을 유추하여 특정 계정에 해당하는 인증쿠키를 생성하여 인증로직을 우회하는 것일 것이다.

 

그럼 인증쿠키가 어떻게 생성되고 있는지 확인해보도록 한다. 아래는 각 계정에 대한 인증쿠키이다.

계정	인증쿠키
webgoat	NzE0ZTcxNjc2NTdhNDM2NjczNzQ3NDYxNmY2NzYyNjU3Nw==
admin	NzE0ZTcxNjc2NTdhNDM2NjczNzQ2ZTY5NmQ2NDYx

 

 

여기서 webgoat의 인증쿠키가 '==' 으로 끝나는 것을 보았을 때 Base64로 인코딩 되어 있는 것으로 보인다.

우선 webgoat의 인증쿠키를 디코딩 해보자

 

인증쿠키를 Base64로 디코딩 후 ASCII Hex로 디코딩해보니, 'qNqgezCfsttaogbew' 이라는 값이 나왔다.

동일한 방법으로 Admin의 인증쿠키를 디코딩 해보니, 'qNqgezCfstnimda' 이라는 값이 나왔다.

 

두 값을 비교해보니, qNqgezCfst 값이 고정되어 있고, 그 뒤의 값만 다른 것을 알 수 있다.

그리고 각 값은 계정명을 Reverse한 것을 확인할 수 있었다.

• qNqgezCfsttaogbew = qNqgezCfst + taogbew(webgoat reverse)
• qNqgezCfstnimda = qNqgezCfst + nimda(admin reverse)

 

그렇다면 이제 tom의 계정명에 해당하는 인증토큰을 위에서 확인한 방법과 순서를 반대로 하여 진행해보자

=> Base64(ASCII Hex("qNqgezCfst" + str.reverse("tom"))

=> NzE0ZTcxNjc2NTdhNDM2NjczNzQ2ZDZmNzQ=

 

그럼 이제 이 값을 사용하여 로그인을 시도해보자.

tom의 인증쿠키를 전달하여 로그인 시도

 

이렇게 Tom의 인증토큰을 생성하여 Tom의 인증 스푸핑에 성공하였다.

 

 

소스코드에서 다시 내용을 확인해보자

아래 소스코드를 확인해보면, 앞서 확인되었던 것 처럼, Cookie 의 존재여부에 따라 인증 프로세스가 다르게 구성되어 있는 것을 알 수 있다.

src/main/java/org/owasp/webgoat/lessons/spoofcookie/SpoofCookieAssignment.java

 

로그인에 성공했을 때에는 쿠키값 생성 시 Login ID (username)가 사용되고 있는 것 또한 확인할 수 있다.

src/main/java/org/owasp/webgoat/lessons/spoofcookie/SpoofCookieAssignment.java

 

인증 쿠키는 Login ID를 소문자로 변경 후 임의의 Salt 값을 붙이고 역순으로 변경 뒤 Hex값으로 변환 후 Base64 인코딩을 하고 있는 것을 알 수 있었다.

src/main/java/org/owasp/webgoat/lessons/spoofcookie/encoders/EncDec.java

 

 

 

이러한 소스코드에서의 몇가지 취약점이 존재한다.

 

첫 번째로 인증쿠키값을 생성 시 직접 쿠키값을 생성하고 있다는 것이다. 인증값은 이번 퀴즈와 마찬가지로 특정 유저를 식별하거나 패턴을 파악하여 직접 생성하여 인증도용이 불가능하도록 유추가 불가능한 임의의 값이 사용되어야 한다. 하지만, 이 소스코드에서는 고정된 SALT값과 로그인ID를 인코딩만 하여 사용하고 있었기 때문에 문제가 되었다. 이러한 문제가 발생되지 않도록 직접 구현보다는 안전하다고 알려진 세션ID 생성 API를 이용하는 것이 보다 안전하게 구현할 수 있는 방법이 된다.

 

두 번째는 고정된 SALT값이 사용되었다는 것이다. 이번 로직에서 SALT는 조금 더 유추가 불가능한 값을 생성하기 위해 SALT를 적용하였는데, 여기서 SALT값이 고정되어 있기 때문에, 사실상 유추가 가능하다. 만약 SALT를 적용하여 값을 생성해야 한다면, 고정되지 않은 SALT값을 사용하여 유추가 불가능해야 할 것이다.

 

세 번째는 전달된 세션에 대한 검증 부재이다. 세션기반의 인증을 사용할 때, 서비스의 목적과 중요도에 따라 세션에 대한 검증이 반드시 필요하다. 이 경우에는 로그인을 하지 않은 유저에 대한 세션이 사용되었지만, 해당 세션이 사용되었다. 하지만 실제 인증세션이 전달되었을 때는 세션 스토리지에서 해당 세션이 실제 존재하는지(로그인 유저에 의해 생성된 세션인지) 확인하는 프로세스가 존재해야 한다. 또한 만약 해당 서비스가 중요서비스인 경우라면, 세션 내 저장된 IP 등을 이용하여 요청자가 해당 세션에 대한 소유자인지 검증도 추가되어야 한다. 마지막 부분은 NAT 사용에 따라 정상적으로 작동되지 않는 부분이 존재한다. 이런 경우 브라우저 핑거프린팅을 이용하면 좀 더 안전하게 구현이 가능하다.