정보 누출(IL)

주요정보통신기반 웹 취약 분석 평가 방법 9번째 항목인 정보 누출(Information Leakage/IL)이다. 

우선 시작하기 전에 누출과 노출 단어의 차이를 먼저 짚고 넘어가고 싶다.

보안뉴스에 따르면 두 단어의 차이는 아래와 같다.

‘누출’은 ‘비밀이나 정보 따위가 밖으로 새어 나감’을 말하고, ‘노출’은 ‘겉으로 드러나거나 드러냄’을 뜻한다.
누출(유출)은 주로 외부 해킹에 의한 것이거나 개인정보처리자 등 사업자에 의해 정보가 빠져나가는 경우, 노출은 고의나 과실의 여부를 떠나 사업자, 해커, 정보주체 등에 의해 정보가 공중에 떠다니는 것.

 

노출과 누출의 차이는 위의 설명을 보면 이해가 어렵진 않으나 정보 누출 취약점을 생각해봤을때 이걸 노출이라 봐야할지 누출이라 봐야할지 이건 좀 헷갈린다. 나는 그냥 이분법적으로 생각하지 않고 전부 다 통용하는 것으로 생각하겠다.

 

아무래도 정보가 새어나가는 공격이다 보니까 직접적으로 타격을 줄 수 있는 그런 공격은 아니지만 제대로된 공격을 시작하기 위한 초석이 될 수 있다. 예를 들어 분명 특정 사이트에 SQLi 취약점이 있다는 것은 알았으나 서버가 MSSQL을 사용하고 있는 것도 모른채 mysql 공격 쿼리만 계속 하고 있었다면 공격이 실패하는게 당연! 만약 공격 타겟 시스템의 정보가 쉽게 노출이 된다면 그에 따른 공격을 하면 되므로 공격 확률이 더욱 높아진다.

 

정보가 노출이 되는 여러 상황을 가정해보자. +대처법도 함께

1) 웹 서버 에러 페이지

웹 서버 에러 페이지 하단에 웹 서버 정보가 노출되어 나오는 상황.

ip에 웹 서버 종류에 리눅스 정보에 뭐 그냥 다 나온다. 당연히 좋지 않은 상황. 만약 내가 위험한 버전의 apache를 사용하고 있었고 위처럼 정보가 노출되었다면 공격자는 그 버전 아파치의 보안 취약점을 이용하여 정말 손쉽게 공격이 가능할 것이다.

 

웹 서버 설정 파일에 들어가주면 ServerSignature 지시자가 있다. ServerSignature 지시자를 off 해버리거나 아예 지워버리면 웹 에러 페이지 하단에 서버 시그니처가 뜨지 않는다.

ServerSignature Off

 

 

2) 중요 정보의 평문 노출

평문 노출 취약점은 따로 있는거 아닌가 했는데 지금 보고 오니까 조금 느낌이 다르다. 어차피 주통기반 막바지에 평문 전송 취약점이 있어서 설명하겠지만 데이터가 평문으로 노출되어 돌아다니는 취약점이 있다. 요거랑 다름.

예를 들어 이러한 경우라고 한다. 아마 Shoulder Surfing을 방지하기 위한 용도겠지..?

패스워드는 패스워드 타입을 사용하자.

 

<input type = "text"...	--->	<input type = "password"...

 

 

3) 에러 메시지에 의한 노출

Error SQLi 할 때 했던 사진이다. 이 사진이 딱 에러 메시지 노출의 예시이다. 이때는 이 에러 메시지를 이용해 정보를 수집하며 강력한 공격을 할 수 있었다. 그렇지 않더라도 아까 말했듯이 웹 서버 정보가 노출되는 것은 역시 좋지 않다.

요거는 코드 짜면서 에러 메시지를 넣게끔 했을텐데 없애면 됨.

 

4) 인코딩된 중요정보는 디코딩 가능한지 확인

이건 주통기반에서 제시하는 방법이다. 지금까지는 항상 내가 한 예시로만 구성해서 가져왔는데 얘는 그냥 개날먹 주통기반에 실린 그대로 가져왔다. 왜? 이해가 안되서;;

Base64로 인코딩된 암호화????? 인코딩과 암호화는 어울리는 단어가 전혀 아니다. 인코딩은 진짜 정보의 형태만 변환했을 뿐 암호화한게 전혀 아니다. 물론 주통기반에서도 제시한 것이 이러한 멍청한 암호화를 적용한 곳을 예시를 들어 디코딩했을때 저렇게 보일 수 있다 라는 것을 얘기해주고 싶었던 거겠지만. 저게? 지금 들어서 저런 거 찾아보기가 가능할란지 모르겠다.

걍 넘겨도 되는 수준

 

5) 임의의 계정으로 로그인을 시도하여 반환되는 에러 메시지를 통해 특정 ID의 가입 여부를 식별할 수 있는지 확인

요것도 주통기반에서 제시하는 방법. 얘도 의문이 많긴 하지만 생각해보니 신기한게 있다.

분명 예전엔 로그인을 시도할 때 가입되어있는 아이디로 비밀번호를 틀리게 입력하면 비밀번호가 틀렸다고 메시지가 뜨고, 가입되어있지 않은 아이디로 로그인을 시도하면 가입되어 있지 않는 아이디라고 떴었다. 확실하게 기억남.

그런데 지금은?

내 아이디를 기입해서 하나 없는 아이디로 시도하나 에러 메시지가 같다.

근데 이게 무슨 소용이지 굳이 로그인 페이지가 아니더라도 회원가입에서 충분히 알아낼 수 있는건데..?

진짜 모름. 

+ 구글은 없는 아이디면 없는 아이디라고 뜸. 뭐지 진짜

 

6) 주석으로 인한 정보 노출

4번 5번이 너무 영양가가 없는데다가 이번 6번은 주석으로 인한 정보 노출? ㅋㅋㅋㅋ 말이 되나 ㅋ

싶겠지만 간간히 주석으로 정보가 노출되는 경우가 있다. 꽤나 심심치 않게.

이처럼 페이지 소스 코드를 열었더니 주석에 소스 코드를 설명하는 것 외에 다른 정보가 들어있는 경우가 있다.

개발자가 1인 개발하는 곳도 있지만 대부분 규모가 커지면 나눠서 개발을 하기 때문에 다른 개발자들에게 정보를 줄 목적, 관리자 계정의 아이디나 비밀번호를 주석에 담는 경우가 많다. 개발이 끝나면 당연히 지워야 하지만 깜빡하지 않고 지우지 않는 실수를 하는 경우가 생긴다면 꽤나 위험해질 수 있다.

 

대처법도 보기는 했지만 그래도 보안설정방법에 대해 알아보긴 해야지.

• 사용자가 주민등록번호 뒷자리, 비밀번호 입력 시 별표 표시하는 등 마스킹 처리를 하여 주변 사람들에게 노출되지 않도록 함

아까 말했듯이 숄더 서핑 방지

• 개인정보의 조회, 출력 시 아래와 같은 원칙으로 일부 정보에 마스킹을 적용하여 표시

1) 성명 중 이름의 가운데 글자 (ex : 홍*동)

2) 생년월일 (ex : ****년 **월 **일)

3) 전화번호 또는 휴대전화번호 (ex : 02-****-5678, 010-****-5678)

4) 주소의 읍/면/동 (ex : 서울시 송파구 ***동)

5) IP v4 주소의 경우 17~24bit, IP v6 주소의 경우 113~128bit

• 웹페이지를 운영 서버에 이관 시 주석은 모두 제거하여 이관
• 중요정보(개인정보, 계정정보, 금융정보 등)를 HTML 소스에 포함하지 않도록 함
• 로그인 실패 시 반환되는 에러 메시지는 특정 ID의 가입 여부를 식별할 수 없게 구현 (예: ‘가입하지 않은 아이디이거나, 잘못된 비밀번호입니다.’)

네이버는 위를 지키고 있으나 구글은 아님. 별로 중요치 않을 것 같은데..

• 일반적으로 웹에서 발생하는 에러 메시지는 400, 500번대의 에러 코드를 반환하는데 이러한 에러 코드에 대해 별도의 에러 페이지로 Redirect 하거나 적절한 에러처리 루틴을 설정하여 처리되도록 함(전체적인 통합 에러 페이지를 작성한 후 모든 에러 코드에 대해 통합 에러 페이지로 Redirect 되도록 설정)

요거는 이제 apache 환경에서만 살짝 알아볼텐데, 다시 말하면 그냥 에러 페이지 별로 사용자 정의 페이지를 설정하라는 소리이다.

웹 서버 설정 파일에서 ErrorDocument 지시자를 사용하면 특정 에러 페이지 별로 설정이 가능하다.

ErrorDocument 404 /error_page.php

위와 같은 식으로 일반 에러 페이지 대신 사용할 페이지를 만들어 대체를 하는 방식이다.