Langflow 1.3.0과 Rails 5.2.2.1 — 오래된 패치선 두 개가 지금 다시 두들겨 맞는 중

이미지 출처: The Hacker News

테스트용으로 띄워둔 웹 서버 액세스 로그를 훑다 보면, 사람이 아니라 기계가 남긴 흔적이 확연히 눈에 띄는 구간이 있다. 몇 초 간격으로 같은 경로를 두드리는데, 그 목록에 /api/v1/validate/code 같은 요청이 섞여 있고, 또 어떤 요청은 URL은 평범한데 Accept 헤더가 이상하게 길다. 하나는 AI 워크플로 도구인 Langflow를 노린 것이고, 다른 하나는 Ruby on Rails의 파일 노출 결함을 노린 것이다. 둘 다 패치가 나온 지 꽤 됐는데도, 공격자들의 스캔 목록에서는 아직 지워지지 않았다.

핵심 요약

• Langflow의 코드 검증 엔드포인트 결함(CVE-2025-3248)과 Rails Action View의 파일 내용 노출 결함(CVE-2019-5418)이 하나의 자동화 스캔 세트로 묶여 관측되고 있음
• 목적은 단순 정찰이 아니라 설정 파일·자격증명 수집과 C2 연결 확보이며, 특히 Rails의 secret_key_base 유출은 세션 위조를 거쳐 코드 실행까지 이어질 수 있음
• 방어는 버전 상향이 1순위지만, 그와 함께 인증 경계·아웃바운드 통제·자격증명 재발급까지 묶어서 처리해야 실제로 끝남

1. 왜 이 둘이 한 세트로 들어오는가

겉보기에 접점이 없어 보이는 두 제품이 같은 캠페인에서 관측되는 이유는 단순하다. 공격자 입장에서 이 둘은 성격이 같은 매물임.

• 둘 다 인증 없이 단일 HTTP 요청으로 결과를 확인할 수 있어 대량 스캔에 적합함
• 둘 다 성공 여부가 응답만 봐도 바로 구분되어, 자동화 도구가 표적 목록을 추리기 쉬움
• 둘 다 개발·내부용으로 띄워두고 잊힌 인스턴스가 많아, 패치 적용률이 낮음

즉 이건 정교한 표적 공격이라기보다, 인터넷 전체를 훑는 그물망에 가까움. 문제는 그 그물에 한 번 걸리면 그다음 단계는 자동으로 진행된다는 점.

2. Langflow 쪽에서 벌어지는 일

Langflow는 LLM 파이프라인을 시각적으로 조립하는 도구라, 사용자가 작성한 파이썬 코드 조각을 다루는 기능이 구조적으로 들어가 있음. 문제가 된 지점은 이 코드 검증 기능이었음.

• 사용자 코드를 문법 검사한다는 명목으로 서버에서 파싱한 뒤, 일부 구문 요소가 평가(evaluate)되는 경로가 존재했음
• 검사 자체는 안전해 보여도, 함수 정의의 기본값이나 데코레이터처럼 "정의만 해도 값이 계산되는" 위치가 있으면 그 순간이 실행 시점이 됨
• 해당 엔드포인트가 인증을 요구하지 않았기 때문에, 외부에서 그대로 호출 가능했음

공격 코드를 굳이 옮겨 적을 필요는 없고, 핵심 교훈만 기억하면 됨. "검증"과 "실행"은 생각보다 가까운 이웃이라는 것. 사용자 입력을 언어 파서에 넘기는 기능이 있다면, 그 파서가 어디까지 계산을 수행하는지 반드시 확인해야 함. 수정은 1.3.0 계열에서 이루어졌고, 이 결함은 실제 악용이 확인되어 봇넷이 감염 장비를 끌어모으는 통로로 쓰인 전력이 있음. 감염 이후 흐름은 대체로 스크립트 내려받기 → 상주 → 외부 C2 접속 순서로 정형화되어 있음.

3. Rails 쪽 — 헤더 한 줄로 설정 파일을 읽어가는 방식

Rails 결함은 성격이 다름. 코드 실행이 아니라 파일 내용 노출임. Action View가 요청의 Accept 헤더에 담긴 값을 템플릿 경로 결정에 활용하던 시절, 그 값에 상위 디렉터리 참조가 섞이면 의도치 않은 파일이 렌더링 대상이 될 수 있었음.

• 공격자가 실제로 노리는 파일은 뻔함 — config/database.yml, config/secrets.yml, .env, 그리고 credentials 관련 파일
• 여기서 DB 접속 정보가 나오면 곧장 측면 이동 재료가 되고, 클라우드 키가 나오면 계정 자체가 흔들림
• 가장 위험한 건 secret_key_base 유출. 이 값은 세션 쿠키 서명에 쓰이므로, 유출되면 공격자가 임의의 세션을 만들어낼 수 있고 역직렬화 경로와 결합될 경우 원격 코드 실행으로 승격될 여지가 생김

수정 버전은 5.2.2.1, 5.1.6.2, 4.2.11.1, 그리고 6.0 계열 초기 버전에서 배포됐음. 문제는 이 취약점이 실패해도 조용하고 성공해도 조용하다는 점. 서버는 200을 돌려주고, 애플리케이션 에러 로그에는 아무것도 남지 않을 수 있음.

4. 탐지 포인트 — 어디를 보면 보이는가

두 사안 모두 네트워크 경계 로그에서 잡아내는 편이 현실적임. 개인적으로는 아래 순서로 확인하는 걸 추천함.

• Accept 헤더 길이·형태 이상: 정상 브라우저의 Accept 값은 패턴이 정해져 있음. 여기에 경로 구분자나 상위 디렉터리 표기가 들어간 요청은 그 자체로 유의미한 신호
• 인증 없이 도달한 API 경로: 관리·검증·디버그 성격의 엔드포인트에 인증 헤더 없는 200 응답이 남았는지 확인
• 동일 IP의 다품종 스캔: 한 소스가 Langflow 경로와 Rails 경로를 연달아 두드렸다면 캠페인성 스캔으로 봐도 무방
• 아웃바운드가 진짜 증거: 애플리케이션 서버가 갑자기 낯선 IP로 HTTP 요청을 보내거나, curl·wget·셸 프로세스를 새로 띄웠다면 그건 이미 다음 단계임
• 응답 크기의 급변: 평소 수 KB짜리 응답을 내던 경로가 갑자기 다른 크기를 돌려줬다면 파일 노출을 의심

5. 완화 — 버전만 올리고 끝내면 안 되는 이유

패치는 당연히 1순위지만, 이미 스캔에 걸렸을 가능성을 전제로 움직여야 함.

• Langflow는 고정 버전 이상으로 올리고, 애초에 인터넷에 직접 노출하지 않는 것이 정답에 가까움. 필요하다면 VPN이나 리버스 프록시 인증 뒤에 둘 것
• Rails는 지원 버전으로 올리되, 노출 정황이 조금이라도 있으면 secret_key_base와 DB 자격증명을 재발급. 값이 이미 새어나간 뒤라면 패치는 문을 닫을 뿐 열쇠를 회수해주지는 않음
• 애플리케이션 컨테이너의 아웃바운드를 기본 차단하고 필요한 목적지만 허용. C2 단계에서 끊어내는 가장 값싼 방법
• 설정 파일을 소스 트리에 두지 말고 환경변수나 시크릿 매니저로 분리. 파일이 읽혀도 건질 게 없게 만드는 접근
• 내부에서만 쓰는 도구라도 자산 목록에 올려둘 것. 이번 사례에서 털리는 건 대부분 "누가 언제 띄웠는지 모르는" 인스턴스임

6. 사후 점검 체크리스트

• 해당 서버의 crontab, systemd 유닛, 시작 스크립트에 낯선 항목이 추가됐는지
• 임시 디렉터리에 실행 권한이 붙은 파일이 생겼는지
• 웹 서비스 계정으로 실행된 셸 프로세스 이력이 있는지
• 노출됐을 수 있는 자격증명이 다른 시스템에서 재사용되고 있지는 않은지

이번 건을 보면서 다시 확인한 건, 새 취약점보다 이미 알려진 취약점의 잔존율이 훨씬 무섭다는 사실이다. Rails 쪽 결함은 나온 지 한참인데도 여전히 스캔 목록 상단에 남아 있고, Langflow처럼 최근에 급하게 퍼진 도구는 아예 "설치했다는 사실 자체를 잊은" 사례가 많다. 공격자는 새로운 걸 찾는 게 아니라, 고쳐지지 않은 걸 찾는다.

오늘은 다른 것 말고 딱 두 가지만 해봐도 좋겠습니다. 우리 조직에서 인터넷에 노출된 웹 서비스 목록을 한 번 뽑아보는 것, 그리고 그중 버전을 마지막으로 확인한 게 언제인지 적어보는 것. 막상 적어보면 생각보다 오래된 항목이 나오거든요. 여러분 환경에서는 어떤 잊힌 서비스가 나왔는지 댓글로 공유해주시면 저도 같이 정리해보겠습니다. 같이 해보아요!