Oracle Padding Attack
oracle padding attack에서 오라클은 흔히 알려진 데이터베이스의 이름으로 쓰여진 것이 아니라 "응답에 대한 판독" 과 같은 뜻으로 쓰였다.
즉 padding이 올바르게 되었는지 여부에 따라 서버의 응답이 다르기 때문에 이것을 이용한 공격을 말한다.
흔히들 알고있는 것 처럼 padding이란 블록암호화에서 모자른 부분들, 즉 틀에서 채우고 남은 부분을 채워주는 것을 말한다.
그 예로,
EX 1을 보면 평문이 3바이트 일 경우 나머지 5바이트를 패딩(0X05)로 채우고 있다.
EX 2 또한 평문이 BANANA인 6바이트 일 경우 나머지 2바이트를 패딩 (0X02)로 채우고 있다.
EX 4인 8바이트 일 경우 나머지 8바이트를 padding으로 채운다는 것이 중요하다.
즉 모든 블록암호화에서는 적어도 한 바이트 이상의 패딩이 들어간다는 것을 알 수 있다.
여기서 CBC모드를 알아야 하는데 CBC란 (Cipher-Block Chaining)의 약자로 서로 엮여 있는 암호 블록이라는 의미이다.
그 예를 그림으로 보자.
위의 그림은 CBC방식으로 암호화 하는 방법이다.
위의 그림은 CBC방법으로 복호화 하는 방법이다.
위의 그림들과 같이 암호화,복호화시 첫 블록의 암호화 값이 두번째 블록에 영향을 미친다.
그리고 첫번째 블록을 암호화 복호화 할 때에는 IV(이니셜 벡터)가 암호문 대신 사용되는 것을 볼 수 있다.
서버응답의 종류
패딩 오라클 공격을 성공하기 위해서는 서버의 응답을 구별하는 능력이 필수적이다.
예로 CBC모드의 블록 암호화를 사용하는 어플리케이션에 조작된 암호문 값을 입력 하였을 경우 서버는 각기 다른 반응을 보이게 된다.
1. 어플리케이션에서 올바른 암호화 값을 받았을 경우(200 OK)
2. 어플리케이션에서 패딩이 올바르지 않은 암호문을 받았을 경우(500 Internal Server Error)
3.어플리케이션에서 패딩은 올바르나 잘못된 암호문을 받았을 경우(암호화된 값을 평문으로 복호화 하였더니 잘못된 값이 있을 경우)
(200 OK - 커스텀 에러 메시지)
위의 3가지 반응을 통해 우리는 암호문의 패딩이 올바른지, 올바르지 않은지에 대해 알수있다.
그 예로 암호분이 7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 라고 예를 들어 보자.
해당 암호문은 다음과 같이 총 3개의 블록으로 나누어 진다.
여기서 첫번째 블록은 이니셜 벡터로 사용되며 나머지 두개의 블록이 평문에 대한 암호문으로 사용되는 것을 볼 수 있다.
여기서 이를 순서대로 IV, 암호문1, 암호문2 로 명명한다.
다음은 평문을 암호화 하는 과정이다.
위의 그림과 같이 IV값에 평문을 XOR하여 Intermediary 값을 만들고 이를 3DES로 암호화 하여 암호문 1이 생성된다.
또한 이때 생성된 암호문1과 나머지 평문(평문+패딩)을 XOR 하여 Intermediary값을 생성한 후 이를 3DES로 암호화 하여
암호문 2를 얻는다. 즉, 암호문은 IV + 암호문1 + 암호문2로 구성된다.
\
이번에는 반대로 복호화 하는 과정이다.
암호문1을 3DES 복호화 한 뒤 나온 Intermediary값을 IV와 XOR 하여 평문 1을 얻었다.
그리고 암호문2를 3DES 복호화 한 뒤 나온 Intermediary 값을 암호문 1 과 XOR하여 평문 2를 얻는다.
이제 패딩 오라클 공격을 통해 암호화된 값을 복호화 하는 방법에 대해 알아 보자.
위에서 사용한 암호문 7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6에서
IV + 암호문1 만 사용하여 7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 까지만 사용하겠다.
먼저, 다음과 같이 IV값을 0으로 채운 암호문을 서버에 전송해보자.
요청 : http://sampleapp/home.jsp?UID=0000000000000000F851D6CC68FC9537858795A28ED4AAC6
응답 : 500 - Internal Server Error
위의 요청에 대한 응답이 500 에러가 뜬다.
왜 그런걸까?
암호문 1을 3DES 복호화 한 뒤 나온 Intermediary 값과 IV 값(0으로 채운) 을 XOR 하여 나온 평문의 마지막 바이트가 올바르지 않은 패딩 값이 되어 에러가 나온 것 이다.
왜냐하면 패딩은 0X01 ~ 0X08 까지 범위이며 해당 수 만큼의 개수가 와야 하기 때문이다.(0X01이면 1개, 0X08이면 8개)
즉, 0X3D는 올바르지 않은 패딩 값으로 인식하여 에러가 나온 것 이다.
이제 패딩이 1개 일 경우를 가정하여, IV의 마지막 바이트를 0X00부터 0XFF 까지 브루트포싱으로 200 OK 응답이 나오는 부분을 확인해 보자
요청 : http://sampleapp/home.jsp?UID=00000000000000003CF851D6CC8FC9537
응답 : 200 OK
IV의 마지막 바이트가 0X3C일 때 패딩이 0X01이 되어 올바른 패딩으로 인식 되었다.
이로써 우리는 결론이 나온다.
[Intermediary 값] ^ 0x3C == 0X01 이므로
[Intermediary 값] == 0x3C ^ 0x01
그러므로 [Intermediary 값] == 0x3D
패딩에 대한 서버의 반응을 통해 8번째 [Intermediary 바이트 값]을 알아낸다.
이제 패딩이 2개일 경우를 가정해 IV의 7번째 바이트를 0X00~0XFF까지 브루트포싱 해보자.
이때 주의할 점은 IV의 8번째 바이트는 0X3D ^ 0X02 == 0X3F가 된다는 점이다.
서버응답이 200 OK일 때, IV의 값을 살펴 보면 0X0000000000000000243F가 되게 된다.
이로써 7번째 Intermediary 값을 알 수 있게 되었다.
(0x24 ^ 0x02 == 0x26)
이렇게 계속 한바이트씩 브루트 포싱으로 결과를 뽑아내면 된다.
그렇다면 이렇게 Intermediary값을 모두 획득 가능하다. Intermediary값을 모두 획득한다면 암호화 과정에서 최초의 IV 값과 평문을 XOR 하여
Intermediary 값을 생성하게 되는데 이미 Intermediary 값을 알고 있고 IV값도 알고 있기 때문에 그 뒤 작업이 가능하다.
그러므로 획득한 Intermediary 값들과 최초의 IV값을 XOR 하면 평문을 얻을 수 있다.
평문을 조작하여 암호화 하려면
(원래 평문) XOR (IV) == ( Intermediary 값) 이 되고
(Intermediary) XOR (조작한 평문) == (조작된 IV값) 이 나오기 떄문이다.
즉, (원래 평문) ^ (IV) ^ (조작한 평문) 을 하게 되면, 조작된 IV값이 나오게 되어, 이 조작된 IV값으로 암호문을 복호화 하게 되면 조작한 평문이 나오게 된다.
출처 및 참고:
http://netifera.com/research/poet/PaddingOracleBHEU10.pdf
http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attack-with-padbuster.html
http://www.troyhunt.com/2010/09/fear-uncertainty-and-padding-oracle.html
laughfool.tistory.com/attachment/cfile7.uf@135D7C3F4F799B14313DAA.pdf
