일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- CodeEngn
- network
- 네트워크보안
- 소프트웨어
- 리버싱
- reversing
- 알고리즘
- 비박스
- 시스템해킹
- hacking
- Webhaking
- 순서도
- bee-box
- 소프트웨어보안
- 웹해킹
- webhacking
- 웹
- System
- 해킹
- ftz
- 네트워크
- 드림핵
- Web
- 워게임
- 시스템
- TCP
- WarGame
- XSS
- dreamhack
- 모의해킹
- Today
- Total
목록Software/소프트웨어보안 (9)
Without a Break
프로그래머의 잘못된 가정 1. 잘못된 신뢰 가정 운영체제는 안전하고, 방화벽은 트래픽을 필터링 함 => 따라서, 네트워크에서 오는 입력은 안전할 것이다. 2. 컴파일된 프로그램(Binary program)은 읽을 수 없다. - 단지 읽기 어려운 것일 뿐, 읽을 수 있음 - 모호하지만, 감추지 않음(난독화의 경우라도) - 리버싱도구의 진화 (코드에 담겨진 비밀 내용이 나타남, 클라이언트/서버의 통신 악용 가능성 있음) 3. 웹페이지는 입력을 점검할 것이다. 가정: 따라서, 프로그램에 데이터가 도착할 때 적정한 포멧을 가질 것이다. - 점검하지 않음. - 직접 http 요청을 제작 (UI 통하지 않고 CGI로 바로) - 요청을 보내기 직전에 변경하므로, 모든 입력은 서버 측에서 재검증할 필요 있음 - 특별한..

스택 Overflow에 대한 대응 일반적인 방어 방법 방어 기술은 fix를 대체하기 어려움 - 계층적인 방어(Layered Defense) 기법 : 악성코드 실행, 취약한 코드의 악용 - 코드의 변경이 가능한지에 대한 고려 Overflow defense 공격에 대한 성공 확률 낮춤 - Tamper detection: 누가 건드렸는지 확인 - 운영체제와 하드웨어에서의 Memory protection: 실행할 수 없는 곳에서는 실행이 안되도록 함 - Diversification methods: 메모리의 위치를 랜덤하게 해라. (특히 return address, ebp) Canaries on the stack 각 스택 프레임이 갖고 있는 취약한 포인터 값들에 대한 보호 Idea - 프레임을 보호계층으로 감싸기..
쉘코드 ① 공격자 입장에서는 무한한 가능성 => 모든걸 다 알 수 있기 때문 ② Set-UID까지 추가되면 특정 시스템에 대해 신같은 존재 => 원하는 걸 다 할 수 있기 때문 Stack 변수들의 악용 지역 변수들은 스택에 연속하여 위치 => 만일 특정 변수의 크기를 넘어서는 값이 쓰여지면 다른 영역에 corruption(변질) 발생 가능 *다른 영역의 예시 ① 다른 지역 변수 ② 이전 함수의 EIP ③ 리턴 주소 ④ Arguments 값 ⑤ 다른 함수의 영역 지역변수의 corruption 지역변수를 오염시키는 상황의 난해함 변수의 위치가 알려지지 않음 효과가 응용코드의 동작에 의존적 => 좀 더 예측가능하고 보편적인 공격을 위해서는 스택 프레임의 고정된 정보를 corrupt시키는 것이 좋음 (Frame..

컴퓨터의 구조 및 소프트웨어 실행 원리 1. 언어별 실행환경의 차이 - Low-level programs은 메모리를 직접 다룸 - Advantage: 효과적이고, 정확한 제어가 가능 - Disadvantage: 데이터의 추상화원칙을 위배 가능 메모리의 임의 접근 포인터 및 포인터 연산 안전한 메모리 사용 실패 2. 안전한 메모리 사용 명확하게 지정된 메모리 영역만을 사용하도록 하기 위해 강력하게 지켜져야 하는 규칙 다른 프로그램의 메모리 영역 절대 접근 불가 현재 함수의 접근가능 메모리 영역 외의 영역의 접근 통제 3. 코드와 데이터 폰 노이만 모델 : Code와 data를 동일 시 함 폰 노이만 컴퓨터 구조 : 해당 모델을 하드웨어 형태로 개발, 컴퓨팅 환경의 혁명의 기폭제 문제점 데이터와 코드가 같은..

정적 분석 vs 동적 분석 정적 분석 동적 분석 소프트웨어의 소스코드가 있을 때 분석이 가능 - 코드의 내용 속에서 취약성을 찾아냄 - 구문 에러 및 논리적 에러를 찾지는 못함 소프트웨어를 실행하여 가능한 모든 경우를 실행하도록 하여 오류가 있는지 확인 - 소스코드를 갖고 있지 않은 경우가 많음 - 소프트웨어 개발자가 제시하지 않은 use case를 고려 할 때도 있음 - 블랙 박스 테스트 vs 화이트 박스 테스트 + 참고) 동적 분석은 개발의 BUILD에서도 이뤄지지만 OPS의 OPERATE에서도 이루어짐 블랙 박스 테스트 vs 화이트 박스 테스트 (동적 분석) 블랙 박스 테스트 (소스코드를 포함) 소프트웨어의 내부 구조를 전혀 알지 못함 소프트웨어를 다양한 각도로 실행하여 반응을 확인하는 형태로 소프..
취약점의 발견과 보고 Zero Day Initiative https://www.zerodayinitiative.com/ Home | Zero Day Initiative www.zerodayinitiative.com TippingPoint에 의해 시작된 취약점 발견/공유 사이트 대기업 SW의 취약점을 발견, 공유함 취약점 발견자에게 금전적으로 보상 : 취약점을 발견 보고하여 경제적 이익을 얻을 수 잇음 CVE (Common Vulnerabilities and Exposures) CERT에 의해 1999년에 시작 취약점의 표준화된 식별을 목표 (Vendor 중심 자체 식별자 지정, 상호 의사소통의 어려움 해결) 각 Vendor 및 공급자들이 자신의 advisory 발표 가능 (단, CVE를 통해 상호참조하고..

Argc/Argv : 함수의 명령 인수. argc : 메인 함수에 전달되는 정보의 개수 argv []: 메인 함수에 전달되는 실질적 정보 (문자열의 배열) #include int main(int argc, char * argv[]){ int count; printf("This program was called with \"%s\".\n",argv[0]); if(argc > 1){ //외부에서 사용자 입력이 있는지 확인(1보다 크면 참) for(count = 1; count 12 return 0; } /* sscamf example 2*/ #include int main() { char sentence [] = "John park is 1238179278479183749173 years old"; char..

DevOps : 응용 프로그램을 빠르게/높은 품질로 제공하기 위한 체계 및 기술을 통칭 full lifecycle investment team undertaking better sw development & delivery pracitces acclerates the last mile of continuous delivery 필요성 사용자의 요구가 빠르게 반영되기를 원함 높은 품질의 소프트웨어에 대한 요구가 높아짐 개발 프로세스 with Security DevSecOps의 추가 요구사항 Threat Model Secure Coding : Rule Book Security as Code : Stack guard SAST(Static Analysis Security Test) : Code (정적 분석) DA..