• 실습 장비 Grayhash DanbiBoard-BASIC 소개 및 Spec 설명 • Firmware, Bootloader, OS, Filesystem의 이해 • CPU 관점에서 본 부팅 과정의 이해 • 실습 : 펌웨어 개발 환경 구축 • 펌웨어 코드 작성 이론 설명 • 실습 : 기본 펌웨어 개발 및 퓨징 • 펌웨어 코드 분석 및 GPIO의 이해 • UART를 이용한 DEBUG 메시지 출력 • 해커의 관점에서 본 UART 프로토콜 • 실습 : LED 등 주변장치 제어 • 하드웨어 통신 프로토콜 I2C의 이해 • 마무리 실습 : Character LCD 제어
2일차 - 리눅스 시스템 개발
• 실습 장비 Grayhash DanbiBoard-EDU 소개 및 Spec 설명 • 부트로더(Bootloader)의 이해 • 메모리, 메모리 컨트롤러 및 메모리 맵의 이해 • 해커의 관점에서 본 메모리 맵 • DDR2 RAM 초기화 방법에 대한 이해 • 실습 : RAM 초기화 및 RAM 테스트 • U-BOOT의 구조 및 커널 로딩 과정의 이해 • 실습 : U-BOOT 포팅 및 퓨징 • 부트로더를 이용한 펌웨어 업그레이드 • 해커의 관점에서 본 부트로더 (부트로더 보안체계 우회 사례들) • 실습 : Linux Kernel 컴파일 및 퓨징 • Root File System의 이해 • 실습 : Root File System 빌드 및 퓨징 • 해커의 관점에서 본 Root File System • 리눅스 부팅 과정 및 파티션 구조의 이해 • 마무리 실습 : 리눅스 시스템 부팅
3일차 - 개발보드의 활용
• 실습 장비 Grayhash DanbiBoard-PRO 소개 및 Spec 설명 • 디바이스 드라이버의 이해 • 실습 : 디바이스 드라이버를 통한 주변장치 제어 • 하드웨어 통신 프로토콜 SPI의 이해 • 해커의 관점에서 본 SPI 프로토콜 • TFT-LCD 디스플레이 연결 • Frame Buffer의 이해 • 실습 : Frame Buffer 장치를 이용한 TFT-LCD 제어 • 실습 : mp3 음원 및 동영상 재생 • USB 시스템 작동 구조의 이해 • 실습 : USB 키보드 및 랜카드 연결 • Ethernet 시스템 작동 구조의 이해 • 실습 : 네트워크 연결 • 마무리 실습 : 게임 에뮬레이터 실행하기
[AVR 프로그래밍] • MCU(Micro Controller Unit)의 이해 • Atmega128A MCU 소개 • 개발 도구(Atmel studio 6.2) 설치 • ISP(In-System Programming)의 이해 • 범용/특수 입출력 포트의 이해 • LED, 모터, 스피커 제어 실습 • 7-Segment 및 Dot Matrix 제어 실습 • 온도 센서 제어를 통한 ADC의 이해 • 디지털 온도계 제작 실습 • UART 통신 실습 • 트랜지스터를 이용한 증폭 작용 실습 • 스위치를 이용한 입력 핀 사용 실습 • 인터럽트와 타이머의 이해 • PWM(Pulse Width Modulation)의 이해 • IrDA(적외선)을 이용한 무선 통신 실습 • AVR Firmware 추출하기 • AVR과 Arduino의 관계 이해 • Arduino 프로그래밍 실습
2일차 - UART&JTAG Hacking
[UART Hacking] • 하드웨어 레벨 프로토콜의 이해 : UART, I2C(2-wire, TWI), SPI • UART Programming의 이해 • Logic Analyzer를 이용한 UART 프로토콜 분석 실습 • UART Pin 찾기 실습 • 유무선 공유기 UART 연결 실습 • Baudrate 분석 실습 • 스마트폰(갤럭시S) UART 연결 실습 • UART 쉘을 이용한 바이너리 추출 실습 • 각종 기기들에 대한 UART 연결 시연 (스마트 TV, 홈 네트워크 시스템, CCTV, NAS 장비) • UART 해킹 case by case
[JTAG Hacking] • JTAG의 개념 및 작동 원리 이해하기 (TDI, TDO, TCK, TMS, TRST) • TAPC(Test Access Port Controller) 상태도 이해하기 • JTAG 실전 활용 예제 • 상용 JTAG 툴 소개 : Riffbox Jtag, H-JTAG, AD-JTAG • JTAG Pin Scanning : Jtagulator, JTAGenum • JTAG을 이용한 펌웨어 획득 실습 • JTAG을 이용한 동적 디버깅 실습
3일차 - Flash Memory 덤프 실습
• Flash Memory 기초 • Winbond W25Q16BV Flash Memory의 이해 • 마이크로 프로세서 GPIO Handling 실습 • SPI 프로토콜의 이해 • Flash Memory Dumper 개발 실습 • Desoldering 실습 • Winbond W25Q16BV Serial Flash Memory Dump 실습 • 8-pin Test-clip 활용 실습 • Dump된 Firmware Image 분석 및 바이너리 파일 추출 실습
[Hardware] • AVR 개발 키트(jmod-128-1) • UART, JTAG 장비 • 점퍼 케이블, 빵판 및 각종 센서들
• CAN(Controller Area Network) 통신의 이해 • ECU(Electronic control unit)의 이해 • CANbus lines 연결하기 실습 • CANbus Hacking Tool 개발 실습 • CAN Message Sniffing 실습 • CAN Message 송신(Injection) 실습 • CAN Message 포맷의 구조 이해 • CANbus Controller와 Transceiver의 이해 • Car Network 종류들의 이해 • 차량진단 표준의 이해와 해킹 관점에서의 활용 • 실제 차량의 OBD-II 포트와 연결하기 실습
• 주요 자동차 해킹 사례 및 취약점 발생 원리 분석 • 2010 - Experimental Security Analysis of a Modern Automobile • 2011 - Comprehensive Experimental Analyses of Automotive Attack Surfaces • 2013 - Adventures in Automotive Networks and Control Units • 2014 - A Survey of Remote Automotive Attack Surfaces • 2015 - Remote Exploitation of an Unaltered Passenger Vehicle • 2015 - How to Hack a Tesla Model S • 2015 - Broadcasting Your Attack: Security Testing DAB Radio In Cars • 2015 - Drive it like you Hacked it: New Attacks and Tools to Wireles • 2016 - Advanced CAN injection technique for vehicle networks • 2016 - Car Hacking Research: Remote Attack Tesla Motors • 2017 - The CIA may be hacking cars
• 자동차 Attack Vector의 이해 • Hardware Vulnerabilities Analysis (UART/JTAG/OBD-II) • Audio/Video/Navigation Device Vulnerabilities Analysis • Smart Device Vulnerabilities Analysis • Telematics Device Vulnerabilities Analysis • ETC : Web Browser, Smartphone APP, Radio Data System, Cloud Server
2일차 - Infotainment System Hacking
• Bluetooth based Car Hacking • Bluetooth 기초 (master/slave, piconet, bluetooth stack) • Bluetooth module 사용 실습 • Bluetooth Packet 송수신 실습 • Bluetooth Packet sniffing 실습 • Bluetooth Profile의 이해 • Bluetooth Profile Scanning 실습 • 차량용 디바이스의 주요 Profiles • 차량의 주요 Bluetooth 관련 기능들 • 차량의 Bluetooth Packet Sniffing 및 분석 • 차량 Bluetooth의 주요 Attack Vectors • Bluetooth Packet 변조 실습
• USB based Car Hacking • 차량 USB의 주요 Attack Vectors • USB(Universal Serial Bus) 기초 • Beagle USB 480을 이용한 USB Packet Sniffing • 주요 USB Packets 분석(Device, Configuration, Interface, Endpoint, String Descriptor) • USB Packet Fuzzing 환경 구축 • OrangePi를 이용한 USB fuzzer 개발 • Linux USB Gadget의 이해 • USB Stack Fuzzing • USB based OS File system Fuzzing • USB based Multi-media file Fuzzing
3일차 - Telematics System Hacking
• TCU(Telematics Control Unit)의 이해 • SMS PDU 포맷의 이해 • PDU 포맷 분석 실습 • PDU 데이터를 이용한 SMS 전송 실습 • Modem device를 이용한 SMS 전송 실습 • 보내는 SMS와 받은 SMS의 PDU 필드 값 비교 • MMS(Multimedia Messaging Service) 전송하기 • PDU-Header 및 TP-UDHI 필드의 이해 • IEI(Identity Element Identifie)와 Application Port의 이해 • SMS Hacking 사례 분석 • SMS Fuzzing 환경 구축 • Android telephony stack의 이해 • SMS 수신 시의 데이터 흐름 경로 분석 및 Fuzzing 지점 선정 • SMS Fuzzer 개발 방법의 이해 • Fake BTS를 이용한 SMS attack (USRP + OpenBTS)
●DNS Cache Poisoning DNS Cache Poisoning 공격은 DNS 통신상의 인증 취약으로 인하여 발생한다. 공격자가 DNS 응답 패킷을 위조하여 취약 DNS 서버에 전송할 경우, DNS 서버가 해당 응답을 Authoritative DNS 서버로부터 발송된 정상적인 응답으로 받아들인다는데 문제점이 있다. 위조된 응답이 받아들여질 경우, 취약 DNS 서버의 Cache 테이블에 공격자에 의하여 위조된 정보가 저장되게 되며, 이후에는 DNS 서버는 일반 이용자들에게 Cache 테이블에 저장된 위조된 DNS 정보를 제공하게 된다. ● DNS 서버 인증 취약점 DNS 서버는 TXID(Transaction ID)와 Source Port 를 이용하여 DNS 패킷을 인증하는데, TXID 와 Source Port 추측이 가능하다는데 문제점이 있다. 특히, DNS Source Port 의 경우 질의 시 일정한 번호로 고정되게 되어 추측이 용이하다.
취약한 Recursive DNS 서버에서의 질의 패킷에 대한 Source Port 확인 예(일정한 번호로 고정)
TXID 또한 변화 범위가 넓지 않아, 공격자가 TXID 번호에 대한 무작위 대입 또는 순차 대입 공격 등을 통하여, 위조 응답 패킷이 인증이 되도록 할 수 있다.
DNS 패킷의 TXID 필드 Length 예
위와 같이 TXID 필드는 16Bit 이므로, 한 번의 무작위 대입 공격으로는 1/65536 확률을 가지게 된다. 그러나, 단시간 내에 무작위로 대입된 대량의 패킷을 발송하는 방식으로 공격 성공 확률을 크게 높일 수 있다.
TXID 번호에 대한 무작위 대입 또는 순차 대입 공격
● DNS Cache Poisoning 공격 분석 DNS 인증 취약점 공격이 성공하여 위조된 DNS 패킷이 취약한 DNS 서버에서 Accept 될 경우, 공격자가 의도한 특정 도메인에 대한 악성 IP 주소 값이 취약한 DNS의 Cache 테이블에 저장되게 되며, 이후에는 해당 취약 DNS 서버는 DNS 질의를 하는 모든 이용자들에게 변조된 IP 주소로 응답하게 된다. 정상적인 DNS 요청 및 서비스 과정과 공격자에 의한 공격 과정을 비교하여 살펴보면 다음과 같다. ▶ 정상적인 DNS 요청 과정
정상적인 DNS 요청 절차 예
인터넷 사용자가 DNS 도메인 서비스를 정상적으로 받을 경우의 과정은 위의 그림과 같다. 사용자 PC 가 Recursive DNS 서버에 특정 도메인네임에 대한 주소 요청을 하게 되면, Recursive DNS 서버는 해당 도메인을 가지고 있는 Authoritative DNS 서버로 찾아가서, 해당 도메인에 대한 주소를 응답받아, 최초 질의한 사용자 PC 에 해당 주소를 알려준다. ▶ DNS 응답 조작 통한 Cache Poisoning 공격 과정 예 정상적인 응답 과정과는 다르게, 공격자가 DNS 응답 패킷을 임의로 제작하여, DNS 서버에 발송하여 DNS Cache 테이블에 공격자가 원하는 정보가 입력되도록 한다. 이 공격을 성공하기 위하여는 우선 DNS 인증 취약점 공격이 성공하여야 한다.
DNS Cache Poisoning 공격 예
① 공격자는 AAA 도메인을 공격 대상 DNS 서버에 요청한다. ② Authoritative DNS 서버로부터 응답 패킷이 온 것처럼 소스 IP 를 Auth DNS IP 로 스푸핑하여 위조된 응답 패킷을 공격 대상 DNS 서버에 보낸다. 공격자는 위조된 패킷이 실제 정상적인 Auth DNS 응답보다 먼저수신 되도록 빠른 속도로 발송한다. ③ 공격 대상 DNS 서버는 위조된 응답 패킷을받아들여, 위조된 주소를 Cache에 저장한다. 위조된 응답 패킷을 받아들이기 위해서는 우선 DNS 인증 취약점 공격이 성공하여야 한다. ④ 공격 대상 DNS 서버를 사용하는 일반 사용자가 AAA 에 대한 DNS 질의를 할 경우 위조된 주소로 응답받게 된다. ● DNS Cache Poisoning 모의 공격 과정 ▶ DNS 인증 취약점 공격 ① 공격자는 공격자가 구성한 Authoritative DNS 서버를 활용, 공격자 도메인으로 쿼리 패킷을 발송 및 분석하는 방법 등을 통하여, 취약 DNS 가 질의 시 사용하는 Source 포트를 파악한다. ② 취약 DNS 서버에 Poisoning 을 원하는 도메인의 다수 하위 도메인으로 질의를 발생시킨 후, TXID 필드 값을 순차적으로 증가시켜가며 빠른 속도로 위조된 응답 패킷을 발송한다. 위조 패킷 발송 시 UDP Destination 포트는 취약 DNS 서버가 사용하는 것으로 확인된 Source 포트 번호로 설정한다. 일단 Authoritative DNS 서버로부터 정상적인 응답을 받을 경우, DNS Cache 에 정상적인 도메인 주소 정보가 저장되게 되어, 이후에는 질의가 발생하지 않게 되며, 위조된 응답 패킷을 수신하지 않아 공격이 불가능해진다. 따라서, 새로운 하위 도메인으로 주기적으로 질의를 한다.
공격을 위한 위조된 응답 패킷 예 (짧은 시간 내에 TXID를 순차적으로 변경해 가며 응답 패킷 발송)
③ 취약 DNS 는 공격자가 발송한 대량의 위조된 패킷 중 TXID 가 일치하는 패킷이수신되면 해당 응답을 정상적인 패킷으로 받아들인다. ▶ DNS Cache Poisoning을 통한 특정 도메인에 대한 IP 주소 위조 DNS 인증 취약점 공격이 성공하게 되면, 취약 DNS 서버는 위조된 DNS 응답 패킷을 받아들여 DNS Payload 에 있는 위조된 정보를 DNS Cache 테이블에 저장한다. www.pr[생략]ng.net 도메인을 대상으로 실제 공격하는 과정과 결과를 살펴보면 다음과 같다.
DNS Cache Poisoning 공격 과정
① 취약 DNS 서버에 pr[생략]ng.net 도메인에 대한 위조된 응답 패킷을 발송한다. (Cache Poisoning을 하고자 하는 도메인인 www.pr[생략]ng.net 와 Resolving IP 199.199.199.199 는 Additional RR 필드 부분에 삽입)
위조된 DNS 응답 패킷 내용 예
② 공격이 성공한 후, 취약 DNS 서버를 사용하는 사용자가 www.pr[생략]ng.net 도메인에 대한 질의를 할 경우, 위조된 199.199.199.199 로 응답받게 된다.
공격 성공 전 - 10.50.100.6 으로 응답
공격 성공 후 - 변조된 199.199.199.199 으로 응답
● 대응 방안 ▶ 사전 예방 방안 :캐시/리졸빙 DNS 서버로 사용되는 시스템을 운영 중이라면, 해당 보안 취약점 공격에 대비하기 위하여 각 벤더사의 DNS 를 최신 버전으로 업그레이드한다.
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "aaa.bbb.ccc.ddd is POOR: 26 queries in 4.0 seconds from 1 ports with std dev 0.00"
DNS가 취약점에 노출되지 않은 경우
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "aaa.bbb.ccc.ddd is GOOD: 26 queries in 2.0 seconds from 26 ports with std dev 17685.51"
▶ 신뢰할 수 있는 호스트에 대해서만 recursive query 서비스가 가능하도록 설정한다. recursive query를 제한하더라도, DNS 가 패치가 안되어 있을 경우는, 내부의 호스트를 이용한 공격에는 노출되게 되므로 주의해야 한다. - 신뢰된 호스트에서만 Recursion 서비스를 제공하는 방법 (BIND 8.2.1와 이후 버전)
● 공격 발생 시의 탐지 방안 DNS 인증 취약점을 공격하기 위해서는, 공격자는 Authoritative DNS IP 로 가장하여 위조된 DNS 응답 패킷을 발송하여야 한다. TXID 필드는 16bit 로써 임의의 값으로 저장된 하나의 응답 패킷을 발송할 경우, 1/65536의 성공 확률을 가지게 된다. 따라서, 공격자는 성공 확률을 높이기 위하여 TXID 를 순차적으로 증가 또는, 무작위로 대입된 응답 패킷들을 대량으로 발생시키는 방식으로 공격을 수행할 소지가 매우 높다. Authoritative DNS 서버로부터 정상적인 응답 패킷이 도착하기 전에, 공격을 성공시켜야 하므로, 한 번의 질의 시 공격을 위한 짧은 시간이 주어진다. 따라서, 공격자는 주기적으로 Poisoning 을 원하는 도메인에 대한 임의의 서브 도메인 이름으로 재질의를 하며 공격을 수행하게 된다. 또한, 위조된 DNS 응답 패킷의 Additional 필드(또는 추가 answer 필드)에는 Poisoning 을 원하는 도메인 정보와 주소가 삽입되게 된다. 공격이 발생하게 되면, 공격 대상 Recursive DNS 서버에서는 단일 IP 로부터 응답 패킷들이 대량으로 유입되는 현상이 관찰될 것으로 보인다. 또한, 해당 응답 패킷의 "Question" 및 "Answer" DNS 필드에는 최하위 서브 도메인명이 랜덤 형식인 비정상적인 형태의 도메인이 포함되어 있을 가능성이 높다. Recursive DNS 서버 운영자는 단일 IP 에서 매우 짧은 시간 내에 DNS 응답 패킷이 대량으로 유입되는 로그 및 현상이 관찰될 경우, 유입되는 DNS 응답 패킷들의 "Question" 및 "Answer" DNS 필드의 페이로드를 확인하여, 최하위 서브 도메인명이 랜덤 형식이거나 계속적으로 변경되는 비정상적인 형태의 실제로는 존재하지 않는 도메인이 포함되어 있는지를 확인해 보도록 한다. 짧은 시간 내에 이러한 유형의 패킷이 다수 확인될 경우 공격 발생을 의심해볼 필요가 있다.
공격 패킷의 "Question" 및 "Answer" 필드 내에 포함되어 있는 비정상적인 도메인 예
UIApp.keyWindow.subviews() // keyWindow의 subviews 확인. 아래 예시는 #으로 구분되는 2개의 subviews를 가지고 있음
#주소.subviews() // 특정 주소값을 가지는 view의 subviews 확인. 아래 예시는 #으로 구분되는 1개의 subview를 가지고 있음
UIApp.keyWindow.subvies()[index]._viewDelegate()// 해당 뷰를 담당하는 controller 출력. 아래 예시는 keyWindow의 첫번째 subview를 담당하는 controller가 UIApplicationRotationFollowingController 임을 나타냄.
// Usage:
// for InstanceMethods: printMethods('className')
// for ClassMethods: printMethods('className', true)
function printMethods(className, isa) {
var count = new new Type("I");
var classObj = (isa != undefined) ? objc_getClass(className)->isa :
objc_getClass(className);
var methods = class_copyMethodList(classObj, count);
var methodsArray = [];
for(var i = 0; i < *count; i++) {
var method = methods[i];
methodsArray.push({selector:method_getName(method),
implementation:method_getImplementation(method)});
}
free(methods);
return methodsArray;
}
UIApp.keyWindow.rootViewController._printHierachy() 명령어로 뷰 계층 확인 후 관심 클래스의 주소값에 대하여 다음 명령어 수행
#<주소값>._methodDescription().toString() // 이 방법의 경우 알고자 하는 클래스의 method 뿐만 아니라 다른 클래스의 메서드들도 출력해주다보니 쓸모없는 정보들이 너무 많이 출력됨
- Print Current ViewController
function currentVC() {
var app = [UIApplication sharedApplication]
var keyWindow = app.keyWindow
var rootController = keyWindow.rootViewController
var visibleController = rootController.visibleViewController
if (!visibleController){
return rootController
}
return visibleController.childViewControllers[0]
}
최근 클라우드 도입이 증가하면서 많은 시스템들이 가상화 기술을 사용하고 있다. 일반적으로 잘 알려진 가상화 기술 ‘하이퍼바이저(Hypervisor)’는 애플리케이션과 라이브러리를 격리시킬 수 있다. 하지만, 운영체제(OS) 뿐만 아니라 하드웨어 스택 부분도 가상화 시키기 때문에 메모리, CPU 등 자원을 많이 소모한다. 반면 ‘도커(Docker)’는 애플리케이션과 라이브러리를 패키지(컨테이너)로 묶어 리눅스 컨테이너(LinuX Containers: LXC)’로 리소스가 적게 드는 격리 환경을 만들 수 있다.
또한 도커는 애플리케이션을 쉽게 빌드(Build), 테스트(Test), 및 배포(Deploy) 할 수 있어 ‘데브옵스(Devops)’에 최적화되어 있는 오픈 소스 도구라 할 수 있다. 이에, 많은 기업들이 도커를 활용해 데브옵스 환경을 구축하고 있다.
도커를 타겟으로 한 악성코드
최근, 많은 서버들이 도커로 구성되면서 이를 타겟으로 한 공격도 증가하고 있다. 특히, 여러 공격 중에서도 ‘Docker REST API’를 이용한 공격이 급증하고 있다. 실제로 도커 관련 서버들의 침해 사례들을 보면 공격자들이 ‘Docker REST API’를 이용해 악성코드를 배포하고 있다. 그리고, 배포된 악성코드에는 취약한 Docker REST API 설정의 서버를 대상으로 측면 이동(Lateral Movement) 기능이 포함되어 기존 SSH 봇넷 악성코드처럼 공격이 확산되고 있다.
본 문서에서 언급하는 ‘취약한 Docker REST API 설정을 가진 서버’는 인증 및 접근 제한없이 원격 환경에서 ‘도커 이미지(Docker Image)’와 ‘도커 컨테이너(Docker Container)’를 관리하는 REST API를 사용할 수 있는 서버를 말한다.
취약한 Docker REST API 서버는 HTTP Request(Port:2375/2376)에 대한 HTTP Response({"message":"page not found"})를 통해 Docker REST API 서버를 탐지할 수 있다. 따라서, 격자는 [그림 2]와 같이 무작위 스캐닝을 수행해 취약한 Docker REST API 서버를 탐지한다.
공격자는 취약한 Docker REST API 서버를 알아낸 다음 Docker REST API를 통해 기존 도커 컨테이너에 악성코드를 실행시키거나 새로운 악성 도커 이미지를 다운로드 받아 실행시킨다.
특히, 공격자는 직접 포트 스캔을 하지 않고도 ‘쇼단(SHODAN)’과 같은 오신트(OSINT: 오픈소스 인텔리전스의 줄임말)를 이용해 Docker REST API 설정이 취약한 서버를 쉽게 찾을 수 있다. 이러한 방식으로 배포되는 악성코드는 대표적으로 6가지 종류가 있으며, 그 히스토리는 아래와 같다.
이번 글에서는 위 악성코드 6개 중 ‘Kinsing’, ‘Xanthe’, ‘KaijiDDoS’에 대해 소개한다.
