Exploit without Coffee

robot-attack RSA 취약점 - Robot Attack 진단 Robot-Detect Github: robot-detect Ubuntu Robot-Detect 설치 sudo apt-get update sudo apt-get upgrade sudo apt-get python3-gmpy2 pip3 install --upgrade pip pip3 install robot-detect 진단 도구 실행 robot-detect [ host ] Windows 파이썬3 설치(환경 변수 등록): python Download page visual c++ 14.0 build tool 설치 gmpy2 설치: gmpy2-2.1.0a1-cp36-cp36m-win32.whl ※ 운영체제 환경에 적합한 버전 내려받은 후 설치 python -m pip install gmpy2-2.1.0a1-cp36-cp36m-win32.whl What’s the difference between “pip install” and “python -m pip install”? 두 명령 모두 pip / init.py에서 같은 main 함수를 호출하여 동일하게 동작한다. robot-detect 설치: pip install robot-detect robot-detect 파일 확장자 .py 로 수정 ([Python 설치 경로]\Scripts\robot-detect) Ex) C:\Users\IEUser\AppData\Local\Programs\Python\Python36-32\Scripts 진단 도구 실행 python robot-detect [ host ] TLS-Attacker Github: TLS-Attacker Ubuntu JAVA 설치 및 JAVA_HOME 환경변수 등록 sudo apt-get install default-jre sudo apt-get install d

CVE-2018-5711 PHP CVE-2018-5711 잘못된 형 변환으로 발생된 PHP 취약점에 대해 알아보자. 영향 버전 PHP 5 < 5.6.33 PHP 7.0 < 7.0.27 PHP 7.1 < 7.1.13 PHP 7.2 < 7.2.1 취약 소스 파일 php-src 소스 저장소 - LWZReadByte_함수 내 취약점 발생 위치 do { sd -> firstcode = sd -> oldcode = GetCode ( fd , & sd -> scd , sd -> code_size , FALSE , ZeroDataBlockP ) ; } while ( sd -> firstcode == sd -> clear_code ) ; return sd -> firstcode ; GetCode 함수는 래퍼 함수로 실제 작업은 GetCode_ 함수에서 수행한다. static int GetCode_ ( gdIOCtx * fd , CODE_STATIC_DATA * scd , int code_size , int flag , int * ZeroDataBlockP ) { int i , j , ret ; unsigned char count ; . . . if ( ( count = GetDataBlock ( fd , & scd -> buf [ 2 ] , ZeroDataBlockP ) ) <= 0 ) scd -> done = TRUE ; . . . } GIF에서 데이터를 읽기 위해서 GetCode_ 함수에서 GetDataBlock 함수를 호출한다. static int GetDataBlock_ ( gdIOCtx * fd , unsigned char * buf , int * Zer

FreeBSD ipfilter use-after-free 취약점 해당 글은 xorl %eax %eax의 취약점 분석 포스팅 을 참고하여 작성하였습니다. FreeBSD의 ipfilter에서 Use-After-Free 취약점(CVE-2017-1081)이 발생하였다. sys/contrib/ipfilter/netinet/ip_frag.c static ipfr_t * ipfr_frag_new(softc, softf, fin, pass, table #ifdef USE_MUTEXES , lock #endif ) ... ipfr_t *fra, frag, *fran; ... /* * 가능한 경우 메모리를 할당하고, 실패 시 기록 후 NULL 반환 */ KMALLOC(fran, ipfr_t *); if (fran == NULL) { FBUMPD(ifs_nomem); return NULL; } ... /* * 이미 존재하지 않는 지 확인 */ for (fra = table[idx]; (fra != NULL); fra = fra->ipfr_hnext) if (!bcmp(( char *)&frag.ipfr_ifp, ( char *)&fra->ipfr_ifp, IPFR_CMPSZ)) { RWLOCK_EXIT(lock); FBUMPD(ifs_exists); KFREE(fra); return NULL; } fra = fran; fran = NULL; fr = fin->fin_fr; fra->ipfr_rule = fr; if (fr != NULL) { MUTEX_ENTER(&fr->

Sulley - 2 Savant는 윈도우용 오픈소스 웹 서버로 버전 별로 여러 알려진 취약점이 존재한다. Savant 3.0에는 Buffer Overflow 취약점이 존재하는 데, 이를 Sulley 퍼저를 이용하여 퍼징 테스트를 하겠다. 먼저 Savant 3.0 을 설치한다. http 프로토콜은 Sulley 퍼저에 기본적으로 내장되어 있으므로 이를 불러와 사용해도 괜찮다. 우리는 이미 알려진 취약점 에 대해서 퍼징 테스트를 수행하므로 편의상 취약 요소를 겨냥한 테스트를 진행한다. requests/http.py from sulley import * s_initialize( "HTTP" ) s_group( "verbs" , values=[ "GET" , "READ" , "POST" , "TRACE" ]) if s_block_start( "body" , group= "verbs" ): s_delim( " " ) s_delim( "/" ) s_string( "index.html" ) s_delim( " " ) s_string( "HTTP" ) s_delim( "/" ) s_string( "1" ) s_delim( "." ) s_string( "1" ) s_static( "\r\n\r\n" ) s_block_end( "body" ) httpfuzz.py from sulley import * from requests import http def init_message (sock) : init = 'GET /index.html HTML/

Sulley Sulley 는 파이썬으로 개발된 퍼저로 많은 사용자를 보유한 인기있는 도구이다. Gray Hat Python이나 인터넷의 여러 블로그에서 쉽게 사용법을 찾아볼 수 있어 퍼징 입문을 위해 많이 활용되고 있으며 파이썬으로 개발된 덕분에 커스터마이징을 위한 기본 뼈대로도 사용되고 있다. Wiki 페이지 를 통해서 설치방법을 제공해주고 있으나, 진행 도중 설치 에러로 막히는 경우가 많다. 이는 컴파일 관련 문제로 Microsoft Visual C++ Compiler for Python 2.7 설치 후 “Visual c++ command prompt”를 이용하여 진행하면 대부분 해결 가능하다. 튜토리얼로 사용되는 warftpd 1.65 퍼징 테스트를 진행해보자. ftp.py 퍼징 테스트를 위해서 FTP 통신 표준 데이터 정의가 필요하다. request 폴더 밑에 ftp.py 파일을 생성하고 아래 코드를 입력하자. from sulley import * s_initialize( "user" ) s_static( "USER" ) s_delim( " " ) s_string( "justin" ) s_static( "\r\n" ) s_initialize( "pass" ) s_static( "PASS" ) s_delim( " " ) s_string( "justin" ) s_static( "\r\n" ) s_initialize( "cwd" ) s_static( "CWD" ) s_delim( " " ) s_string( "c:" ) s_static( "\r\n" ) s_initialize( "dele" ) s_static( "DELE"

Hooking - 1 후킹이란 운영 체제나 응용 소프트웨어 등의 각종 컴퓨터 프로그램에서 소프트에어 구성 요소 간에 발생하는 함수 호출, 메시지, 이벤트 등을 중간에서 바꾸거나 가로채는 명령, 방법, 기술이나 행위를 말한다. 출처: 위키피디아 키보드 후킹 소스코드를 살펴보며 후킹에 대해 이해해보자. void Stealth() { HWND Stealth; AllocConsole(); Stealth = FindWindowA( "ConsoleWindowClass" , NULL); ShowWindow(Stealth, 0 ); } 후킹 소스에서 공통적으로 볼 수 있는 형태의 로직으로 이는 콘솔 프로그램 실행 시 콘솔 창을 드러내지 않고 동작시키는 내용이다. 사용된 함수 하나 씩 살펴보자. BOOL WINAPI AllocConsole(void): 호출 프로세스에 새로운 콘솔을 할당하는 함수로 실패 시 Zero를 반환한다. MSDN HWND WINAPI FindWindowA( In_opt LPCTSTR lpClassName, In_opt LPCTSTR lpWindowName ); ClassName과 윈도우 명이 일치하는 경우 윈도우 핸들을 가져온다. 실패 시 NULL을 반환한다. MSDN BOOL WINAPI ShowWindow( In HWND hWnd, In int nCmdShow ); 윈도우 보여주기 상태를 설정한다. SW_HIDE: 0 으로 설정 시 창을 숨기고 다른 창을 활성화한다. 이제 이번 예제의 핵심 함수 GetAsyncKeyState() 와 GetKeyState() 를 살펴보자. SHORT WINAPI GetAsyncKeyState( In int vKey ); 가상 키코드 를 인자로 하여 함수가 호출되는 시점에 키를 누르고 있는지 아닌지와 이전에 누른적이

CVE-2017-12623 Apache NIFI 에서 XXE 취약점이 발생하여 조치되었다. 취약 코드와 조치 후 코드를 비교해보자. 취약 코드 final Unmarshaller unmarshaller = JAXB_CONTEXT.createUnmarshaller(); unmarshaller.setSchema(schema); - final JAXBElement<Authorizers> element = unmarshaller.unmarshal( new StreamSource(authorizersConfigurationFile), Authorizers.class); external entity 제한 없이 XML 파일을 불러와 사용하여 external entity에 삽입된 악의적인 명령을 수행하는 취약점이 발생하였다. 테스트 파일 + <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE object [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]> + < object > + < name > &xxe; </ name > + < description > Arbitrary XML that has an XXE attack present. </ description > + < groupId > 3a204982-015e-1000-eaa2-19d352ec8394 </ groupId > + < timestamp > 09/05/2017 14:51:01 PDT </ timestamp > + </ object > 취약

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++는 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