-->

[인시큐어뱅크] HTTP 통신 및 파라미터 조작 취약점

반응형

HTTP 통신과 파라미터 조작 취약점을 하나로 묶어 포스팅하려 한다. 인시큐어뱅크(InsecureBankv2)의 깃허브에 나와있는 취약점 명칭 그대로 썼는데 KISA에서 나온 가이드 기준으로 보면, '중요정보 평문 전송 취약점'이라고 할 수 있을 것 같다.   

 

 

HTTP 통신 및 파라미터  조작 취약점 진단

요즘 HTTP 통신을 하는 곳이 있을까 싶을정도로 HTTP 통신은 보안을 전혀 고려하지 않은 프로토콜이라는 것은 보안을 하는 사람이라면 누구나 알고있을 것이다. 평문 전송을 하기 때문에 정보 유출은 당연하고 입력값 검증을 하지 않는다는 가정하에 조작도 가능하게 된다.

 

먼저, 프록시 설정부터 수행해준다. 녹스 에뮬레이터 기준으로 설정>WiFi 에서 WiredSSID 를 길게 클릭하면 아래와 같이 WiredSSID 네트워크 수정 창이 뜨게된다.

 

 

 

네트워크 수정을 클릭하고 고급 옵션을 체크한 후, 호스트와 포트를 입력해 프록시 설정을 해준다. 포트는 버프스위트가 8080을 쓰기 때문에 8080으로 입력해주었다.

 

 

 

버프스위트에서 Intercept is on을 클릭해준 후, 로그인을 수행해보면 HTTP 통신을 하고있기 때문에 아래와 같이 계정정보가 평문으로 그대로 노출되는 것을 볼 수 있다. 여담이지만 버프스위트 왜이렇게 저화질이지...? ㅇㅅㅇ??

 

 

 

DoTransfer에서 파라미터 조작이 가능한지 확인해보자. 확인결과 amount 값을 임의로 변경해도 Transfer가 성공하는 것을 볼 수 있었다. (View Statement에는 뜨지 않지만 성공한 것이 맞음)

 

 

 

HTTP 통신 및 파라미터 조작 취약점 진단결과 및 대응방안

  • HTTP 프로토콜을 사용해 데이터 송수신 시 중요정보가 평문으로 노출되는 취약점이 존재하므로 암호화 통신(HTTPS 프로토콜 = TLS/SSL) 을 적용해야 한다.
  • 대부분의 인시큐어뱅크 파라미터 조작 취약점 포스팅에서 대응방법으로 '서버검증'을 언급했는데 여기서 수행한 파라미터 조작은 서버에서의 입력값 검증 미비로 인한 취약점이라기 보다는 평문 송수신으로 인한 MITM 취약점이 더 맞다고 생각하기 때문에 암호화를 적용하는 것이 대응방안이라고 생각한다.
  • 물론 여기서 단순 파라미터 조작이 아닌 인젝션을 한다거나 일부분만 변경한 패킷을 재사용한 경우라면, 전자는 서버에서 입력값 필터링을 해야하는 것이고 후자는 서버에서 세션검증을 해야하는 것이기 때문에 서버검증이라고 하는게 맞다.

 

댓글

Designed by JB FACTORY