Railway 보안 공개: 환경 변수 유출 및 모든 배포 중단
Railway는 10월 21일에 승인되지 않은 제3자가 고객 환경 변수에 접근했을 수 있으며, 그중 일부는 암호 해독된 내용을 얻었을 수 있다고 공개했습니다. 플랫폼은 모든 고객에게 모든 비밀을 회전하라고 알리는 동시에 모든 배포를 중단했습니다. 이 공개에 대한 Hacker News 스레드(547점, 318개 댓글)는 도난당한 키가 이미 사용되었다는 개발자들의 보고와 하나의 운영상 모순으로 가득합니다: 사용자들은 자격 증명을 회전하라는 지시를 받았지만, 빌드가 비활성화된 상태에서는 새 값을 적용하기 위해 재배포할 수 없습니다.
Railway가 실제로 공개한 내용
Railway는 10월 21일 아침에 고객 환경 변수를 저장하는 시스템에서 비정상적인 활동을 감지했으며, 현재까지의 조사에 따르면 승인되지 않은 제3자가 암호화된 환경 변수에 접근했을 수 있고, 그중 일부는 암호 해독된 내용을 얻었을 수 있다고 밝혔습니다.
공개 내용에서:
오늘 아침 일찍, Railway는 고객 환경 변수를 저장하는 시스템과 관련된 비정상적인 활동을 감지했습니다. 추가 조사 후, 현재까지의 조사에 따르면 승인되지 않은 제3자가 암호화된 환경 변수에 접근했을 수 있으며, 그중 일부는 암호 해독된 내용을 얻었을 수 있습니다. 환경 변수에는 API 키 또는 데이터베이스 및 레지스트리 자격 증명과 같은 비밀이 포함될 수 있습니다.
Railway가 밝힌 주요 사항:
- Railway의 환경 변수에는 API 키, 데이터베이스 자격 증명, 개인 레지스트리 자격 증명과 같은 비밀이 포함될 수 있습니다.
- Railway는 이 침입이 "AI 추론 제공자를 손상시키는 것을 목표로 플랫폼 기업을 최근 표적으로 삼은 일련의 공격"의 일부라고 믿고 있습니다.
- Railway는 이러한 업스트림 제공자에게 사전에 키를 폐기할 수 있도록 통보했다고 밝혔습니다.
- Railway의 초기 분석은 영향이 일부 사용자에게만 국한될 수 있음을 시사하지만, 모든 사용자가 예방 조치로 행동할 것을 권장합니다.
- 권장 조치: "Railway에 저장된 모든 환경 변수(API 키 포함)와 개인 레지스트리 자격 증명을 즉시 회전하고, 해당 서비스의 로그에서 비정상적인 활동을 검토하십시오."
- Railway가 조사하는 동안 모든 배포가 중단되었으므로, 빌드가 복원될 때까지 사용자는 새 버전을 배포할 수 없습니다.
- Railway는 확인된 영향을 받은 계정에 이메일로 직접 연락할 것이며, 블로그 공지 및 status.railway.com에 업데이트를 게시할 것이라고 밝혔으며, 사건 번호 QH8L8B3E를 참조했습니다.
핵심 모순: 비밀을 회전하되 재배포는 불가
스레드에서 가장 반복되는 불만은 Railway의 두 지침이 많은 사용자에게 상호 배타적이라는 것입니다: Railway 내에서 비밀을 회전하는 것은 해당 서비스가 재배포될 때까지 실행 중인 서비스에 영향을 미치지 않으며, 배포는 중단되었습니다.
"배포를 비활성화한 상태에서 키를 어떻게 회전할 수 있습니까? 기본적으로 우리 서비스를 오프라인으로 전환하라는 말입니다..." — fyzix
"다운타임 없이 비밀을 회전하는 방법을 설명해 주시겠습니까?" — fmvilas
"OpenRouter가 이 사건을 기반으로 이전 키를 폐기함에 따라 env var의 API 키를 변경했습니다. 그러나 제 지역에서는 재배포가 불가능하여 env를 업데이트할 수 없고 이제 제품을 사용할 수 없습니다." — averrous
여러 댓글 작성자는 조언을 따른 결과 이전보다 더 나빠졌다고 설명했습니다. 현지 시간으로 오전 5:20에 키를 회전한 한 개발자는 로그에 잘못된 사용 흔적이 없었으며, 조치를 취하지 않았다면 서비스가 "적어도 온라인 상태를 유지했을 것"이라고 썼습니다. 다른 한 명은 키를 폐기한 후 앱이 다운되었고 재배포할 수 없다고 말했습니다. rdm_blackhole은 Railway가 버킷 자격 증명을 재생성했지만 배포가 중단된 상태로 유지되어 서비스가 버킷에 전혀 연결할 수 없게 되었다고 보고하며, 이러한 순서를 "완전히 어리석다"고 비판했습니다.
rdm_blackhole은 또한 스레드 후반에 빌드가 CET 오전 11:43에도 여전히 대기열에 막혀 있고, 재배포 없이는 키를 효과적으로 회전할 수 없으며, Discord 인증이 불가능하고, 대시보드의 지원 링크가 404 페이지로 이어진다고 보고했습니다.
개발자들은 유출된 키가 이미 사용되었다고 보고
스레드에는 도난당한 자격 증명이 공개 전후에 제3자에 의해 사용되었다는 여러 직접 보고가 포함되어 있습니다 — 특히 LLM API 키.
"밤새 프로덕션 비밀을 회전하고 있습니다... 좋습니다. 그들이 이미 내 비밀 키 중 많은 것을 실제로 사용한 것을 확인했습니다." — dylanz
"Railway Discord에서 여러 사람이 Railway에 저장된 비밀이 제3자에 의해 사용되었다는 것을 확인하는 것을 보았습니다. 공격자가 암호 해독된 환경 변수를 읽을 수 있었던 것이 확실해 보입니다." — MattIPv4
스레드의 구체적인 보고:
- 한 댓글 작성자는 Railway 배포에 사용된 Anthropic API 키가 Railway 공지 후 약 3시간 만에 승인되지 않은 남용 증거로 인해 비활성화되었으며, 남용이 감지되기 전에 약 20달러의 토큰 사용이 발생했다고 말했습니다.
- 다른 한 명은 OpenRouter 키가 도난당하여 약 2달러의 요금이 발생했다고 말했습니다.
- 세 번째는 OpenRouter 대시보드에서 자신이 만들지 않은 Anthropic 모델에 대한 API 호출이 표시되었고, 로그에 Go HTTP 클라이언트와 공급자로 Anthropic만 사용된 것으로 나타났다고 말했습니다. 그들은 "주요 표적이 LLM API 키였을 가능성이 높습니다..."라고 썼습니다.
- cowlby는 10월 21일 CDT 오후 5:54:13에 Railway 직원이 수행한
BucketInstanceCredential.regenerated감사 로그 항목을 게시했으며, 데이터베이스 및 버킷 자격 증명이 환경 변수에 있다면 공격자가 데이터베이스 및 버킷 내용에도 접근했을 가능성이 있다고 추론했습니다.
또 다른 댓글 작성자는 도난당한 LLM 키가 어떻게 현금화되는지 질문하며, 손상된 키로 저렴한 추론을 재판매하는 의심스러운 AI 멀티플렉서를 추측했습니다 — 스레드에서 답변되지 않은 질문입니다.
"AI 추론 제공자를 표적으로 한 공격"이라는 프레임은 회의론을 불러일으킴
Railway의 캠페인이 AI 추론 제공자를 손상시키는 것을 목표로 한다는 진술은 맥락으로 보편적으로 받아들여지지 않았으며, 일부 댓글 작성자는 이 프레임 자체를 책임 회피로 읽었습니다.
"모든 보안 침해 공개에 이제 '공격자가 AI를 사용했습니다!'라는 문구가 필수로 포함되는 것이 웃깁니다. 마치 안전한 시스템을 유지해야 하는 책임에서 면제되는 것처럼. 오히려 상황을 더욱 비난하게 만듭니다. AI를 사용하여 취약점을 찾을 수 있었다면 자체 레드 팀이 공격자보다 먼저 찾았어야 했습니다." — paxy
다른 사람들은 공개에서 답변되지 않은 기본적인 아키텍처 질문을 제기했습니다: 암호화된 비밀이 어떻게 해독되었는지.
"비밀이 어떻게 해독되는지, 이해할 수 있도록 설명을 듣고 싶습니다... env 비밀이 어떻게 모두에게 유출되는지..." — minraws
"누군가 환경 변수와 해당 암호화 키를 모두 얻은 것입니까? 지금 거기 있는 보안 운영 엔지니어들이 안타깝습니다. 잔인하네요" — ksajadi
공개 내용은 해독이 어떻게 발생했는지 또는 영향을 받은 계정 수를 명시하지 않았습니다.
커뮤니케이션 및 타이밍 불만
반복되는 주제는 사용자가 이메일이 도착하기 훨씬 전에 Discord 서버나 상태 페이지에서 사건에 대해 알게 되었다는 것입니다.
"사람들은 3시간 전, 사건 시작 후 10시간 만에 Railway 전용으로 만든 키가 사용량을 발생시키고 있다고 Discord에 쓰고 있었습니다. 한편 빌드는 12시간 이상 중단되었습니다. 지금에서야 모든 고객에게 이메일을 보냈습니다." — alpineman
한 댓글 작성자는 23:36에 이메일을 받았다고 말했고, 유럽 개발자는 소식을 듣고 일어났을 때 배포가 이미 24시간 동안 중단되어 있었다고 말하며 "이 사실을 오전 2시까지 기다렸다는 것이 말도 안 된다"고 덧붙였습니다. 다른 한 명은 공개가 블로그 하위 도메인에 있는 반면 마케팅 홈페이지는 여전히 "소프트웨어를 평화롭게 배송하세요"라고 읽히며 사건에 대한 언급이 없다고 지적했습니다.
별도로, 한 댓글 작성자는 "Railway는 지난 대규모 중단의 이유에 대해 정직하지 않았습니다"라고 주장했고, 다른 한 명은 올해 초 고객 데이터를 유출한 이전 사건 이후 이미 주요 고객을 Railway에서 이전했다고 말했습니다.
같은 날의 더 넓은 맥락
댓글 작성자들은 Railway 사건을 보안 팀에게 나쁜 24시간의 일부로 프레임화했습니다.
"사이버 보안에 미친 하루: PHP RCE, eMudhra 인증서, 그리고 이제 Railway. 그리고 이제 시작일 뿐이라고 생각합니다." — vldszn
이 댓글은 eMudhra 인증서 손상에 대한 Cloudflare 게시물과 PHP RCE에 대한 Wiz 게시물에 연결됩니다. 다른 댓글 작성자는 Railway 사건을 주말에 opencode가 겪은 해킹과 비교했고, 한 명은 다음에 "Vercel SNAFU"를 보고 일어날 것이라고 농담했습니다.
이전 논의: VPS, Cloud Run, fly.io, 자체 호스팅
여러 댓글 작성자는 이 사건과 며칠간의 배포 중단이 플랫폼을 떠나게 만든다고 말했습니다.
- 한 개발자는 Railway의 이전 중단 후 Cloud Run으로 이전을 고려했고, 플랫폼에 또 다른 기회를 주었지만 이제 머무를 가능성이 낮다고 말했습니다.
- 다른 한 명은 최소한의 중단으로 fly.io로 긴급 이전을 수행했으며, 환경 변수를 변경할 수 있도록 즉시 이전할 것을 조언하며 "Railway에 한 푼도 더 주지 마세요"라고 덧붙였습니다.
- 또 다른 한 명은 Coolify로 데이터베이스를 자체 호스팅으로 이전했다고 말했습니다.
- 한 명은 프로젝트를 직접 호스팅하기 위해 현재 Hetzner 또는 OVH 중 어떤 VPS가 가장 좋은지 물었습니다.
다른 댓글 작성자는 환경 변수 패턴 자체에 반대하며, 코드와 함께 git에 비밀을 버전 관리하는 오픈 소스 임베디드 비밀 저장소를 홍보했습니다. Rust, Go, PHP, Python, JS/TS, C#/.NET, PowerShell, bash에서 사용할 수 있습니다.
Railway 사용자를 위한 실질적인 현재 상황
스레드에 포착된 논의 기준으로 상황은 다음과 같습니다: 빌드가 중단되어 영향을 받은 계정에서는 회전된 자격 증명을 적용하기 위한 재배포가 불가능합니다. OpenRouter를 포함한 업스트림 제공자가 사전에 키를 무효화한 것으로 보고되었습니다. Railway는 확인된 영향을 받은 계정에 이메일을 보낼 것이라고 밝혔습니다.
공개 및 스레드에서 직접 따르는 단계:
- Railway 환경 변수에 저장된 모든 비밀(데이터베이스 자격 증명, 버킷 자격 증명, 개인 레지스트리 자격 증명, API 키 포함)을 잠재적으로 손상된 것으로 취급하십시오.
- 공급자 대시보드 및 서비스 로그에서 승인되지 않은 사용을 검토하십시오. 여러 댓글 작성자는 자체 애플리케이션 로그가 아닌 공급자 대시보드에서 사용 증거를 찾았습니다.
- 회전 후 재배포가 필요하므로 빌드가 중단된 동안 계속된 다운타임을 예상하십시오. 복원을 위해 status.railway.com 사건 QH8L8B3E를 주시하십시오.
- 프로젝트에서 직원이 시작한 자격 증명 재생성 이벤트가 있는지 Railway 감사 로그를 확인하십시오.
여전히 답변되지 않은 질문
공개 및 스레드는 여러 질문을 남겨두며, 자료의 어떤 출처도 이를 해결하지 않습니다:
- 암호화된 환경 변수가 어떻게 해독되었는지, 그리고 암호화 키 자체가 얻어졌는지 여부.
- 영향을 받은 계정의 정확한 수 또는 비율.
- 빌드가 언제 재개될지.
- 손상된 API 키가 공격자에 의해 어떻게 현금화되는지.
- Railway가 빌드가 돌아오면 고객 서비스를 자동으로 재배포할지 여부. 한 댓글 작성자는 이를 명시적으로 희망했지만 결과를 테스트하지 않을까 걱정했습니다.
한 댓글 작성자의 실용적 계산 요약이 스레드의 분위기를 포착합니다: 배포가 중단된 상태에서 "무엇이 더 나쁜가: 도난당한 키 또는 고장난 제품?"
Sources
관련
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch