토요일 오후...
고객으로부터 홈페이지 접속이 안된다는 연락이 왔다.
"일시적인 장애인가..."
폰으로 사이트 접속을 해보니 404 오류가 발생하였다..
평소에 일시적인 장애가 발생할 때와 다른 증상이었다..
"404 오류가 왜 발생하지?"
"어??? 404는 서버와는 통신이 정상적으로 되었고... 다만, 클라이언트가 요청한 페이지를 찾을수 없다는 오류가 아닌가..."
순간 등골이 오싹해져왔다...
"원격데스크톱"으로 서버에 접속해보니.. 아래와 같은 창이 뜬다..
Just for money
If you want to unlock the server and data, please contact us
jin423f4345@ctemplar.com
================
서버와 데이터의 잠금을 해제하시려면 나에게 연락하십시오.
jin423f4345@ctemplar.com
돈을 위해
랜섬웨어 상태
D드라이브가 비트로커로 암호화 되어 있고,
C드라이브는 초기화가 되어 있었다.
헤커는 서버에서 다음과 같은 작업을 한 것이다.
1. 어떤 취약점인지는 모르겠지만 서버강탈
2. C의 SQL 기본 폴더에 있는 파일들을 전부 D에 복사
3. D드라이브를 비트로커로 암호화
4. C드라이브를 초기상태로 복구
랜섬웨어 조치
사실 백업만 완벽했다면 굳이 복구할 필요가 없었다.
해당 서버의 백업정책은 D드라이브는 백업용도, 그리고, D에 백업된 파일이 NAS로 전송되도록 한 상태였다.
하지만, 트래픽 비용이 만만치 않아 한달정도 전에 NAS 백업을 중지한 상태였고, 대안을 모색중이었다.
즉... D드라이브는 반드시 복구를 해야 되는 상황이었다.
그래서, 헤커에게 메일을 보내니 다음과 같은 회신이 왔다.
(메일1)
Hello, please tell us the ip address of your server so that we can confirm the information. We are only for money, we only accept Bitcoin.
Sent From CTemplar Secure Email
바로 아이피 정보를 메일로 보내니 몇시간뒤.. 0.3비트코인을 알려준 지갑으로 전송하면 복호화키를 준다고 하였다.
(메일2)
You only need to pay 0.3 Bitcoin to unlock the disk.
We have backed up your data in the d:\data directory.
Please don't worry about losing database files.
If you agree to pay 0.3 bitcoins, we will tell you later, our bitcoin wallet address, after we receive 0.3 bitcoins, we will immediately tell you to decrypt the password, uninstall the backdoor, and Trojan. Guarantee that you will not invade you again.
We only do it for money.
Sent From CTemplar Secure Email
(메일3)
After we receive 0.3 Bitcoin, we will tell you the decryption password immediately. Uninstall all backdoors and Trojan horses. Guarantee that you will not invade you again.
The following is our Bitcoin wallet address.
=========================================================
38HTY8rUi5qw9afDFZv9sHDME1DzHghD9C
=========================================================
Sent From CTemplar Secure Email
당시 시세로 800만원 정도였다. ( 요즘은 훨씬 커졌지만.. )
헤커에게 비트코인 전송방법을 모른다.. 다른 수단은 안되냐.. 라고 하니.. 친절(?)하게도 전송방법과 몇가지 협박메일이 또 왔다.
(메일4)
By the way, please do not track the flow of Bitcoin, we will buy Bitcoin, Litecoin, U.S. dollars, British pounds, etc. multiple times. Money laundering.
We use at least two levels of agencies and at least two countries. And the terminal we use is also 4G / 5G purchased anonymously.
In addition, please do not try to guess the password and perform data recovery, otherwise we will not be responsible for the data loss caused by this. Please do not format the disks. No organization or individual in the world can crack BitLock.
If you don't know how to buy and send Bitcoin, the website will tell you how to proceed.
Bithumb, Coinone, and Upbit
Sent From CTemplar Secure Email
이 상황에서는 어쩔수 없이 헤커의 요구에 응할수밖에 없는 상황이 된다.
헤커의 입장에서는 돈만 입금되면 복구에 노력해줘야 다음 예비고객에 대한 신뢰도가 높아지니 믿고 입금하라고 한다..
해당 계좌로 0.3비트코인을 전송하려고 하니..
바로는 전달이 되지 않고 하루 뒤에 전달이 된다는 안내가 뜬다..
헤커에게 얘기를 하니 한국의 법이 그런가보다 하면서 마음 푹 놓고 쉬고 있으란다..
신경질이 나면서도 안심이 되는 맨트이기도 했다..
다음날... 전송이 무사히 되었고... 정말 다행히도 복호화키를 받았다.
( 이때의 심정은 참 묘하다... 헤커가 친밀하게 느껴진다고 해야 하나... 아무튼 겪어본 사람만 알듯.. )
(메일5)
We have received your 0.3 bitcoins. Now tell you the decryption password, please record it.
=============================================================
455xCVG3rdsf345234dsf34f2342sf%U413
=============================================================
If you have any questions, please contact us.
We will do our best to serve you.
Sent From CTemplar Secure Email
서버를 켜고 복호화를 진행하였다.
그런데, 갑자기 불안한 생각이 들었다...
D드라이브의 용량은 거의 100%를 차지하고 있었다..
왜 그럴까??
순간... 헤커가 D로 파일을 옮기면서 용량 되는데까지만 복사하고 나머지는 남겨두었거나... 아니면 D에 있는 파일을 지우고, C에 있는 디비파일을 복사했을수도 있겠다는 생각이 들었다...
거의 반나절이 지나서 복구가 되었다...
상태를 확인하고 좌절에 빠졌다.
D에 있는 백업파일이 많이 지워졌고, C에 있는 디비파일을 복사했는데.. 그나마 모두 복사한거도 아니고 100% 용량이 찰때까지만 복사한 것이다...
현재 상태로는 고객 50% 정도만 살릴수 있었다..
이제 다음 수순으로 넘어가야 했다..
C드라이브를 살려야 한다.
해커에게 이 상황을 얘기하고 조심스럽게 물어보았다.
C드라이브를 초기화할 때 복구 불가능하게 초기화를 했냐? 아니면 그냥 단순 초기화를 했냐?
다행히 단순초기화를 했다는 회신이 왔다..
그리고는, 현재상황에서는 자기가 도와줄 상황이 안되니 당장 복구업체에 달려가서 복구를 시도해보라고 한다..
이자식 죽여버리고 싶지만... 현실적이다...
이제 희망은 C드라이브는 단순 초기화를 시켰다는 사실 하나만 남았다...
하지만... 단순 초기화했다고 하더라도, 데이터 위에 운영체제 파일이 덮어써져있는 것은 복구 못하게 된다...
그리고, 윈도우 업데이트가 자동으로 실행되어서 업데이트 파일이 데이터파일이 존재하는 위에 일부 받아졌다면...
데이터 복구는 설 연휴가 걸쳐있어서... 연휴 끝나고 디스크를 받아왔다..
다행히 꽤 많은 부분을 살릴수는 있었지만...
그렇지 못한 것도 꽤 많이 존재했다...
C와 D 양쪽에서 살린 데이터를 조합해서 할수있는 최대한의 피해복구(전체 피해의 70~80% 정도)를 하고...
이제 재발방지에 대한 계획을 세워야 한다..
(참고로, MSSQL은 MDF와 LDF 파일이 있는데, MDF 만 있으면 복구가 가능)
혹시나 싶어 헤커에게 다시 메일을 보냈다..
재발 방지를 위해 충고해줄 말이 없냐고...
윈도우보안패치와 백업을 게을리 하지 마라...
C8
랜섬웨어 대책 마련
D 드라이브가 암호화될 정도라면 루트권한이 강탈되었다는 뜻일테고..
그럼 두가지 중 하나로 해킹되었을 것같다.
- 서버 차제의 취약점
- 홈페이지의 취약점
서버는 불행히도 윈도우2008이다..
보안패치 서비스가 중지된...
꽤 오래된 서버이고... 탑재된 고객이 많아서 쉽게 윈도우 업그레이드를 하지 못했었다.
<서버조치>
윈도우는 다시 설치한 상태라 어떤 취약점이 있었는지는 확인할 수 없지만, 대략 다음과 같은 절차로 설정하였다.
- SMB 취약점 처리
- MSSQL 서비스 계정을 일반 계정으로 설정
- 불필요한 서비스 사용중지
- 방화벽 점검
<홈페이지 조치>
홈페이지는 자체 개발한 홈페이지와 외주를 주고 개발한 홈페이지들이 혼재하고 있다.
자체 개발한 홈페이지는 SQL인젝션과 웹쉘에 대한 대비책을 고려하고 만들었지만, 외주를 주고 개발한 예전 홈페이지들은 제대로 돌아가는지만 확인하고 사실상 소스 차원의 점검은 하지 못했었다.
그래서, 모든 소스를 열어서 SQL인젝션 체크를 하였다.
우려했던데로 많은 부분에 SQL인젝션 취약점이 존재했다.
웹나이트로 앞단에 간단한 방지책이 있기는 하지만, SQL인젝션 취약점은 존재해서는 안된다.
그래서, 모든 get,post 전달인자를 바로 쿼리 문자열 조합으로 사용한 부분을, SQL 변수로 전달하는 식으로 수정하였다.
그리고.. 웹쉘은 기본적으로 첨부파일들이 저장되는 폴더에 스크립트 실행권한이 존재하게 되면 발생한다.
( 가상폴더를 만들게 되면 기본적으로 권한이 부여된 상태로 만들어지니 반드시 해제해야 한다. )
현재는 서버가 재설정된 상태라 확인을 할 수가 없지만... 안타깝게도... 일부 사이트에서 asp, php 파일이 업로드가 되고 있었다.. ( 첨부파일 업로드에서 확장자 체크를 하지 않은 사이트들이 존재했다. )
그래서... 복구된 파일들중 첨부파일경로에 asp, php 파일들이 없는지 체크해보니... 파일이 발견이 되었다..
해당 파일을 분석해보니... 외부에서 전달된 쿼리를 실행하는 놈이었다...
만약... 이 폴더에 스크립트권한, 실행권한이 있었다면... 이놈이 범인일 가능성이 높았다.
아무튼... 첨부파일이 업로드되는 폴더가 가상폴더로 지정되어 있고, 그 가상폴더가 스크립트권한,실행권한이 존재한다면 모두 제거해주어야 한다.
<웹사이트 공통적인 환경점검>
나머지 모든 사이트들에 대해서는 아래와 같은 점검을 하였다.
- 500번대 에러메시지를 전부 404 페이지로 변환(헤커들은 페이지 오류메시지를 통해서 추측을 할 수 있으므로)
- 업로드폴더에서의 파일실행권한 해제
- 디렉터리 노출 해제(디렉터리검색 체크해제 확인)
- WebDAV 비활성화 확인
- robots.txt 에서 입력폼 페이지는 전부 거부 ( 오류나는 페이지들만 구글링을 통해 검색할수도 있으므로 )
<백업정책 설정>
별도의 백업서버로 전송하던 것을 구글드라이브로 대체하였다.
그리고, 전체 디비 백업은 한달에 한번 직접 방문하여 외장하드에 담아오고,
로그백업은 매일 D의 특정폴더에 저장되게 하였다.
그 D의 특정폴더는 구글드라이브에 저장이 된다. ( 만약 D가 날라가도, 구글드라이브는 히스토리 기능이 있으므로 대처가 가능할 것으로 생각된다. )
이제 다시... 트래픽이 문제가 되는데, 구글드라이브에는 송수신 속도 제한을 거는 메뉴가 있어서, 계약된 트래픽을 초과하지 않는 범위로 설정하였다.
<재발 발생시>
위와 같은 경험을 하고 보니.. 만약 꼭같은 일을 당한다면 아래와 같은 절차로 진행할 것이다. 헤커와 협상한다는 자체가 굴욕적이기는 하지만.. 반드시 복구해야 되는 데이터라면 대안은 없다고 생각이 된다... ( 나중에 어떤분의 경험담을 읽어보았는데, 아마도 해커는 서버를 해킹할때는 아이피를 키로 해서 암호화시키고, 일반 피씨를 해킹할 때는 동일한 키를 사용하는 듯 하다.. )
- 파워 오프 ( 윈도우업데이트가 자동 실행되어 업데이트파일이 다운로드 받아져서 C드라이브가 덮어써질수 있으므로 최대한 빨리 파워오프)
- 헤커에 연락해서 D드라이브에 대한 복구키는 획득할것
- C 드라이브는 복구업체에 맡김
혹시나 비트로커 랜섬웨어에 걸려 고민하시는 분을 위해 경험담을 올려보았습니다.(파일 단위 암호화가 아닌, 드라이브 자체에 암호화를 거는 비트로커 랜섬웨어에 대한 경험담이니 혼동없으시기 바랍니다. )
'보안' 카테고리의 다른 글
| SMTP서버 구축 및 SPF(TXT) 레코드 수정 (2) | 2024.01.05 |
|---|---|
| netstat를 이용해서 네트워크 상태(백도어 탐지)를 분석하는 방법(윈도우) (1) | 2024.01.04 |