- 깃허브, 24년 한 해 저장소에서 3,900만 건 이상의 비밀정보 유출(발견) - 문제를 해결하기 위해 고급 보안 기능(GitHub Advanced Security)을 전면 개편
내용
- 비밀정보 유출은 최근 소프트웨어 개발 과정에서 가장 심각한 보안 위협 중 하나로 부상 > 작년 한 해 동안 깃허브의 비밀정보 스캔(Secret Scanning) 기능을 통해 3,900만 건이 넘는 민감 정보가 공개 및 비공개 저장소에서 발견 > 개발 속도가 빨라질수록 비밀정보 유출도 그만큼 증가하고 있음을 보여줌
- 깃허브 > 22.04 비밀정보가 포함된 코드를 푸시(Push)하는 것을 방지하는 ‘푸시 보호(Push Protection)’ 기능을 도입 > 24.02부터는 이를 모든 공개 저장소에 기본 적용 > 그럼에도 불구하고 비밀정보가 여전히 유출되는 주된 이유 ① 개발자들이 커밋 과정에서 편의성을 우선시하거나 ② Git 기록을 통해 실수로 저장소가 공개되는 경우가 많기 때문
- 깃허브는 문제를 해결하기 위해 고급 보안 기능(GitHub Advanced Security)을 전면 개편 ① 비밀 보호(Secret Protection)와 코드 보안(Code Security) 기능를 분리해 개별 제품으로 출시 > 기존 : 통합형 보안 제품군 > 중소 규모 개발팀도 저렴한 비용으로 고급 보안 기능을 사용할 수 있게됨
② 조직 전체를 대상으로 한 무료 비밀 위험 진단 기능이 제공 > 공개, 비공개, 내부, 보관 저장소까지 포함해 모든 저장소에서 민감 정보를 점검할 수 있도록 함
③ 푸시 보호 기능에는 ‘우회 권한 위임’ 기능이 추가 > 특정 사용자나 팀에게만 비밀정보가 포함된 커밋의 푸시를 허용하는 정책을 설정할 수 있음 > 조직 차원의 정책 기반 통제가 가능해짐
④ 인공지능 기반 코파일럿(Copilot)을 활용해 구조화되지 않은 비밀번호 등의 비밀정보도 탐지할 수 있도록 함 > 탐지 정확도를 높이고 오탐률을 줄여주는 효과
⑤ AWS, 구글 클라우드, 오픈AI 등 주요 클라우드 서비스 제공업체들과의 협력 > 더 정밀한 비밀정보 탐지기를 구축하고 유출 발생 시 빠르게 대응할 수 있도록 체계를 강화
기타
- 보안 전문가들 권고 > 개발 과정에서 민감 정보를 코드에 직접 입력하지 말고 환경 변수나 비밀관리 도구, 보안 금고(Vault)를 통해 분리 저장할 것 > CI/CD 파이프라인이나 클라우드 플랫폼과 연동 가능한 도구를 활용해 비밀정보를 자동으로 처리 (인적 실수로 인한 노출을 줄이는 것이 중요) > 주기적인 감사와 보안 관리 가이드라인 숙지
- Palo Alto Networks GlobalProtect VPN 포털을 대상으로 한 스캔 활동이 급증 - 약 2만4천 개 고유 IP 주소가 관여하였으며, 향후 취약점 악용 가능성에 대한 우려 증가
내용
- 25.03.17부터 시작돼 하루 최대 2만 개에 달하는 고유 IP 주소가 스캔 시도 > 03.26까지 규모 유지 > 23,800개 IP는 ‘의심스러운(suspicious)’ 활동으로 분류됐으며, 154개는 실제 ‘악의적인(malicious)’ 활동을 한 것으로 확인 > 03.26 PAN-OS 크롤러 활동 급증 )해당 스캔에는 별도로 2,580개 IP 확인)
- 위협 인텔리전스 기업 그레이노이즈(GreyNoise) > 네트워크 스캔 급증은 일반적으로 새로운 취약점 공개나 악용 시도에 앞서 발생하는 사전 정찰(Reconnaissance)의 전형적인 패턴
- 스캔 활동의 방식도 일정하고 일관성이 높음 > 단순한 자동화된 스캔이 아니라 특정한 방어 체계를 시험 및 분석하려는 조직적인 공격 준비 단계일 가능성이 큼
- 관련 장비 운영 중인 관리자 대상 권고 > 시스템 로그 면밀히 분석 > 공격 징후를 사전에 탐지해 방어 체계 강화 > 특히 3월 중순 이후의 로그를 검토해 이상 활동이 있었는지 점검 > 로그인 포털의 보안 강화 > 확인된 악성 IP 차단 리스트 등록
- 팔로알토네트웍스 > 관련 스캔 활동에 대해 인지 > 해당 활동의 영향을 분석하고, 필요한 대응 조치를 파악하기 위해 모니터링 중 > 최신 버전의 PAN-OS를 사용해 보안 기능을 최적화할 것을 고객들에게 권고
기타
- 보안 전문가들 권고 > 실제 공격으로 이어질 가능성이 있음 > VPN과 포털 보안에 대한 대비책을 지금부터 강화 > 취약점이 발견되기 전이라도 최신 보안 패치를 적용 > 의심스러운 네트워크 접근을 지속적으로 모니터링 > 관리 인터페이스에 대한 접근 제어와 다중 인증을 엄격히 적용 등 권고
- 사이버보안 연구진이 랜섬웨어 조직 ‘블랙락(BlackLock)’의 온라인 인프라에 침투 - 주요 운영 정보 확보
내용
- 블랙락(BlackLock) > 이전에 엘도라도(Eldorado)라는 이름으로 활동 > 24.03경부터 활동을 본격화한 Ransomware-as-a-Service(RaaS) 조직 > 기술, 제조, 건설, 금융, 유통 등 다양한 산업 및 미국, 영국, 캐나다, 프랑스, 이탈리아 등 여러 국가를 공격
- 미국 보안 기업 리시큐리티(Resecurity) > 블랙락이 다크웹에서 운영하던 데이터 유출 사이트(DLS)에 로컬 파일 포함(Local File Inclusion, LFI) 취약점이 존재함을 발견 > 해당 취약점은 웹 서버에 경로 이동(Path Traversal) 공격을 가해 서버 내부 정보를 불법으로 열람할 수 있도록 함 > 연구진은 이를 통해 서버 설정 파일, 계정 자격증명, 운영자가 입력한 명령어 기록 등 민감한 정보를 확보 * 블랙락 조직에게 있어 매우 심각한 운영 보안(OPSEC) 실패로 평가됨
- 유출된 데이터 분석 결과 ① 데이터 탈취 방식 > 피해자의 시스템에서 탈취한 데이터를 클라우드 서비스인 MEGA로 전송하기 위해 Rclone 툴 사용 > 일부 경우 피해자의 컴퓨터에 MEGA 클라이언트를 직접 설치한 흔적 발견
② 일회용 이메일 사용 > YOPmail과 같은 일회용 이메일 서비스로 만든 계정으로 최소 8개의 MEGA 계정을 생성해 피해자 데이터 보관
③ 기존 랜섬웨어와의 유사성 > 역공학 분석 결과, 드래곤포스(DragonForce) 랜섬웨어와 소스코드 및 협박 메시지에서 유사한 부분 발견 > 드래곤포스는 Visual C++로 작성, 블랙락은 Go 언어를 사용 > 개발 방식은 다르지만 상호 연관 가능성이 제기
④ 공격 파트너 모집 > 블랙락의 핵심 인물로 알려진 ‘$$$’는 25.01 중순부터 지하 커뮤니티에서 공격 초기 침투를 수행할 파트너 모집 > 이들은 악성 사이트로 피해자를 유도해 초기 접근 권한을 확보한 후 랜섬웨어를 설치하는 역할
기타
- 랜섬웨어 조직 간의 경쟁 또는 조직 통합의 신호 > 블랙락의 데이터 유출 사이트가 드래곤포스에 의해 변조 > 마모나(Mamona)의 사이트도 동일하게 변조
- 능동적 대응 전략을 통해 사이버 범죄 생태계에 실질적인 타격을 줄 수 있음을 보여줌 > 공격 기법이 계속 진화하는 만큼, 지속적인 경계와 보안 커뮤니티 간 협력이 앞으로도 중요할 것으로 보임
- KISA, 해킹 진단 도구 업데이트 - 리눅스 추가 지원 및 사용자 편의 기능 등 추가
내용
- KISA 해킹 진단 도구 > 23년 기업이 자체적으로 해킹 사고 여부를 점검할 수 있도록 개발 및 시범 배포 > 24년 정식 버전 배포 및 지속적 기능 개선 > 관리자 계정 접속 시도나 데이터 유출 시도 등의 주요 증거 데이터를 분석 > 해킹 여부를 빨강(심각)-주황(주의)-녹색(정상) 3단계로 제시 > 점검 결과를 통해 해킹이 의심되면, KISA에 침해사고 분석 기술지원 서비스를 받아 원인 분석부터 재발 방지 대책 수립까지 지원받을 수 있음
- 이번 업데이트에서 리눅스 추가 지원을 통해 활용 범위 확대 > 윈도우용 점검 도구는 사용자 편의를 돕기 위해 증거 데이터 수집 항목 추가, 탐지룰 제작 기능 개선, 신규 탐지룰 탑재 등의 기능을 추가
- Ingress란 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음 [1][2][3][4] -Ingress Controller란 Ingress 리소스에 정의된 규칙을 읽고, 해당 규칙에 따라 트래픽을 라우팅 [1][2][3][4] - Ingress NGINX Controller란 NGINX를 역방향 프록시 및 로드 밸런서로 사용하는 Kubernetes용 Ingress Controller [5][6]
2. 주요내용 [7]
- Ingress NGINX Controller의 구조적 설계 문제로 공격자가 악의적인 Ingress 객체를 전송하여 임의의 NGINX 설정을 주입할 수 있음
> 취약점 악용에 성공 시 클러스터 내 모든 시크릿 노출, 원격 코드 실행 등이 가능
- Admission Controller는 사용자의 요청을 변조(Mutate)와 검증(Validation)을 통해 요청의 승인 여부를 결정
> 기본적으로 인증 없이 누구나 접근 가능한 상태로 배포되어 네트워크를 통해 액세스 가능
※ 변조(Mutate) : 사용자의 요청을 사전 정의된 변형 규칙에 따라 요청을 변경
※ 검증(Validation) : 요청이 기준에 맞는지 확인하여 해당 요청을 승인 또는 거절
- Admission Controller는 Admission Webhook Endpoint를 통해 Kubernetes API 서버와 통신
> AdmissionReview 구조로 통신
> 일반 적으로 Kubernetes API 서버만 AdmissionReview 요청을 보내야 하지만, Admission Controller는 누구나 접근 가능하기 때문에 임의의 AdmissionReview요청을 전송할 수 있음
[사진 1] Admission Controller
- Ingress NGINX Controller는 AdmissionReview 요청을 처리할 때 템플릿 파일과 제공된 Ingress 객체를 기반으로 임시 NGINX 구성 파일을 생성
> 임시 파일 생성 후 nginx -t 명령을 사용해 임시 구성 파일의 유효성을 테스트
> 이때, 적절한 검증이 없어 조작된 Ingress 객체를 전송해 임의의 NGINX 구성을 삽입할 수 있음
[사진 2] nginx -t
2.1 취약점
2.1.1 CVE-2025-24514 [9]
- authreq 파서는 인증 관련 주석을 처리하는 역할을 수행
> 주석에는 URL을 포함하는 auth-url 필드를 설정해야 하며, 해당 값을 적절한 검증 없이 $externalAuth.URL에 포함
> ngnix -t 명령을 실행할 때 명령에 포함되어 실행
2.1.2 CVE-2025-24513 [10]
- 부적절한 입력 값 검증으로 Directory Traversal 공격이 가능
> 이를 통해 DoS 또는 제한된 비밀 객체 노출 발생 가능
2.1.3 CVE-2025-1097 [11]
- authtls 파서는 auth-tls-match-cn 주석을 CommonNameAnnotationValidator를 사용하여 필드 값을 검증
> auth-tls-match-cn 주석은 CN=으로 시작
> 이를 통해 임의의 코드 실행이 가능
2.1.4 CVE-2025-1098 [12]
- mirror-target과 mirror-host Ingress 주석을 사용하여 nginx에 임의의 구성을 삽입할 수 있음
> 이를 통해 임의의 코드 실행이 가능
2.1.5 CVE-2025-1974 [13]
- 특정 조건 하에서 Pod Network에 액세스할 수 있는 인증되지 않은 공격자가 임의 코드 실행이 가능
3. 대응방안
- 벤더사 제공 보안 업데이트 적용 [14][15][16][17]
제품명
영향받는 버전
해결 버전
Ingress NGINX Controller
1.11.0 미만
1.11.5
1.11.0 이상 ~ 1.11.4 이하
1.12.0
1.12.1
- 추가 모니터링 및 필터 적용
> Admission Controller가 Kubernetes API 서버에서만 접근 가능하도록 접근 제한
> Admission Webhook Endpoint가 외부에 노출되지 않도록 설정
> Admission Controller 컴포넌트가 불필요할 경우 비활성화
> Helm을 사용하여 ingress-nginx를 설치한 경우 controller.admissionWebhooks.enabled=false로 설정하여 재설치 > 수동으로 ingress-nginx를 설치한 경우
① ValidatingWebhookConfiguration에서 ingress-nginx-admission 삭제
② ingress-ngin-controller 컨테이너의 Deployment 또는 Daemonset에서 '--validating-webhook' 인수 삭제
// Middleware to remove the x-middleware-subrequest header
app.use((req, res, next) => {
delete req.headers['x-middleware-subrequest'];
next();
});
- WAF에서 x-middleware-subrequest 헤더를 포함한 요청을 차단하도록 설정
- 탐지룰 설정
alert tcp any any -> any any (msg:"CVE-2025-29927 x-middleware-subrequest Detected"; flow:to_server,established; content:"x-middleware-subrequest|3A|"; http_header; pcre:"x-middleware-subrequest\s*:\s*(pages\/_middleware|middleware|src\/middleware)"; )
