jwmsg

중소기업을 대상 으로 하는 피싱메일 분석 [2]


스팸 필터를 뚫고 들어온 피싱메일?

<스팸을 뚫고 와버렸다>

패턴도 똑같고, 방식도 똑같다. 그런데 얘는 어째서 스팸을 뚫고 들어왔을까?

네이버 웍스에서는 “원문 전체보기” 기능이 있다.

여기서는 메일의 헤더 부분을 확인 할 수 있고, 어떤 메일서버를 통해 왔는지, 확인이 가능하다.

<헤더 보는 방법>
메일의 헤더를 통해 어디서 왔는지 확인해보기

메일의 헤더를 통해 확인을 했더니 이게 뭐지?

우리 회사와 같은 네이버 웍스에서 발신된 메일이었다.

유추해볼 수 있는건 다음과 같다

  1. 해커에 의해 이미 털린 A라는 회사는 네이버 웍스를 사용한다.
  2. A 라는 회사의 메일에 접근하여 나에게 피싱 메일을 보낸다
  3. 만약 내가 피싱메일에 계정정보를 넣는다면?
  4. 해커는 또다시 우리 회사 내 메일에 접근해서 다른 회사에 피싱메일을 보낸다

아마도,, 위 와 같지 않을까 싶다.

스팸을 뚫을 수 있었던 것도. 아마 같은 플랫폼안에서 전달되다 보니 “실제 기업 간의 메일” 로 인식하여 스팸 필터가 적용이 되지 않았던 것으로 생각이 든다.


이젠 아무도 믿을 수 없다.

과연, 피싱메일을 통해 얻은 계정으로 다른 회사에게만 공격을 시도할까?

협력사, 거래처, 또는 동료직원에게도 피싱메일을 보내어 충분히 해커의 목적을 달성 시킬 수 있다.

당분간은 메일을 열어보기 전에, 로그인하기전에 신중을 기해야 할 것으로 보인다.


수집한 정보로 뭘 하는데?

사실 나도 잘 모른다. 수집된 내역이 있는 로그 파일을 찾아낸것도 아니고, 도대체 어디다 사용하려는지는 모르겠으나 하나 확실한것이 있다면 정황상 “또다른 피싱메일을 다른 사람에게 보내는” 용도로 활용될 가능성은 있는듯 하다.

보통 수많은 메일을 하나하나씩 보내기엔 당연히 수고도 들고, 해커로서 할짓이 못된다. 그러니 자동화 또는 시스템을 활용할 텐데 그 좋은 방법이 바로 SMTP IMAP 이다.

실제로 우리 회사의 마스터 계정을 향한 로그인 시도가 엄청나게 빗발치고 있고, 해커가 노리는것 또한 계정정보를 얻어서 SMTPIMAP 으로 접속하여 다른 행위를 시도하려는게 가장 크다

네이버 웍스에서 지원하는 감사 기능으로 로그인 실패 목록을 열람 해 보았다.

사내 관리부의 협조를 통해 감사 기능을 이용하여 로그인 실패 목록을 열어보았더니 수많은 IP 주소를 통해 지속적으로 연결을 시도하는 정황이 발생하고 있다.


우리회사가 웍스를 쓰는지 뭘 쓰는지 어떻게 알고 보냈을까?

회사 이메일은 도메인으로 구성되어 있다. 이메일을 보내는데 ip 를 치는 사람은 없을 것이다.

DNS 레코드 중에 MX 레코드를 조회하면 확인할 수 있는데,


맛소금 해커의 jwmsg.me 도메인의 mx 레코드를 보아
google 의 workplace 를 쓰는것으로 볼 수 있다

위 처럼 mx 레코드를 통해 메일을 어디로 보내야 할지가 나온다. 이를 통해 google 을 사용하는지 네이버웍스를 사용하는지, 하이웍스를 사용하는지 각각 조회가 가능하다.

아마도 해커는 이 점을 노리고 피싱 공격을 시도할때, works 유저들에 대해 UI 나 각종 로그인 서비스들을 전부 맞춰놓고 메일을 보냈을 것으로 추정한다.


문득 드는 생각,

우리 회사 도메인에 내 ID 및 직원들 ID 를 어떻게 알고 메일을 보냈을까?

추측 하건데, “우리 회사 직원중 한명이 이미 털렸다” 는 가정하에 분명 조직도를 열어봤거나 주소록을 열어봤을 가능성 밖에 없었다.

실제로 외부에 공개하거나 전송을 하지 않는 시스템 메일 계정으로도 (내부전송용) 해당 메일이 온 것으로 추정컨데,

네이버 웍스 자체가 털리지 않고서야, 우리 내부 직원의 계정 유출로 인해주소록이나 조직도가 유출된 정황으로 밖에 해석 되지 않는다. (에이 설마,,,)

우리회사는 이를 해결하기 위해 다음과 같은 정책을 도입하고 시행을 예정하고 있다

  1. 전산 특별 감사기간 (이메일 및 기타 전산 로그인 기록 IP 부검 후 이상이 있는 경우 전산 2차 인증 (OTP) 의무화)
  2. 비밀번호 90일에 1회 무조건 변경
  3. 비밀번호 중복 금지 (2회까지)
  4. 주요 전산서비스 (NAS, GIT 등) 은 IP 방화벽으로 내부망 및 지정 VPN 에서만 접속 가능하고 OTP 의무화.
  5. 매주 1회 이상 백신 돌리고 내역 검사 받기

깨달은 점

사실 보안 관리 하는거 매우 귀찮다. 보안때문에 접속도 힘들고 어려워 져서 직원들 민원이 폭주하기도 한다.

그런데, 우리 회사는 여러 협력 파트너사와 함께 일하는 기업 아닌가?

우리가 해킹공격, 정보유출을 당하는 순간 협력회사들또한 그 위협에 노출된다.

만약 협력회사들 마저도 해킹이나 정보유출 피해를 입는다면 그 피해에 대한 책임은 고스란히 우리 회사로 돌아오게 될 것이다.

예전처럼 단순하고 간단하게 생각할 요소가 아니다.

이제는 지능적이고 치밀하고 계획적으로 들어오는 공격에 대해서 우리가 과연 뭘 해야하는지 생각하고 대응할 준비를 하는 자세가 필요하다.

  • “나는 개발자니까 개발만 해야지~”
  • “우리회사는 제조업이라 보안? 상관없지 않을까?”

와 같은 생각은 결국 나도 모르는 사이에 해킹 피해로 인한 기업의 존폐의 기로까지 가게 될 수 있다.

jwmsg

중소기업을 대상 으로 하는 피싱메일 분석 [1]


사건의 발단 <최초의 메일>

<사건의 원인>

나한테 견적서가 올 이유가 없다. 난 영업이나 견적을 담당하는 사람이 아니다.
심지어 견적서가 스팸함에 들어있었고,
첨부파일이 분명 없는 메일인데 첨부파일 항목이 있어서 확인해보니
첨부파일이 아니라 “이미지” 를 첨부파일처럼 속여 놓았다.
저 이미지를 누르면 어떤 사이트가 뜬다.

hxxps://swift-iron-purring[.]on-fleek[.]app/vhcvwdcywdhscfgxvscxdfserxdfdszaewsrdtfytewdvwdecftwycvhwecfewyvhjhvwgcftyewvhgwe.html
<가짜 Works 로그인 창>

놀랍도록 똑같이 생겼다.
“당연히” 여기에 실제 아이디와 비밀번호를 입력하면 털린다.
해당 정보를 수집해서 뭘 하는지는 후속 편에서 다뤄보도록 한다.

<실제 Works 로그인 창>

보안 전문가들도 이정도로 똑같으면 속아서 로그인 할 수 도 있다.

이 사이트에 로그인을 하면, 다음 과 같은 방법으로 데이터를 보낸다.

<데이터를 전송하는 로직>

여기서,
aHR0cHM6Ly9wYXJrbGFuZHVzYS5jby9nZWlkYW0veGVuZC5waHA=
의 경우, 복호화 하면 다음과 같다.

hxxps://parklandusa[.]co/geidam/xend.php

약간 소름 돋는 부분도 있다.

두번이상 시도하면 로그인 되는것처럼 보이게 하기

로그인을 시도해서 2회 시도하고나면 실제 웍스모바일 로그인 창으로 넘어가게 해서 로그인이 된것 처럼 꾸미는 것이다.

(그 이하는 틀렸다고 일부러 표시하여 재 검증 하는 듯 하다)

이렇게 하면, “로그인 된 상태로 메일을 열었으니 당연히 로그인 된 상태로 네이버 웍스의 메인화면이 뜬다”


피싱 사이트에 대해 더 자세히 알아보기

hxxps://swift-iron-purring[.]on-fleek[.]app/vhcvwdcywdhscfgxvscxdfserxdfdszaewsrdtfytewdvwdecftwycvhwecfewyvhjhvwgcftyewvhgwe.html

위에서 언급한 해당 사이트를 보면 이상하다. 이름이 너무 길다. 저거 어디선가 본거 같아서 index 페이지를 보려고 path 만 남기고 다 지워보니..

hxxps://swift-iron-purring[.]on-fleek[.]app/
IPFS ?????

IPFS 가 뜬다. 이게 뭔지 좀 알아보니.

블록체인에 파일을 저장해서 분산화 하는 파일시스템 이라고 한다.

P2P 방식으로 파일을 공유하는 서비스 인데, 이를 이용하여 웹 호스팅을 해주는 서비스가 Fleek 이라는 서비스 같다.

fleek.co

사실 이 사이트는 V3 에서 악성 사이트로 뜬다… 만 일단 허용하고 들어와 봤다.

IPFS 특성상 얘는 중앙 서버가 없다. 단지 Fleek 같은 서비스가 도메인 기반으로 해당 파일을 웹으로 보여주는 서비스 인것으로 파악 된다.

해당서비스는 웹 프론트만 띄워두었고, API 는 별도로 만들어 둔것 같은데 API 서비스를 조금더 파악해 보자면

hxxps://parklandusa[.]co/

들어가보니 디렉터리 리스팅이 된다,..

물론 실제 전송 api 위치는 /geidam/xend.php 이지만,

눈여겨 볼 위치는 /cgibn/ 아래에 있는 항목들이다.

hiworks 라는 이름도 보이고, 일부 xend(네이버웍스용인듯) 등이 보임

/cgibn/hiworks.php 는 하이웍스 오피스 유저를 상대로,

/cgibn/thanks.php 는 (실제 접속하면 이동함) 이카운트 메일 유저를 상대로

/cgibn/xend.php 는 (아까와 동일) 네이버 웍스 유저를 상대로

피싱을 시도하는 정황이 확인된다.


자, 일단 정리를 하자면

누구인지, 어떤 애들인지는 모르겠지만,
국내 중소기업들이 자주 사용하는 오피스 프로그램 또는 메일 시스템 사용자들을
상대로 굉장히 기획적이고 치밀하게“피싱 메일” 범죄를 수행하고 있다.

심지어 P2P 분산 파일 시스템을 활용하고, 익명의 API 서버를 활용하여 정보를 수집하는 등의 행위를 통해 중소기업 이메일 계정들을 탈취하고 있는 정황이 크게 나타난다.

우리나라 산업구조상, 대기업과 파트너쉽을 맺고 있는 중소기업들이 상당히 많고, 중소기업들은 대기업과의 거래를 통해 성장하는 경우가 많으며 거래처의 이메일을 신뢰하는 경우가 많은데, 만약 중소기업의 메일을 활용하여 악성코드 또는 렌섬웨어의 유포가 발생한다면 대기업은 속수무책으로 당할 수 있다.

다음 포스트에서는,

  • “스팸메일로 분류가 안된 상태로 온 피싱메일”
  • “아이디와 암호를 활용하여 뭘 시도하는지”
  • “해결할 방법은 없는지”

에 대해 알아보도록 한다.

jwmsg

중소기업을 대상 으로 하는 피싱메일 분석 [0]


프롤로그

일을 열심히 하고 있는 도중에 갑자기 회사 직원 중 한 명이 소리를 지른다.

  • 악!!!!!! 안돼!!! 비번 빨리 바꿔야겠다!!!

나는 회사에서 전산, 인프라, 보안, 개발, 등 컴퓨터 들어가는 일을 다 도맡아 하고 있는 입장에서, 소리를 듣자마자 직원 자리로 가서 확인을 했다.

  • 견적서가 왔다 길래 눌렀는데 로그인 창이 떠서….
  • 아이디와 비밀번호를 입력했는데도 로그인이 안되어서 이상하다 싶어서…
  • 위에 URL 을 보고야 해킹 이라는 걸 알게 되었습니다.

사실 전산 담당하는 입장에서, 정말 다행스럽기도 하고,
큰 소리로(?) 주변 IT 담당자에게 알렸기에 빠르게 대처할 수 있었다.
이상하다 싶어서 URL 을 보고 바로 인지했다는 점에서 
나름 최소한의 보안 의식이 있는 사람이라고 생각하게 되었다.


본격적으로 피싱 메일을 부검하기 전에.. 일단 해야 할 일

일단 피싱 메일을 분석하기에 앞서…
이게 단순 해당 직원 뿐만 아니라 나한테도 오거나 다른 직원한테도 갔을 것이다.

그럼 지금 가장 심각한건,

“나도 파악하지 못하는 누군가가 이미 로그인을 시도 했다면?”

그리 하야, 모든 전사 직원에게 메일을 보냈다

  • 1. 요즘 이상한 메일 온다
  • 2. 누르지 마라
  • 3. 눌러서 시도한 이력이 있으면 이 글을 보는 즉시 나한테 보고 해달라$
  • 4. 메일이 오면 그 메일 전부다 나한테 FW 해달라$
  • 5. 조만간 회사에 백신 도입할 것이다. 매주 수요일마다 돌리고 보고 해달라$
  • 6. 암호 3개월에 1회 변경 의무화 시행 하겠다.

지금까지 신경 쓰지 않았던 보안을 조금 더 강화해서 정책을 모두에게 알렸다.

그러면서 겸사겸사 피싱 메일들을 FW 받아서 표본을 늘리고 패턴을 잡아서 해커를 조져 보기로 결정한다.

jwmsg

CVE-2021-22205 긴급 패치하기

그렇습니다. 저도 갑작스럽게 이 RCE 가 터져서 문제가 좀 생겼습니다.

아마 이 게시물에 들어오신분들은 저와 같은 상황에 처해있거나 GITLAB CE/EE 운영하다가 문제가 생기신 분들일 가능성이 있습니다 저도 중 많이 받았어요.

특히 저처럼 AWS Lightsail 사용하시는분들도 꼭 확인하셔야 하는 이유가 있습니다. 저도 처음엔 당황스러웠는데요.

AWS 에서 메일이 날아왔습니다….

그대의 서버가 봇넷으로 이용당하고 있으니 조치하십시오…..

그래서 일단 부지런하게 원인이 뭔지 좀 밝혀내야 하지 않을까하고 페북에다가도 수소문을 해서 조금 검색해보니 최근 (2021년 11월 1일쯤?) 문제가 좀 있었던것 같습니다.


일단 무슨 문제일까?

깃랩의 설명에 따르면 이미지 올리거나 할때 EXIF 영역을 제거하는 부분이 있는듯합니다. 그래서 그부분을 ExifTool 이라는 녀석이 받아서 처리하는데, 이 ExifTool 이라는 녀석에게 RCE 취약점이 발견된것 같습니다. (EXIF에 대한 내용은 여기로)

일반적으로 gitlab.com 은 문제가 되지 않구요, 별도로 자체 Gitlab을 서버에 올려서 사용하시는 CE 또는 EE 유저들은 필히 이 문제를 꼭 확인하시기 바랍니다.


문제가 발생하는 서버 버전

다음 버전의 서버에서 발생하는데 보통 다들 깃랩 같은서버는 한번 올려놓고 딱히 업데이트 안하는것 같아서 이번에 대부분의 서버들은 패치되어야 할것 같습니다.

  • 11.9.x – 13.8.7
  • 13.9.0 – 13.9.5
  • 13.10.0 – 13.10.2

일단 내 서버가 당했을까?

일단 깃랩에서 친절하게 잘 설명하고 있습니다.

그런데 일단 한글로도 정리를 해야할것 같아서 여기다가 정리를 해보려 합니다.

일단 뭘 하기전에 항상,……

일단 스냅샷 부터 꼭 찍으시고 작업 하시기 바랍니다.

/var/log/gitlab/gitlab-workhouse 아래에 current 라는 로그파일이 있습니다. 해당 파일에서 grep 을 이용하여 “exiftool command failed” 를 검색하면 되는데요.

느낌이 쎄하다,,, stderr 을 보아하니 뭔가 다운을 받은것 같다,,,,

대충 뭔갈 다운받은듯한데, 뭔가 수상쩍은 stderr 혹은 stdout 부분이 발견되신다면 일단 내 서버가 털렸을 것에 집중을 하셔야 합니다.

해당 시간에 맞는 nginx 의 로그를 확인해 보셔도 좋습니다.

uploads/user 쪽으로 post 가 하나 날아들어온게 포착…

일단 빼박,, 저는 뭔가 느낌이 좋지 않습니다..

공격 당한것 같은데 어찌 해야 합니까?

지금 저도 공격 벡터 찾아서 분석중인데, 시간이 좀 걸릴것 같습니다.

확실한건 이번주 주말(11월 13일) 까지 상세하게 찾아보고 글을 써서 공유해볼 예정입니다.


패치는 어찌하면 좋습니까….

일단 가장 좋은 방법은 최신버전의 Gitlab CE로 업그레이드 하는겁니다만,,,

아시다시피,, 코드 저장소를 함부로 업그레이드를 갑자기 진행하기엔 좀 곤란한 부분이 있습니다.

하나의 솔루션으로는 ExifTool 부분의 소스코드만 별도로 패치하는것입니다만.

sudo su cd ~  
curl -JLO https://gitlab.com/gitlab-org/build/CNG/-/raw/master/gitlab-ruby/patches/allow-only-tiff-jpeg-exif-strip.patch  
cd /opt/gitlab/embedded/lib/exiftool-perl  
patch -p2 < ~/allow-only-tiff-jpeg-exif-strip.patch

일단 제가 해봤는데요, 왜인지 모르겠으나 저는 안되더라구요 (되시는 분들은 여기서 멈추시면 됩니다.)

이상하게 저는 FAILED 가 뜹니다. 그래서 저는 그냥 ExifTool이 돌지 못하게 막도록 하기로 했습니다. (그렇게 되면 자동으로 EXIF 를 처리하는 로직이 사라지니 혹시 필요하신 분은 좀 다른 방법을 찾으셔야 할듯 합니다)

/opt/gitlab/embedded/bin/exiftool 를 에디터 (VIM,등)으로 여시고,

#!/bin/bash

cat -

위 처럼 파일을 덮어 버리시기 바랍니다.

(저는 exiftool.bak 이라고 별도로 백업파일 만들어 두고 진행했습니다.)


패치가 잘 되었는지?

역시 직접 공격 넣어보시면 됩니다. 해당 CVE 코드를 기반으로 Git 에 돌아다니는 python 소스코드를 이용하여 테스트 해보실 수 있습니다.

일단, 저는 혹시나,,,, 하는 마음에 이 블로그에는 공유하지 않겠습니다. 별도로 잘 찾아보시기 바랍니다.

패치 전엔 공격 가능하다고 뜹니다.
패치가 잘 되면 불가 하다고 뜹니다.

마무리글…

이제, AWS 에 보고메일을 보내야 할듯합니다.

일단 워낙 긴급한 사안같아서 난리난듯 한데,

암튼 제 글솜씨가 좋지않아 두서없이 적은점은 죄송합니다 ㅠㅜㅠㅜ

다들 해결은 잘 하셨으면 좋겠습니다.

jwmsg

OSINT 특집[2] – 이미지에서 정보를?

바로 이어서 이미지/영상 소스에서 정보를 추출하는 방법과, 이를 통해 찾아낼 수 있는 정보들에 대하여 알아볼까 합니다.


눈에 보이는 영역에서 정보를 찾아보자!

제일 먼저, 우리가 쉽게 찾을 수 있는것에서부터 찾아내보는겁니다.

제가 과거 제 2회 NEWSECU 정보보안해킹대회 때 출제했던 문제 입니다.

  1. 위 사진을 찍은 위치의 주소는?
  2. 위 사진에서 지나가고 있는 버스의 번호는?
  3. 위 사진을 찍은 시기(몇년/몇월)는?

사진에서 찾을 수 있는 정보는 다음과 같습니다.

  1. 건물에 적힌 간판들의 상호명들
  2. 앞에 지나가고 있는 버스의 정류소 (나머지는 일부러 지웠음)
  3. 영화 대개봉을 알리는 포스터들

그럼,,
건물에 적힌 상호명들을 조합하여, 건물의 명칭과 주소를 알아낼 수 있고,
지나가는 정류소를 나열하여 검색하면 버스 번호를 조회해 볼 수 있습니다!
그리고, 보통 1~2주전쯤 홍보하는 영화포스터를 통해,
사진을 찍을 수 있는 시기를 알 수 있습니다!
[직접 찾으실 수 있게 정답은 공개하지 않겠습니다]

자, 그럼, 친구와 집근처에서 셀카를 찍고 SNS에 올렸다고 가정해 봅시다.

뒷 배경과 조그마한 정보들을 토대로 사진을 찍은 위치와 시간대를 유추당할 수 있는 여지를 줄 수 있는것이겠죠?

물론, “나 여기 왔어요~~” 자랑하기 위해서 올리는 사진에서는 문제가 되지 않겠지만, 단순히 셀카만 찍어 올리는것을 목적으로 올린경우, 그리고 그 찍은 위치가 공개되면 좋지 않은 경우엔, 당연히 배경을 주의하여 촬영을 하는게 좋을 수 있다고 의견을 남깁니다.


눈에 보이지는 않지만, 남아있는 정보!

혹시, EXIF 라는 정보를 들어보신 적이 있으신가요?

EXIF 는 EXchangable Image File format 의 약자로, 우리가 흔히 사용하는 “JPG/JPEG” 형태의 사진에서 주로 사용하는 이미지의 “메타데이터” 를 저장하는 하나의 “포멧(형태)” 입니다.

메타데이터가 뭔데?

메타데이터는 “데이터에 대한 데이터” 라고 하는데, 즉 어느 데이터를 설명하기 위한 또다른 데이터 라고 생각하면 됩니다. 예를들어 사진이 있다고 가정할때, 사진을 설명하는 정보 (사진이름, 사진찍은시간, 사진찍은사람, 사진찍은 기기의 정보 등) 가 이에 해당합니다.

그거가지고 뭐하는데?

제가 아래 사진을 하나 준비해 왔습니다! 이 아래 사진을 토대로 분석해 봅시다!

이 사진을 오른쪽 마우스 눌러서 다운로드 하시면 아래 방법으로 실습 하실 수 있습니다.

먼저 파일의 오른쪽 마우스를 눌러 속성을 봅시다.

카메라 제조업체, 카메라 모델, 촛점과 카메라 셋팅까지 모두 확인이 가능
심지어, 위도, 경도, 고도 까지 알 수 있습니다.

여기서 중요한건, 당연히 위도 경도 고도 겠죠? 위/경도를 이용해 위치를 찾고, 고도를 이용해 층수를 계산하면? (실제로 저게 학교기숙사) 만약 집안에서의 위/경/고도를 알게 된다면, 집주소 찾는건 그냥 하겠죠?

위, 경도는 세미콜론(;) 을 단위로 3개의 영역(도,분,초) 으로 나뉩니다. 이 3개의 영역을 계산하면 실제 위경도 좌표가 나오는데 방법은 아래와 같습니다.

위 사진에서 위도가, 37도 37분 17.2999 초 이므로, 60분법을 이용하여 계산하면,

위도는
37+(37/60)+(17.2999/3600) = 37 + 0.61666 + 0.004805527777 =
37.621472194444… 가 나옵니다.

경도는
127+(3/60)+(23.159999 / 3600) = 127 + 0.05 + 0.00643333305555 =
127.05643333305555… 가 나옵니다.

위경도를 구글에 검색하면!

역시 구글신은 무엇이든 알고 계신다!!!!

제가 살았던 광운대학교 기숙사 위치를 찍어 볼 수 있습니다.
(소름돋는건, 실제로 저 위치가 내방 있는 위치였다는거,)

여기에 고도를 더하면?

해당 위치 저층의 고도는 약 41미터

그럼 카메라에서 측정된 47미터였으니까, 약 6미터, 2미터당 1층이라 치면 (3층높이) => 본인은 5층이었음 [오차 존재]

오차가 존재하더라도, 어느정도 들어맞출 수 있는 정도 입니다. 만약 이게 집에서 찍은 사진을 온라인에 잘못 올렸을 경우, 집주소와 위치를 노출 당할 우려가 있겠죠? (무섭네,,)


안전하게 이미지 올리는 방법은?

사실, 아무리 안전하게 한다 한들 찾을 사람들은 다 찾습니다. (팩트)

하지만, 최대한 우리가 신경을 쓴다면 가장 먼저 EXIF 영역을 지운 상태로 이미지를 업로드 하는게 좋겠죠?

  • 사진을 찍을때 부터 위치정보를 지우고 찍는다

당연히 처음부터 찍을때 위치정보를 지우고 찍는걸 추천합니다.
안드로이드 같은 경우 카메라 앱 설정에서 위치정보를 기록하지 않는 방법이 있습니다.
아이폰의 경우에는 설정->개인정보보호->위치서비스->카메라->안함 설정을 해주시면 됩니다.

  • 이미 찍은 사진을 올릴때에는 exif 제거하는 도구 를 이용하여 제거한다.

PC 로 업로드 할 때는 EXIF Eraser 라는 툴을 이용하여 꼭 EXIF 영역을 지우고 올립시다. 혹은 페북이나, 인스타, 트위터 등에 업로드 할때, “자동으로 위치 수집, 태그” 기능을 꼭 끄고 업로드 합니다.

모바일에서는 사실 EXIF영역을 지워주는 앱들이 많이 출시 되었습니다만,, 사실 개인적으로는 신뢰하기 어려워서 추천해 드리지는 않습니다 (과거에 사진이랑 위치를 수집해가는 앱들이 있었기에ㅡ,,ㅡ) 되도록이면 처음부터 위치정보나 기본정보를 지우고 찍는걸 추천해 드리며, 업로드 시에도 주의해서 업로드 하시길 바랍니다.


그리하야, 드디어 이미지속 나의 정보를 지키는 방법에 대하여 알아보았습니다.

다음글에서는 “SNS 글에서 추출가능한 정보들” 에 대하여 알아보겠습니다.

jwmsg

OSINT 특집[1] – 오신트가 머임?

안녕하세요, 저어어엉말로 오랜만에 글을 써보는 맛소금 해커 입니다.
요즘들어 인스타그램이나, 페이스북 등 개인 SNS 를 애용하는 사람들이 늘어나고 있습니다. 자신의 일상을 공유하고, 셀카를 올리는 등, 다양한 목적으로 SNS 를 이용하면서 세상과 소통하곤 합니다.

하지만, 우리가 잊고 있던 몇가지들이 있습니다. 사소한 정보, 사소한 사진, 사소한 내용의 글 이더라도 그 속에서 다양한 개인정보 혹은 민감한 정보들을 찾아낼 수 있습니다. 그래서 이제는 SNS 를 이용하는데에도 더더욱 주의해야 합니다.

오늘부터 특집으로 OSINT 관련된 내용으로 글을 써볼까 합니다. (과연 제가 성실히 글을 잘 작성할지는 모르겠지만) 앞으로 잘 부탁드립니다.


OSINT 가 뭐임?

Open Source INTelligence 의 약어로, “공개 정보(원천)” 를 이용한 “인텔리전스” 입니다. 여기서 Open Source(공개정보) 라고 함은 말 그대로, 온라인/오프라인 상에 공개되어, 얻을 수 있는 모든 정보들을 칭하는 말로, SNS/Github/영상매체/블로그/홈페이지 댓글 등 다양한 곳에서 추출해 낼 수 있는 정보들을 말합니다.

OSINT 의 종류로는 IMINT(영상/이미지 정보), HUMINT(인간 정보), SIGINT(신호정보) 등이 존재하며, 수집하는 방법도 다양합니다.

사실 이걸 글로만 쓰면 이해하기 싫고 노잼일게 분명합니다. 그러니, 다음 글부터는 직접 추출해보면서 자세하게 각각을 알아보도록 하겠습니다.

다음 글에서는 IMINT 정보를 수집/추출하는 방법을 알아보고, 이를 대비하는 방법에 대하여 알아보도록 하겠습니다.

jwmsg

FAT32 파일 추출 삽질기 – 해캠에서 실패했던 시연 설명

하,,,,, 제가 멍청했습니다. 하위 클러스터 바이트가 0076 이면, 데이터영역 시작이 2번 클러스터 이니까. 데이터 영역 기준으로 74클러스터 만큼 이동해야 하는데, 76클러스터만큼 이동해서 시그니처를 찾지 못했군요,,,

그래서, 아래에 FAT32 파일 추출을 한번 설명해볼까 합니다. 이미지파일은 해캠에서만 배포하였고, 해당이미지는 트레이닝을 위한 어느 한 포렌식 트레이닝 사이트에서 받은 이미지 내부에 FAT32 영역 500메가만 불러왔어요. 저작권이나 뭐나 그럴 수 있으니, 따로 공유하지는 않겠습니다.


순서는 다음과 같습니다

  1. VBR 영역에서 1섹터당 몇바이트인지 알아오기 (off = 0x0B , 2Byte)
  2. VBR 영역에서 1클러스터당 몇 섹터인지 알아오기 (off = 0x0D , 1Byte)
  3. VBR 영역 에서 예약된 섹터 수가 몇개인지 알아오기 (off = 0x0E , 2Byte)
  4. VBR 영역에서 FAT 영역이 몇개인지 알아오기 (off = 0x10, 1Byte)
  5. VBR 영역에서 하나의 FAT 영역의 크기는 몇 섹터인지 알아오기 (off = 0x24, 4byte)
  6. VBR 영역에서 루트디렉터리(루트 클러스터) 번호 알아오기(off = 0x2C, 4byte).
  7. Dir Entry 영역 에서 파일명(off = 0x00, 11Byte)
  8. Dir Entry 영역에서 상위 클러스터 2바이트(off=0x20, 2Byte)
  9. Dir Entry 영역에서 하위 클러스터 2바이트(off=0x30, 2Byte)

** 각 영역에서부터 오프셋이 시작되니 착오 없으시길 바랍니다.

여기서 알 수 있는것은

FAT 시작 오프셋 = (예약된 섹터 수 * 1섹터당 바이트 수)

DATA영역 시작 오프셋 =
(FAT 시작 오프셋 + FAT영역갯수 * FAT 1개 영역 크기 * FAT 영역 갯수)

파일의 시작 오프셋 =
(DATA영역 시작 오프셋 + ( (시작 클러스터 번호 4바이트 – 루트클러스터번호) * 1클러스터 당 섹터수 * 1섹터당 바이트 수) )

파일의 끝 오프셋 =
일단, FAT시작 오프셋으로 갑니다.
그 위치는 0번 클러스터를 가르치는 부분입니다.
그렇다면, 76번 클러스터니까, 4byte * 76 하면 76클러스터의 할당정보가 나오죠.
해당 클러스터 할당정보에 적힌 다음 클러스터번호로 넘어갑니다.
당연히 해당위치는 FAT시작 오프셋에서 4Byte * 해당 다음 클러스터 번호가 되겠죠
쭉 가다보면 FFFFFF0F 가 보일것입니다. EOF 입니다.
드디어 해당 위치의 오프셋에서 FAT 시작 오프셋을 빼고 4로 나누면,
몇번째 클러스터 인지 알 수 있습니다.
해당 클러스터가 마지막 클러스터 입니다.
그 마지막클러스터 오프셋은
(DATA영역 시작 오프셋 + ( (마지막 클러스터 번호 4바이트 – 루트클러스터번호) * 1클러스터 당 섹터수 * 1섹터당 바이트 수) ) 이며,
해당 위치에서 (1클러스터 당 섹터수 * 1섹터당 바이트 수) 만큼만 더 가면
그 위치가 파일의 끝 오프셋이 됩니다.


발표에서 실패했던 이유가 DATA 영역 시작 위치는 2번 클러스터니까, 76번 클러스터로 가려면, 당연히 74번 클러스터를 뛰어 넘어가야 하는데, 제가 멍청하게 76번 뛰어넘어가면서 78번 클러스터를 보여드렸습니다.

위 방식을 추후 눈으로 볼 수 있는 이미지 파일로 정리를 하여 공개하도록 하겠습니당 ㅠㅜ

추가로 그 FAT툴 시연 영상입니다

jwmsg

FAT32 분석기 – 1

요즘에는 잘 사용하는지는 모르겠으나, 몇년전까지만 해도 대부분의 USB와 SDCard 같은 경우 FAT32를 쓰곤 했습니다.  파일시스템을 공부하면서 FAT 이미지 에서 데이터를 카빙하거나, 디렉터리 목록을 긁어오는등을 하며 조금 감각을 익혀가긴 했었는데,, 과도한 입시 공부를 하느라(거짓말) 파일시스템이 기억도 안나고 감각이 무뎌져 다시 공부를 시작했습니다.

일단, 그냥 글로만 보면 이해가 잘 안되서, C++로 코드를 작성하고 Sample 이미지를 기반으로 공부를 해 나가보겠습니다. 일단 이번 글에서는 FAT32의 기본적인 부부분만 짚고 넘어가 봅시다!

일단, FAT는 File Allocation Table 의 약자 입니다. 이는 매우 단순한 파일시스템 입니다. 과거 XP이전 시대때 주로 사용되었고, 현재는 작은 용량의 저장소 (흔히 2~16기가 미만)의 파일시스템 입니다.

기본적인 FAT 구조

위 그림은 기본적인 FAT 구조 입니다. 일단 먼저 예약된 영역에는 이 파일시스템을 정의(?)하는 영역입니다. 주로 첫 섹터에 부트섹터가 존재합니다. 부트섹터에서는 아래와 같은 정보를 알 수 있습니다.

BootSector 구조체
(표로 만들기 힘들어서,,, ㅠㅜㅠㅜ 조만간 표로 만들어서 업데이트 할께요,,)

여기서 가장 중요한것들만 모아 봤습니다. 이 아래에 있는 목록들만 있어도 충분히 FAT32의 디렉터리, 데이터 들을 분석할 수 있고, 카빙도 가능합니다.

  • (Dec)11~12 번째 offset의 섹터당 바이트수
  • (Dec)13 번째 offset 에 있는 클러스터당 섹터수,
  • (Dec)14~15번째 offset의 예약된 영역의 섹터크기
  • (Dec)16번째 offset의 FAT영역의 개수
  • (Dec)36~39번째 offset의 FAT 영역의 섹터 수
  • (Dec)44~47번째 offset의 루트디랙터리의 클러스터 번호 (주로 2 입니다.)

일단 여기까지 글의 시작을 알리며  다음 내용 (FAT32의 디렉터리 정보를 불러오기)를 통해 계속 이어나가겠습니다. 아 참, 그리고 EVTX 도 이어서 올리도록 하겠습니다!

jwmsg

evtx 파일 구조분석 – 3

지난 글에서는 File Header 를 분석하여 chunk의 위치를 찾는 방법을 알아보았습니다. 이번 글에서는 Chunk 내에 있는 Header 를 분석하여 Recoard 의 위치를 찾아가고, Recoard 를 읽어가는 방법에 대하여 알아보도록 하겠습니다.

Chunk 내에 존재한 Header로 0x200 의 길이이다.

이번 역시 위 구조로는 눈에 안들어오니 HXD와 함께 삽질을 시작해 봅시다.

Magic 시그니처로 ElfChnk 입니다.
이 Chunk 에서 첫번째의 레코드의 번호를 명시 합니다.
이 chunk 에서 가장 마지막의 레코드의 번호를 명시합니다.
FirstLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.
이 또한 마찬가지로 LastLogRecordNum 과는 별 차이를 알 수 없으나
아마 첫번째 레코드를 의미하는것으로 알고 있습니다.
String table Offset 이라고 되어 있으나
제 추측상 File header 와 마찬가지로, Header 영역에 제일 상단영역의 크기 같습니다.
보통 0x80 입니다.
마지막 레코드의 Offset 입니다.
주의! 상대적인 위치입니다, Chunk 의 첫 offset 을 기준으로 합니다.
만약 새로 레코드가 추가될경우, 
세로운 레코드가 시작할  offset 의 위치 입니다.
Chunk 내에 존재하는 레코드들의 CRC 입니다.
레코드들의 무결성을 확인 할 수 있습니다.
사용되지 않는 알수 없는 영역인데,
예약된 영역, 혹은 Padding 영역이라고 생각이 듭니다.
플레그 영역 입니다.
상위 해더의 CRC 입니다.
String 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)
템플릿 테이블로 어떤 값들이 저장되어 있긴 한데,,, 뭔지 아직 잘 모르겠습니다.
추후 알아보고 업데이트 하겠습니다,
(추측이지만,, 뭔가 바이너리 XML 과 연관 되어있지않을까요?)

그럼 이제 레코드 위치를 찾아보도록 하겠습니다.
먼저 Chunk 의 해더는 0x200 이었습니다.
그렇다면 chunk의 offset + 0x200 하면 첫번째 레코드의 offset이 나오겠네요!
그리고 다음 레코드로 넘어가려면 현재 레코드 길이만큼 뛰어넘으면 될것 같네요!

이번글은 여기서 마치도록 하겠습니다. 이번글은 약간 chunk 의 구조만 집중적으로 알아보고 다른 내용이 없네요 ㅠㅜ

이제 다음장에서는 레코드 영역을 제대로 분석하여보고, BinaryXML 이 무엇인지 간단히 알아보겠습니다.