요즘은 주변의 Wi-Fi로 위치정보를 파악한다. 반대로 하면 어떨까?

요즘 대부분의 스마트폰이나 태블릿PC, 그리고 노트북은 GPS보다 Wi-Fi를 이용해 더 정확한 위치를 파악한다. 원리는 간단한데 구글 같은 돈 많은 사람이 먼저 차를 끌고 돌아다니면서 Wi-Fi AP(Access Point)가 어디에 위치해 있는지 수집을 해 지도를 만든다. 그리고 우리는 주변에 있는 Wi-Fi AP들의 BSSID와 신호 세기를 구글, 혹은 다른 곳에 던지면 삼각측량을 해 내가 어디쯤에 위치해 있는지 알려주게 된다.

Wi-Fi를 모니터 모드로 돌려서 스캔을 해 본 사람들은 알겠지만 주변에 있는 AP 뿐만 아니라 기타 장비(Station)들도 잡히게 된다(물론 신호 세기도 함께).
만약 모니터모드의 장비 3개 이상을 적절한 거리를 두고 배치한 뒤 지나다니는 와이파이 신호를 잡으면 역시나 삼각측량이 가능해지고 위치를 알 수 있게 되지 않을까? 전자칠판의 펜 위치를 파악하는 것처럼 말이다.

Yasager – Karma on the Fon이 아직도 통할까?

Wi-Fi 관련 공격방법 중에 Yasager(독일어로 대충 Yes man쯤 된다)라는 게 있다. 이게 어떤 공격이냐면 Wi-Fi 클라이언트들은 켜지는 순간 자기가 가지고 있던 AP들의 SSID가 근처에 존재하는지 모두에게 물어보게 된다. 굳이 Beacon frame(AP에서 자신의 SSID를 알리는 행위)이 발생하기까지 기다리지 않도록 하기 위함이다. 예를들어 RealAP라는 AP목록이 저장되어있을 때 Wi-FI를 켜면 RealAP라는 SSID를 가진 AP가 존재하는지 물어보게 된다.

제대로 만들어진 AP라면 자신의 SSID가 RealAP일 때만 응답을 하겠지만 Yasager는 실제 자신의 SSID가 FakeAP라 할지라도 무조건 맞다고 응답한다. 그러면 클라이언트는 그걸 검증할 방법이 없기때문에 접속을 하게 된다. 원래의 AP가 더 가까이 있어야 성공하기 쉽기 때문에 추가적으로 Aireplay등을 통해 Yasager가 아닌 AP에 대해서는 Deauth 패킷을 날려주는 방법도 같이 쓴다.

당연하겠지만 원래 저장된 AP 설정에 암호가 있다면 그 클라이언트는 Yasager에게 암호와 함께 접속 요청을 한다. 내 기억상 이 Yasager는 WEP 보안까지는 어떻게 하나 모르겠지만 WPA 이상으로 넘어가면 그냥 접속이 안된다. 그래서 암호가 걸리지 않은 AP를 대상으로 Spoofing을 해서 원본 AP가 아닌 Fake AP로 접속하게 만드는 공격이다.

예전엔 암호가 걸리지 않은 AP가 많았고 그래서 효과는 굉장했지만(Facebook의 피싱사이트만 만들어서 제공해도..) 지금은 집에서도 다들 WPA 이상의 암호를 걸어서 사용하기 때문에 공격할 수 있는 곳은 근처 카페 AP정도가 될 것이다. 그런데 카페 Wi-Fi 정도면 그냥 같이 접속해서 ARP spoofing 공격을 하는 걸로도 충분하다. 오픈된 AP가 밀집된 지역에서라면 좀 쓸모가 있을지도 모르겠지만 요즘 그런 곳이 흔하지는 않다.

그래서 내 생각에는 통신사들의 오픈된 AP들(T-WiFi, olleh, u+zone)을 한꺼번에 타깃으로 잡는 것 이외에는 그다지 활용할 곳이 없을 것 같다.
이번 해킹캠프때 네트워크 보안에 대한 이것저것을 발표하려 하는데 이것도 간략히 넣어야겠다 하고 자료를 만들다가 생각나서 써봤다.

HTTP에서 보안을 조금이나마 강화시키는 헤더들

오늘 STS(Strict-Transport-Security)를 적용하려고 검색을 하다가 몇 가지 처음 보는 헤더들을 찾았다. 이 글에 자세히 설명이 나와있는데 대충 적어보면 이렇다.

1. Content-Security-Policy

누군가 페이지에 외부 스크립트 등을 걸어서 XSS 공격을 할 수 있기 때문에 페이지에서 허용할 origin을 지정할 수 있다. Content의 종류는 아래와 같다.

  1. script-src: JavaScript code (이 헤더를 사용하는 가장 큰 이유다)
  2. connect-src: XMLHttpRequest, WebSockets, and EventSource.
  3. font-src: fonts
  4. frame-src: frame ulrs
  5. img-src: images
  6. media-src: audio & video
  7. object-src: Flash (and other plugins)
  8. style-src: CSS

자신의 사이트와 구글의 각종 스크립트들만 허용하고 싶다면 아래와 같이 적어주면 된다.

Content-Security-Policy: script-src 'self' https://apis.google.com

2. X-Frame-Options

가끔 누군가가 자신의 사이트와 비슷한 도메인을 사서 아무 내용도 없이 자신의 사이트만 전체 크기의 프레임으로 박아놓는 짓을 한다는 글을 몇 번 본 적이 있다. 접근하는 유저만 엄청 끌어모은 다음 나중에 갑자기 내용을 바꿔서 날로먹는 방법이라는데 아무튼 이런 짓을 막을 수 있게 자신의 페이지가 Frame 안에 들어가는 것을 방지하게 해준다. Clickjacking도 막을 수 있겠다.

사용 방법은 아래와 같이 3가지가 있다.

  • X-Frame-Options: DENY (프레임 안에 절대 들어가지 못하게 한다)
  • X-Frame-Options: SAMEORIGIN (같은 origin일 경우에만 허용한다)
  • X-Frame-Options: ALLOW FROM hxtp://some-domain.com (특정 origin에서만 허용한다)

3. X-Content-Type-Options

Github에서 잘 쓰고 있다고 하는데 jpg 확장자로 js파일을 올려 우회를 한 후에 script 태그에 src로 넣는 수법을 방지하는 헤더다. 이 헤더를 넣으면 MIMETYPE과 다르게 사용하지 못하게 한다. nosniff를 넣어주면 활성화가 된다.

4. Strict-Transport-Security

내가 오늘 하려고 했던 STS다. SSL strip 공격을 막기 위해 나온 헤더인데 이 헤더를 받게 되면 브라우저는 다음에 접속할 땐 URL이 http로 지정되어있어도 무시하고 무조건 https로 접속하게 된다. 이런 방법으로 SSL strip 공격을 피할 수 있게 된다.(단, 한 번이라도 이미 접속은 한 상태여야 한다)

사용방법은 그냥 쿠키 지정하듯이 max-age를 초단위로 입력해주면 된다. includeSubDomains를 넣어주면 서브도메인들에도 적용이 되지만 나는 SSL 인증서가 와일드카드가 아니라 그건 뺐다.

참고로 오늘 실험해본 결과 HTTP 통신을 하고 있을 때는 이 헤더를 무시하게 된다. 꼭 301이나 302 리다이렉트를 해서 HTTPS를 사용하게 한 후 이 헤더를 넣자(둘 다 넣어도 상관은 없지만 HTTPS에서 이 헤더를 꼭 한 번은 받아야 한다).

2014/08/02 추가:
STS를 적용하게 되면 해당 도메인에 대한 모든 HTTP 연결이 포트와 관계없이 HTTPS로 전환된다.
다른 포트에서 테스트 앱을 돌리거나 할 때는 IP를 이용해 접속하거나 해야 SSL 오류등이 뜨지 않는다.