WebGoat / Crypto Basics

첫 번째 문제 - Base64 Encoding

첫 번째 문제를 번역기로 해석해 보니
Base64 인코딩
인코딩은 사실 암호학은 아니지만 암호화 기능과 관련된 모든 종류의 표준에서 많이 사용됩니다. 특히 Base64 인코딩이 그렇습니다.

Base64 인코딩은 모든 종류의 바이트를 특정 바이트 범위로 변환하는 데 사용되는 기술입니다. 이 특정 범위는 ASCII 읽기 바이트입니다. 이렇게 하면 비밀 키나 개인 키와 같은 이진 데이터를 더 쉽게 전송할 수 있습니다. 이러한 키를 출력하거나 적을 수도 있습니다. 인코딩도 가역적입니다. 따라서 인코딩된 버전이 있는 경우 원본 버전을 만들 수 있습니다.

위키백과에서 더 자세한 내용을 확인할 수 있습니다. 기본적으로 모든 바이트를 처리하여 각 6비트 세트를 읽기 쉬운 바이트(8비트)로 변환합니다. 그 결과 인코딩된 바이트의 크기가 약 33% 증가했습니다.

기본 인증
기본 인증은 때때로 웹 애플리케이션에서 사용됩니다. 이는 base64 인코딩을 사용합니다. 따라서 서버로 전송되는 사용자 이름 비밀번호를 읽지 않도록 다른 사람을 보호하기 위해 최소한 전송 계층 보안(TLS 또는 일반적으로 https로 알려진)을 사용하는 것이 중요합니다.

요약
1. base64는 엄밀히 말하면 암호화까지는 아니다.
2. 이진데이터를 쉽게 전송할 수 있다. 하지만 변환된 데이터 크기가 33% 증가한다.
3. 웹 애플리케이션 때때로 base64 인코딩을 사용하니 https를 사용해서 다른 사람이 서버에 전송된 사용자 이름, 비밀번호를 읽지 못하도록 보호하는 것이 중요하다.

문제를 확인해 보니
헤더를 가로챘다고 가정해 보겠습니다 : Authorization: MTIzMTIzOmFkbWlu 라고 base64 인코딩된 값이 하나 보입니다. 해당 값을 디코딩해서 풀어보겠습니다.
base64 디코딩

base64 디코딩 값

보아하니 :(콜론)을 기준으로 앞에는 ID(123123)인 거 같고 뒤에는 PW(admin) 같네요.

결과

이번 문제는 상당히 쉬웠네요. 다음으로 넘어가 보겠습니다.

두 번째 문제 - Other Encoding

두 번째 문제를 번역기로 해석해 보니
URL 인코딩
URL 인코딩은 폼 데이터와 요청 매개변수를 서버로 보낼 때 많이 사용됩니다. URL에는 공백이 허용되지 않으므로 %20, +으로 대체됩니다. 다른 문자에 대해서도 비슷한 대체가 이루어집니다.

HTML 인코딩
HTML 인코딩은 텍스트가 브라우저에서 HTML로 해석되지 않고 그대로 표시되도록 합니다. HTML에는 <, >, &, " 처럼 브라우저가 문법적으로 해석하는 예약어들이 있습니다. 만약 사용자 입력값(댓글 등)에 이런 문자가 포함되어 있는데 인코딩하지 않으면 다음과 같은 문제가 생깁니다.
1. 화면 깨짐 : 브라우저가 일반 텍스트를 HTML 태그로 착각하여 레이아웃이 무너집니다.
2. 보안 취약점 (XSS) : 악성 사용자가 <script> 태그를 주입하여 다른 사용자의 정보를 탈취하는 크로스 사이트 스크립팅(XSS) 공격에 노출될 수 있습니다.

현재 해당 글에도 HTML인코딩을 사용하고 있습니다. 여러분은 <script> 문자가 제대로 보이고 있겠지만 실제로 글을 작성하고 있는 필자는

위에 있는 사진에 나온거처럼 <script> 를 표현하고있습니다.

UUEncode
Unix-2-Unix 인코딩은 이메일 첨부 파일을 보내는 데 사용되었습니다. 하지만 UUEncode는 텍스트만 보낼 수 있던 구식 통신 환경에서 파일을 강제로 텍스트로 바꿔서 보내던 옛날 방식입니다. 현재는 더 안전하고 표준화된 Base64를 주로 사용합니다. ex) MIME - 현대 이메일 방식

XOR 인코딩
인코딩은 비밀번호를 저장하기 위한 최초의 간단한 난독화 기법으로 사용되기도 합니다. 예를 들어 IBM WebSphere Application Server는 특정 XOR 인코딩 구현을 사용하여 구성 파일에 비밀번호를 저장합니다. IBM은 이러한 파일에 대한 액세스를 보호하고 기본 XOR 인코딩을 사용자 지정 암호화로 대체할 것을 권장합니다. 그러나 이러한 권장 사항을 따르지 않으면 이러한 기본값이 취약점이 될 수 있습니다.

요약
1. 이러한 다양한 인코딩 방식이 있다. 그리고 우리는 알게 모르게 직/간접적으로 사용 중이다.

이제 문제를 확인해 볼까요?

문제에서는 xor인코딩된 문자열을 풀어서 해결하라는 거 같습니다. 해당 문제를 해결하기 위해서는 먼저 구글에서 websphere xor decoder를 입력하면 websphere에서 최초 설정 시 사용하는 xor인코딩 알고리즘을 참고해 인코딩 데이터를 디코딩 해주는 사이트가 나옵니다.

그다음 우리는 문제에서 제시한 xor인코딩된 값을 넣으면 디코딩된 값을 알아낼 수 있습니다.
디코딩 값 : databasepassword

결과

이렇게 xor인코딩된 값을 얻어서 해당 문제를 해결하였습니다.

세 번째 문제 - Plain Hashing/Salted Hashes

세 번째 문제를 번역기로 해석해 보니
Plain Hashing
해싱은 원본 데이터가 변경되었는지 여부를 감지하는 데 주로 사용되는 암호화 유형입니다. 해시는 원본 데이터에서 생성됩니다. 해시는 비가역적 암호화 기술을 기반으로 합니다. 원본 데이터가 단 한 바이트만 변경되면 결과 해시도 달라집니다.

따라서 어떤 면에서는 보안 기술처럼 보입니다. 하지만 비밀번호에 사용할 때는 그렇지도 않고 결코 좋은 해결책이 아닙니다. 여기서 문제는 사전에서 비밀번호를 생성하고 이러한 비밀번호에서 모든 종류의 변형을 계산할 수 있다는 것입니다. 각 비밀번호에 대해 해시를 계산할 수 있습니다. 이 모든 해시는 대규모 데이터베이스에 저장할 수 있습니다. 따라서 비밀번호일 수 있는 해시를 찾을 때마다 데이터베이스에서 해시를 찾아 비밀번호를 찾기만 하면 됩니다.

일부 해싱 알고리즘은 더 이상 사용해서는 안 됩니다: MD5, SHA-1 이러한 해싱의 경우 페이로드를 변경하여 동일한 해시를 생성할 수 있습니다. 이는 많은 컴퓨팅 성능을 필요로 하지만 여전히 실행 가능한 옵션입니다.

Salted Hashes
일반 비밀번호는 당연히 데이터베이스에 저장되어서는 안 됩니다. 일반 해시에도 마찬가지입니다. OWASP 비밀번호 저장 차트 시트는 비밀번호 관련 정보를 안전하게 저장해야 할 때 무엇을 사용해야 하는지 설명합니다.

요약
1. 단방향 암호화는 한쪽방향으로 암호화한다.
즉, 평문->암호화 O , 암호화 -> 평문 X
2. Hashing은 단방향 암호화 과정이다. 단방향 암호화 알고리즘 종류 ex) MD5, SHA-1, SHA-256, SHA-512
3. DB에 PW를 평문으로 넣지 말고 암호화해서 저장해라. 그리고 그 값을 해시랑 비교해서 찾아라.
4. MD5, SHA-1 알고리즘은 서로 해시값이 같을 수 있어서 쓰지 마라
예를 들면)
A.pw -> qwe123(MD5 알고리즘)
B.pw -> qwe123(SHA-1 알고리즘)
이렇게 돼버리면 A라는 사람의 비밀번호로 B 사용자로 로그인할 수 있다. -> 안정성이 떨어짐

이제 문제를 확인해 보겠습니다.

첫 번째, 두 번째 모두 해시값에 담긴 비밀번호를 찾는 문제입니다. 저는 해시값 복호화 사이트를 검색해서 나온 것 중에 웹사이트를 지원하는 곳을 찾았습니다.

이제 문제에서 제시한 해시값을 넣어서 비밀번호를 확인해 보겠습니다.
첫 번째 문제의 해시값은 MD5로 해시값을 만들었군요. 결괏값은 password 입니다.

두 번째 문제에서 해시값은 SHA-256으로 해시값을 만들었고, 결괏값은 passw0rd 입니다.

결과

알아낸 비밀번호를 입력해서 이번 문제를 해결하였습니다.

마무리

이번 실습에서는 다양한 인코딩 종류와 해시의 종류 왜 이런 것들을 사용하는지 알아보았습니다.