1. Crypto Basics
웹 애플리케이션에서 일반적으로 사용되는 다양한 유형의 암호화 기술과 취약점에 대해 알아보자.
2. 모의 해킹
1) Base64 인코딩 방식
먼저 Base64의 인코딩 방식에 대해 알아보기 위해 ABCD를 인코딩을 해보자.
A,B,C,D에 각각 맞는 아스키 코드를 바이너리값으로 바꾼다. 그리고 8비트씩 묶여있는 것을 6비트씩 다시 묶은 후 10진수로 바꾼다. 그 후 그 숫자에 맞는 문자를 Base64 색인표에서 찾아 나열한다.
이때 자리수가 6개씩 나누어 떨어지지 않은 경우가 있는데 빈자리는 0으로 모두 채워주고 인코딩 된 값에 추가된 2비트당 =를 붙여 준다. 아래의 예시의 경우 4개의 비트가 추가되었으므로 다음과 같이 QUJDRA== 라는 결과가 나온다.
이처럼 Base64는 인코딩 방법은 단순해서 인코딩의 역순으로 진행하면 그대로 디코딩되어 원문을 알아낼 수 있어 암호화보다는 단순 인코딩 방법 중 하나이다.
Https의 경우 중요한 데이터가 네트워크 상에 평문으로 노출되지 않도록 암호화한 후 이중으로 자체적으로 암호화하는 것을 권고한다. 만약 이때 Base64 인코딩을 하게 된다면 이중으로 암호화했다고 볼 수 없게된다.
그럼 1번 문제를 보면 Base64 인코딩된 문자가 주어졌다.
이걸 다음과 같이 decoder를 이용하면 쉽게 아이디와 비밀번화를 알아낼 수 있다.
이 예제로 Base64 인코딩은 민감한 정보를 담기에는 적절하지 않은 방법이라는 것을 기억하자.
2) URL 인코딩
URL 인코딩은 서버에 데이터를 전달할 때 예약어나 특수문자, 한글 같은 것들을 안전하게 전달할 수 있도록 하는 인코딩 방식이다.
인코딩 방법은 문자를 16진수로 변환해 %뒤에 붙여서 사용된다. 한글의 경우도 UTF-8 방식으로 바이트를 배열해 16진수로 나타내 표현한다.
ex) " " -> %20(공백),
3) HTML Entity 인코딩
HTML Entity 인코딩은 HTML파일을 작성할 때 '<','>' 과 같은 예약어를 화면에 그대로 표현하고 싶을 때 사용된다.
| 문자 | Entity 이름 | Entity 번호 |
|---|---|---|
| < | lt | 60 |
| > | gt | 62 |
| " | quot | 34 |
| < | apos | 39 |
이름의 경우 &이름;, 숫자로 표현할 경우 &#숫자; 로 표현한다.
ex) < -> < or <
4) XOR 인코딩
XOR 인코딩은 원문과 Key값을 비트에서 XOR연산을 통해 새로운 비트를 만들어낸다. 이전에 설명했던 인코딩과는 다르게 꽤 복잡하여 XOR암호화라고 부르지만 정보를 보호해줄 만큼 알고리즘이 복잡하지 않아 key를 쉽게 추측할 수 있어 믿을만한 암호화는 아니라고 한다.
특히 XOR 인코딩를 사용하는 IBM WebSphere의 경우 시스템 초기에 설정된 암호화방식이 모두 같기 때문에 초기설정값을 바꿔주지 않으면 쉽게 보안성을 잃을 수 있다.
그럼 IBM WebSSphere처럼 초기설정을 바꾸지 않았을 때 XOR 인코딩을 풀어보자.
위에 주어진 XOR인코딩을 Websphere Xor Decoder사이트에서 디코딩을 하면 쉽게 비밀번호를 얻을 수 있고 문제를 해결할 수 있다.
이런 XOR과 같은 대칭키 암호화의 경우 대칭키로 암호화 복호화가 이루어지기 때문에 위의 예시처럼 대칭키가 쉽게 유출될 수 있는 상황을 만들지 않도록 잘 관리해야한다.
5) 단방향 암호화
마지막으로 단방향 암호화는 한방향으로만 암호화할 수 있고 다시 복호화할 수 없는 암호화이다.
이 단방향이라고 해서 마냥 좋은 것만은 아니다. 만약 Hash값이 충분히 길지 못하다면 2개의 데이터에 같은 hash값이 만들어 질 수도 있다.
만약 A사용자의 a라는 비밀번호와 B사용자의 b라는 비밀번호를 암호화했는데 둘다 c라는 결과물이 나왔다면 A와B는 서로의 비밀번호로 로그인을 할 수 있게 된다. 이렇게 같은 결과물이 나오지 않도록 하는 것을 충돌 저항성이라고 한다.
충돌 저항성을 유지하기 위해서 Hash데이터 길이가 최소 256bit 이상인 SHA256, SHA512 사용을 권장한다고 한다. 반면 MD5, SHA1과 같은 경우 Hash 데이터 길이가 충분히 길지 않아서 사용을 권장하지 않는다.
그럼 이런 단방향 암호화의 원문은 어떻게 알아낼 수 있을까? 단방향 알고리즘은 암호화 방법이 공개되어 있어 해커들은 수많은 경우의 암호하를 해서 데이터베이스에 원문과 암호화한 결과를 저장한 후 원문을 찾아내는 Rainbow table기법을 사용한다고 한다.
이런 경우 원문 뒤에 임의의 문자열을 추가해 복잡성을 높이는 Salt를 사용하여 방지할 수 있다. 하지만 Salt값이 유출된다면 역시 무용지물이 될 수 있으니 관리에 유의해야한다.
이번에 주어진 문제는 Salt를 사용하지 않은 Hash로 Rainbow Table공격 기법을 사용해보자.
Rainbow Table기법은 crackstation이라는 사이트에서 다음과 같이 쉽게 사용할 수 있다. 주어진 Hash 값을 각각 입력해주면 많은 원문과 Hash값을 가진 데이터베이스에서 원문을 얻어와 문제를 해결할 수 있다.
6) 대칭키, 공개키
대칭키는 XOR처럼 같은 키로 암호화, 복호화가 이루어 진다. 이경우 대칭키의 길이가 짧으면 무작위 대입법으로 위험성이 있을 수 있다. 따라서 키의 길이가 최소 256bit 이상인(AES256) 것을 이용하길 권장한다.
공개키는 암호화는 모두가 아는 공개키로, 복화화는 나만 아닌 개인키를 이용하는 방법이다. 이는 무작위 대입 공격으로부터는 상대적으로 안전하지만 알고리즘이 복잡해 대칭키에 비해 암호화, 복호화하는 과정에서 시간이 다소 걸린다는 단점이 있다.
공개키의 단점은 다음과 같이 하이브리드 방식으로 보안성과 속도를 모두 충족할 수 있다. 원문은 대칭키로 암호화하고 이 대칭키를 수신자의 공개키로 암호화한다.
수신자는 개인키로 대칭키를 복호화하고 그 대칭키로 복호화를 진행하여 원문을 얻을 수 있다.
하이브리드방식이 왜 빠른가?
생각을 해보면 공개키방식과 하이브리드 방식은 공개키로 암호화 개인키로 복호화 과정이 한 번씩 얼어난다. 그런데 왜 하이브리드 방식이 빠른 걸까?
그 이유는 복호화하는 대상이 다르기 때문이다. 공개키의 경우에는 원문의 데이터의 크기가 GB단위일 수 있다. 반면 하이브리드의 암호화 대상인 대칭키는 길어야 256bit정도로 짧기 때문에 속도차이가 발생한다.
3. 정리
Base64, URL 인코딩, XOR, 단방향, 대칭키, 공개키 등의 암호화, 인코딩 방법을 정리해 보았다.
모든 암호화, 인코딩 방법에는 장단점이 있고 이를 고려해 상황에 맞게 적절하게 사용해야 한다.
