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: