Exploit without Coffee

type safety 란 무엇인가. Basic Type Safety “잘 형식화된 프로그램은 잘못될 수 없다.” 이 구문은 Robin Milner이 1978년 작성한 A Theory of Type Polymorphism in Programming 에서 언급된 말로 Type Safety를 직관적으로 보여줍니다. Going wrong 프로그래밍 언어는 구문과 의미에 따라 정의된다. 모든 언어가 직면한 문제는 구문적으로 유효하지만 의미상으로 문제가되는 프로그램이 많다는 것이다. 영어를 예로 들자면 Chomsky의 “Colorless green ideals sleep furiously”를 볼 수 있는 데, 구문은 완벽하지만 의미가 없다. 다른 예로 OCaml 프로그래밍 언어의 1 + "foo"; 와 같은 구문은 프로그램에서 어떠한 의미도 없다. C언어에서 { char buf[4]; buf[4] = 'x' } 는 인덱스 4에 대한 버퍼 영역을 벗어나고 있으며, 언어적으로 이에 대한 조치가 정의되어 있지 않으므로 의미가 없다고 말할 수 있다. 이러한 무의미한 프로그램을 운영하다면 go wrong 이라 말할 수 있다. Well typed -> Cannot go wrong type-safe language에서 타입 시스템은 올바른 프로그램만 통과시킨다. 특히 우리는 프로그램이 타입 시스템이 허용한 좋은 형식의 프로그램은 type safety를 보장하고 프로그램의 의미가 잘못되지 않을 것이라 생각한다. Which languages are type safe? 이제 인기 좋은 몇몇 언어들이 타입 안전성이 보장되는 언어인지 아닌지 살펴보겠다. 우리는 각기 다른 언어에서 다양한 의미로 적용되고 있는 타입 안전성을 알 수 있다. C와 C++: not type safe. C의 표준 타입 시스템은 버퍼의 끝을 쓰는 것과 같이 일반적 관행을 벗어나는 프로그램을 배제하지 않는다. 따라서 작성된 C 프로그

CVE-2017-8759 1. 취약 버전 확인은 닷넷 프레임워크 버전으로 진행 닷넷 프레임워크 버전과 공용 언어 런타임 버전은 별개이며 취약점 발생 요인은 닷넷 프레임워크로 닷넷 프레임 워크 버전으로 취약 유무를 판별하면 됩니다. 여기서 런타임은 JVM과 같이 프로그램 구동을 위한 가상의 실행 환경으로 이해하면 될 것 같습니다. 취약점 발생은 닷넷 프레임워크 wsdlparser.cs의 PrintClientProxy()메소드에서 줄바꿈 처리 미흡으로 발생되었습니다. 2. 취약점 동작 방식 닷넷 프레임워크 소스코드 다운로드 URL: https://referencesource.microsoft.com/download.html 먼저 POC 핵심을 살펴보겠습니다. < service name = "Service" > < port name = "Port" binding = "tns:Binding" > < soap:address location = "http://localhost?C:\Windows\System32\calc.exe?011" /> < soap:address location = "; System.Diagnostics.Process.Start(_url.Split('?')[1], _url.Split('?')[2]); //" /> </ port > </ service > 위는 POC 구성 중 원격 서버에서 받아오는 XML 데이터의 일부입니다. 두개의 “soap:address location” 엘리먼트로 구성되어 있는 것을 볼 수 있습니다. 다음은 취약점이 발생한 wsdlparser.cs의 PrintClientProxy()메소드의

CVE-2017-21615, CVE-2017-21616 취약점 요약 CVE-2017-12615 영향: 하. 기본 설정 상 PUT 메소드를 허용하지 않으며, 보안 표준을 어기는 사항이므로 발견 시 개선 프로세스 진행. 위협: JSP 업로드. 조건: Tomcat Version 7.0.0-7.0.79에서 PUT Method 허용 상세: PUT 메소드로 서버에 존재하지 않는 “test.jsp”파일 요청을 보낼 경우, 서블릿 컨테이너에서 “test.jsp” 내 정의된 PUT 메소드를 수행하려 하므로 404 Error를 반환한다. 그러나 “/”, “%20”, “:: DATA”와 같은 특수문자를 제거하여 실제 서버에 JSP 파일이 저장된다. 확인 방법: grep -r 'readonly' [톰캣 디렉터리]/conf/web.xml 취약 버전에서 readonly를 false로 정의한 경우 취약 테스트를 위한 web.xml 설정 PUT 메소드가 허용된 톰캣 서버에 curl -X PUT http://TEST.com/test.jsp/ -d "test" 을 전송할 경우, jsp 혹은 jspx 요청이 아니므로 defaultservlet으로 PUT 메소드를 처리하게 된다. 그런데 java.io.Win32FileSystem 의 파일 생성 과정에서 수행하는 파일 명 표준화 시 불필요하게 인식한 특수문자를 제거(‘/’, ‘%20, ‘::$DATA’)함으로써 결과적으로 JSP 파일이 업로드된다. < init-param > < param-name > readonly </ param-name > < param-value > false </ param-value > </ init-param > CVE-2017-12616 영향: 중. 이미지, CSS 파일, JS 파일이 저장된 외부 디렉터리를 연결하는 설정으로 소스 디렉터리(JSP) 이와 같은 방법

Linux BlueBorne vulnerabilities 리눅스 블루투스 스택(BlueZ)에서 두 개의 보안 취약사항이 발견되었다. 이 취약점들은 2017년 9월 12일자로 공개 되어 BlueBorne 이라는 이름으로 불리고 있으며, 해당 취약점을 보유하고 있는 벤더 사 제품이 존재하여 총 8개의 취약점으로 분류되어졌다. 1) CVE-2017-1000250 이 취약점은 bluetoothd 프로세스에 존재하며, SDP server 요청을 처리하는 과정에서 나타난다. service_search_attr_req (src/sdpd-request.c) 함수에서 sdp 검색 요청 속성을 처리할 때 정보를 유출한다. 이로 인해 희생자 단말 사용자와 상호작용 없이, 어떤 사전의 인증 없이(페어링), 스택의 Service discovery protocol (SDP) server를 엑세스할 수 있다. 이 취약점은 bluetooth 프로세스의 힙으로 부터 정보 유출을 유도할 수 있으며, 여기에는 블루투스 암호 키나 다른 가치있는 데이터가 포함된다. Simple Service Discovery Protocol SSDP(Simple Service Discovery Protocol)은 네트워크 서비스나 정보를 찾기 위해서 사용하는 네트워크 프로토콜이다. SSDP를 이용하면, DHCP나 DNS와 같은 네트워크 서버 혹은 정적인 호스트 설정 없이 이런 일들을 수행할 수 있다. SSDP는 일반 거주지와 소규모 사무 환경에서 UPnP(Universal Plug and Play)를 위한 기본적인 프로토콜로 이미 널리 사용하고 있다. 1999년 MS와 HP가 IETF에 드래프트 했다. IETF제안이 만료된 이후 SSDP는 UPnP 표준에 포함됐다. 이 취약점의 세부사항을 살펴보자. 출처: joinc - SSDP 이 취약점의 세부사항을 살펴보자. - SDP 서버 검색 속성 핸들러( service_search_attr_req, under s

C 프로그램 메모리 구조 C 프로그램 메모리 구조는 일반적으로 다음의 섹션으로 나타낸다. - Text segment - Initialized data segment - Uninitialized data segment - Stack - Heap high address+----------------------+ | |command+line arguments | |and environment variables +----------------------+ | stack | | + | | | | | v | | | | ^ | | | | | + | | heap | +----------------------+ | uninitialized data |initialized to | (bss) |zero bt exec +----------------------+ | initialized data |read from +----------------------+program file | text |by exe

C++ 언어 공통 취약점 C++는 C가 아니다. 이것이 무엇보다 첫 번째로 염두해야할 점이다. printf() , char* 와 유사한 것들을 사용하지 말고 C++의 방향성대로 코드를 진행하자. 만약 C의 방식을 고수해야한다면 C의 보안 표준 또한 함께 참고한다. Memory handling malloc() 과 free() 함수를 사용하지 않고 new() 와 delete() 함수를 사용한다. 코드에서 Exception 발생 시 new 에 의해 할당된 메모리는 할당 취소된다. String handling char* 를 사용하지 않고 std::string 클래스를 사용한다. fscanf 를 사용하지 않고 std::outputstream 오브젝트와 함께 >> 연산자를 사용한다. File handling fopen() 함수를 사용하지 않는다. 읽기 위해서는 std::ifstream 를 사용한다. 쓸 때는 좀 더 복잡한 고려사항이 있는 데, C의 open 플래그 값과 함께 open() 호출하고 boost 라이브러리를 사용하면 파일 기술자 자체에서 좋은 스트림을 얻을 수 있다. #include <boost/iostreams/device/file_descriptor.hpp> #include <boost/iostreams/stream_buffer.hpp> #include <iostream> #include <sys/stat.h> #include <sys/types.h> #include <fcntl.h> namespace io = boost::iostreams; class ex {}; int main () { int fd = open( "/my/file" , O_WRONLY|O_CREAT|O_EXCL, 0600 ); if (fd == - 1 ) throw ex(); io::s

C 언어 공통 취약점 해당 글은 CERN Computer Security의 Common vulnerabilities guide for C programmers 글을 참고하여 작성하였습니다. C언어에서 발생하는 대부분의 취약점은 버퍼 오버플로우와 문자열 처리 미흡과 관련되어 있다. 이는 segmentation fault를 유발하고 입력 값을 조작할 경우 임의 코드 실행으로 이어질 수 있다. 이에 대부분의 에러와 조치 방안을 살펴보자고 한다. gets stdio gets() 함수는 버퍼 길이를 검증하지 않아 사용 시 항상 취약성을 야기한다. Vulnerable Code #include<stdio.h> int main() { char username[ 8 ]; int allow = 0 ; printf ( "Enter your username, please: " ); gets(username); //악의적인 값 삽입 if (grantAccess(username)) { allow = 1 ; } if (allow != 0 ) { //username을 오버플로우하여 덮어씀 privilegeAction(); } return 0 ; } Mitigation fgets() 함수 사용 및 동적 메모리 할당 #include <stdio.h> #include <stdlib.h> #define LENGTH 8 int main () { char * username, *nlptr; int allow = 0 ; username = malloc (LENGTH * sizeof (*username)); if (!username) return EXIT_FAILURE; printf ( "Enter your username, please:

화이트박스 암호 기술 본 내용은 ETRI의 화이트박스 암호 및 응용 기술 동향 분석 문서를 참고하여 작성한 글입니다. 등장 배경 지금까지 암호 알고리즘은 동작하는 단말과 단말의 신뢰를 토대로 제 3자가 해독할 수 없게 하는 것을 목표로 만들어졌다. 그러나 사용자가 사용하는 단말에 심어진 악성 프로그램이나, 공격자가 공격을 위해 암호화 통신에 참여할 수 있으므로 통신하는 양쪽을 신뢰할 수 없는 것이 현실이다. 이에 TPM, 스마트카드와 같은 하드웨어를 활용한 대안이 제시되고 있으나 비용증가 및 설치의 어려움의 문제를 안고 있다. 이를 해결하고자 등장한 화이트 박스 암호 기술은 소프트웨어만으로 암호 키를 안전하게 보관할 수 있고, 신뢰할 수 없는 단말에서 암호화 알고리즘이 실행되더라도 암호 키가 드러나지 않도록하는 기술이다. 암호 기술 AES 화이트박스 암호를 활용하여 기본 원리와 동작 메커니즘을 알아보자. 화이트 박스 암호 원리 암호 키가 신뢰할 수 있는 장치에서 관리된다고 가정했던 기존의 암호 메커니즘과 달리 화이트박스 암호 메커니즘에서는 끝단의 장치를 신뢰하지 않고 암호 키를 암호 알고리즘에 섞어 암호 키를 쉽게 볼 수 없게 하였다. 즉, 화이트박스 암호는 알고리즘을 큰 룩업테이블로 만들고 그 안에 암호 키를 암호 알고리즘과 뒤섞인 상태로 숨겨둠으로써 내부의 동작을 분석하더라도 암호 키를 쉽게 유추하지 못하도록 하는 기법이다. 암호 알고리즘을 하나의 큰 룩업테이블로 만들면 크기가 지나치게 커지므로, 분리하되 중간 값이 노출되지 안도록 인코딩과 디코딩을 수행한다. 인코딩 과정( )과 디코딩 과정( )이 별도의 테이블에서 계산되므로 중간 값이 노출되지 않고 원래 암호화 동작( )만 수행하는 결과와 동일하다. 안전성( ) 과정이 추가되기 때문에 동일한 암호 키를 사용하더라도 AES를 이용한 암복호화 결과와 화이트박스로 구현된 AES를 이용한 암복호화 결과는 차이가 있다. 룩업테이블 순람표(順覽表