jwmsg
안녕하세요. 맛소금 해커 입니다.
아마 이 페이지에 접근 하셨다면, 제가 만든 해킹 USB 를 컴퓨터에 연결 하셨을 겁니다.
해당 해킹 USB 는 정보보안 교육을 위해 특수 제작되었으며,
실제 해킹을 시도하지는 않고, 이 페이지를 띄워 주의를 주고 있습니다.
길, 또는 사무실 등 지에서 발견된 알 수 없는 USB 또는 신원을 알지 못하는 사람이 건내어준 USB는 되도록 PC에 연결하지 마시고,
모든 USB 또는 저장장치에 대해 의심하는 습관을 가지셔야 자신의 소중한 개인정보를 비롯하여, PC 에 저장된 소중한 데이터들을 안전하게 지켜낼 수 있습니다.
부디 이번 경험을 통해, 정보보안에 한걸음 더 다가가셨으면 하는 바램 입니다.
습득하신 USB 는 적절한 위치에 다시 떨어뜨려, 다양한 사람들이 아무런 USB 를 꼽았을때 위험 할 수 있다는 점을 인지 할 수 있도록 협조 부탁드립니다.
추가로 궁금하신 점이 있으시다면 본 사이트 아래 연락처로 연락 바랍니다.
감사합니다.
jwmsg
그렇습니다. 저도 갑작스럽게 이 RCE 가 터져서 문제가 좀 생겼습니다.
아마 이 게시물에 들어오신분들은 저와 같은 상황에 처해있거나 GITLAB CE/EE 운영하다가 문제가 생기신 분들일 가능성이 있습니다 저도 중 많이 받았어요.
특히 저처럼 AWS Lightsail 사용하시는분들도 꼭 확인하셔야 하는 이유가 있습니다. 저도 처음엔 당황스러웠는데요.
AWS 에서 메일이 날아왔습니다….
그래서 일단 부지런하게 원인이 뭔지 좀 밝혀내야 하지 않을까하고 페북에다가도 수소문을 해서 조금 검색해보니 최근 (2021년 11월 1일쯤?) 문제가 좀 있었던것 같습니다.
깃랩의 설명에 따르면 이미지 올리거나 할때 EXIF 영역을 제거하는 부분이 있는듯합니다. 그래서 그부분을 ExifTool 이라는 녀석이 받아서 처리하는데, 이 ExifTool 이라는 녀석에게 RCE 취약점이 발견된것 같습니다. (EXIF에 대한 내용은 여기로)
일반적으로 gitlab.com 은 문제가 되지 않구요, 별도로 자체 Gitlab을 서버에 올려서 사용하시는 CE 또는 EE 유저들은 필히 이 문제를 꼭 확인하시기 바랍니다.
다음 버전의 서버에서 발생하는데 보통 다들 깃랩 같은서버는 한번 올려놓고 딱히 업데이트 안하는것 같아서 이번에 대부분의 서버들은 패치되어야 할것 같습니다.
일단 깃랩에서 친절하게 잘 설명하고 있습니다.
그런데 일단 한글로도 정리를 해야할것 같아서 여기다가 정리를 해보려 합니다.
/var/log/gitlab/gitlab-workhouse 아래에 current 라는 로그파일이 있습니다. 해당 파일에서 grep 을 이용하여 “exiftool command failed” 를 검색하면 되는데요.
대충 뭔갈 다운받은듯한데, 뭔가 수상쩍은 stderr 혹은 stdout 부분이 발견되신다면 일단 내 서버가 털렸을 것에 집중을 하셔야 합니다.
해당 시간에 맞는 nginx 의 로그를 확인해 보셔도 좋습니다.
일단 빼박,, 저는 뭔가 느낌이 좋지 않습니다..
지금 저도 공격 벡터 찾아서 분석중인데, 시간이 좀 걸릴것 같습니다.
확실한건 이번주 주말(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
개인적으로 즐겨 보는 트위치 방송이 있는데, 해당 방송 스트리머가, 왜에? 왜? 를 10분동안 듣는 영상도 있었고, 2020년 06월 13일 방송분에서, WAE 바이러스 언급이 있었다.
https://www.twitch.tv/jinjalim/video/649662807
1시간 47분쯤..
암튼 기발한 영감을 얻은 나머지, 맛소금해커는 닉값을 하기 위해 바이러스를 만들었다.
Malwares.com 결과 입니다.
진짜 바이러스가 아니라, 바이러스 처럼 보이게 만든것 이므로 너무 겁먹지 않으셔도 좋을것 같습니다.
아무튼, 할짓없어 빈둥대는 맛소금해커의 뻘짓중 하나였습니다. 감사합니다.
jwmsg
하,,,,, 제가 멍청했습니다. 하위 클러스터 바이트가 0076 이면, 데이터영역 시작이 2번 클러스터 이니까. 데이터 영역 기준으로 74클러스터 만큼 이동해야 하는데, 76클러스터만큼 이동해서 시그니처를 찾지 못했군요,,,
그래서, 아래에 FAT32 파일 추출을 한번 설명해볼까 합니다. 이미지파일은 해캠에서만 배포하였고, 해당이미지는 트레이닝을 위한 어느 한 포렌식 트레이닝 사이트에서 받은 이미지 내부에 FAT32 영역 500메가만 불러왔어요. 저작권이나 뭐나 그럴 수 있으니, 따로 공유하지는 않겠습니다.
순서는 다음과 같습니다
** 각 영역에서부터 오프셋이 시작되니 착오 없으시길 바랍니다.
여기서 알 수 있는것은
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툴 시연 영상입니다