Study/Software Security11 [소프트웨어보안] 프로그래밍 관점에서의 소프트웨어 보안 프로그래머의 잘못된 가정 프로그래머가 갖는 잘못된 신뢰 가정 1. 운영체제는 안전하고, 방화벽은 트랙픽을 필터링한다. 2. 네트워크에서 오는 입력은 안전할 것이다. 3. 컴파일된 프로그램은 읽을 수 없다. - 단지 읽기 어려운 것일 뿐 - 모호하지만, 감추지 않음(난독화의 경우라도) - 리버싱도구의 진화 • 코드에 담겨진 비밀 내용이 나타남 • 클라이언트/서버의 통신이 악용될 수 있음 4. 나의 웹페이지는 입력을 점검할 것이 다. 따라서 프로그램에 데이터가 도착할 때 적정한 포멧을 가질 것이다. - 직접 http 요청을 제작 - 요청을 보내기 직전에 변경 - 모든 입력은 서버 측에서 재검증해야함 - 특별한 인코딩이 포함되어 있을 수 있음 Memory corruption attacks memory corr.. 2022. 12. 6. [소프트웨어보안] 스택 Overflow에 대한 대응, 안전한 프로그램 개발 스택 Overflow에 대한 대응 일반적 방어 방법 방어 기술은 fix를 대체하기 어려움 – 계층적인 방어(Layered Defense) 기법 • 악성코드 실행, 취약한 코드의 악용 – 코드의 변경이 가능한지에 대한 고려 Overflow defense Overflow에 대한 대응 방법은 지속적으로 개발되어 옴 공격에 대한 성공 확률 낮춤 – Tamper detection – 운영체제와 하드웨어에서의 Memory protection – Diversification methods Canaries on the stack • 각 스택 프레임이 갖고 있는 취약한 포인터 값들에 대한 보호 • Idea: – 프레임을 보호계층으로 감싸기 “canary” – Canary는 return address 아래 위치 – 공격자.. 2022. 11. 30. [소프트웨어보안] Buffer Overflow Attack Set-UID Programs Privileged Programs - 높은 권한 기반 프로그램 1. Set-UID Programs - euid를 기반으로 접근통제를 진행하도록 만든 프로그램 2. Server Programs - 낮은 번호의 소켓을 생성 - 24x7 실행되어야 함 3. Device Drivers - 물리적 장치에 접근하기 위한 소프트웨어 - 장치 접근을 위한 권한 필요 4. System Daemons - 백그라운드에서 실행되면서 시스템의 운영을 지원 - 부모 프로세스가 없는 프로세스 Needs for Privileged Programs - 권한 필요 사례 Password Dilemma 사용자가 password를 변경하도록 허용하는 방법 - 높은 권한을 가져야 수정할 수 있는 파일 - 낮은 .. 2022. 11. 23. [소프트웨어보안] Set-UID 권한 프로그램과 공격 기법 권한 있는 프로그램의 필요성 Linux 환경 - /etc/shadow에 password를 저장 - 사용자가 자신의 비밀번호를 수정하고자 할 때 해당 파일 사용 - Only Writable to the owner, Owner만 사용 가능! - 파일의 정보를 보려면 root로 접근하거나 sudo를 사용 일반 사용자가 패스워드 파일을 볼 수 있게 하는 방법 - 패스워드의 변경을 위해서 shadow 파일에 대한 변경 필요 - 일반 사용자는 shadow 파일을 변경하지 못한다. (root만 변경 가능) - 운영체제가 세밀한 접근통제를 수행하도록 하는 방법 1) 현재는 파일 단위로 접근 통제를 수행 2) 파일 내의 특정 영역까지 접근 통제 규칙을 적용 (현재 불가능) Set-UID 메커니즘 shadow 파일의 구성.. 2022. 11. 16. [소프트웨어보안] Stack buffer overflow 이론 Stack buffer overflow 이론 Stack 변수들의 악용 - 지역 변수들은 스택에 연속하여 위치 - 만약 특정 변수의 크기를 넘어서는 값이 쓰여지면 다른 영역에 corruption 발생 가능 다른 영역 ex) 다른 지역 변수, 이전 함수의 FP, 리턴 주소, Arguments 값, 다른 함수의 영역 지역 변수의 corruption - 지역 변수를 오염(corruption)시키는 상황은 변수의 위치가 알려지지 않고 효과가 응용코드의 동작에 의존적이라서 난해하다. 즉, 공격자가 원하는 목표를 달성하는 것이 쉽지 않다. - 좀 더 예측 가능하고 보편적인 공격을 위해서는 스택 프레임의 고정된 정보를 corrupt시키는 것이 좋다. - 해당 코드에서 authenticate()의 sprintf() 함수.. 2022. 11. 6. [소프트웨어보안] 컴퓨터의 구조 및 소프트웨어 실행 원리, C언어와 어셈블리어의 이해 컴퓨터의 구조 및 소프트웨어 실행 원리 1. 언어 별 실행 환경의 차이 ▶ Low-level programs은 메모리를 직접 다룬다. ▶ Low-level program의 장점: 효과적 / 정확한 제어 가능 ▶ Low-level program의 단점: 데이터의 추상화원칙 위배 가능! - 메모리의 임의 접근 - 포인터 및 포인터 연산 - 안전한 메모리 사용 실패 2. 안전한 메모리 사용 방법 ▶ 명확하게 지정된 메모리 영역만을 사용하도록 하기 위해 강력하게 지켜져야 하는 규칙 - 다른 프로그램의 메모리 영역 절대 접근 불가 - 현재 함수의 접근가능 메모리 영역 외의 영역의 접근 통제 3. 컴퓨터의 구조 - 코드와 데이터 ▶ 폰 노이만 모델 - 코드와 데이터를 동일 시 한다. ▶ 폰 노이만 컴퓨터 구조 - .. 2022. 10. 19. [소프트웨어보안] 소프트웨어의 정적 분석 방법 소프트웨어의 정적 분석 방법 이론 1. 정적 분석 vs 동적 분석 1) 정적 분석 - 소프트웨어의 소스코드가 있을 때 분석이 가능. 코드의 내용 속에서 취약성을 찾아낸다. - 중요한 점: 구문 에러 및 논리적 에러를 찾지는 못한다. 2) 동적 분석 - 소프트웨어를 실행하여 가능한 모든 경우를 실행하도록 하여 오류가 있는 지를 확인한다. - 소스코드를 갖고 있지 않은 경우가 많다. - 소프트웨어 개발자가 제시하지 않은 use case를 고려 할 때 도 있다. 2. 블랙 박스 테스트 vs 화이트 박스 테스트 1) 블랙 박스 Test - 소프트웨어의 내부 구조를 전혀 알지 못한다. (소스코드를 포함) - 소프트웨어를 다양한 각도로 실행하여 반응을 확인 하는 형태로 소프트웨어를 테스트한다. - Test 시나리오.. 2022. 10. 12. [소프트웨어보안] Security advisories, CVE Security advisories(어드버져리) 1. Security advisories(어드버져리)란? - Security advisories는 소프트웨어 개발사(Vendor)에 의해 발표 - Public 공개 원칙, 초기단계에 공개대상 제한 - 사전 안내의 경우 : 큰 고객, 보안기업을 대상 - 패치가 없는 상황이 있을 수 있다. - 대중공개를 할 경우 패치 혹은 update가 존재 - 소프트웨어 제공 회사와 공급 개발자 중심으로 구성함 - Advisories의 사용자는 SW의 User, 시스템관리자, 추가 개발자들 이 이용 - 각 개발사마다 자체 포맷이 있으나 공통적으로 지켜야 하는 최소한의 요구사항들이 있다. 1) 이름/날짜/구별을 위한 식별자 2) 위험도 (Criticality) 3) 영향을 받.. 2022. 10. 12. [소프트웨어보안] 소프트웨어의 개발 절차 및 보안관리, 취약점에 대한 Public Advisory 소프트웨어의 개발 절차 및 보안관리 - DevOps and DevSecOps 취약점 - 공격의 시간적 관계 DevOps - 응용 프로그램을 빠르게/높은 품질로 제공하기 위한 체 계 및 기술을 통칭 DevOps의 필요성 - 사용자의 요구가 빠르게 반영되기를 원한다. - 높은 품질의 소프트웨어에 대한 요구는 더 높아진다. DevOps의 추가 요구사항 - Threat Model - Secure Coding - Security as Code - SAST - DAST - Penetration Test - Digital Sign - Secure Transfer - Secure Config - Security Scan - Security Patch - Security Audit - Security Monitoring.. 2022. 10. 5. [소프트웨어보안] Argc/Argv Programming, sscanf Argc/Argv Programming #include int main (int argc, char *argv[]){ int count; printf ("This program was called with \"%s\".\n",argv[0]); if (argc > 1) { for (count = 1; count < argc; count++){ printf("argv[%d] = %s\n", count, argv[count]); } } else { printf("The command had no other arguments.\n"); } return 0; } sscanf의 활용 /* sscanf example */ #include int main () { char sentence []=“John is 12 y.. 2022. 10. 5. [소프트웨어보안] SW 보안의 5 요소 1. 소프트웨어보안 실무와 이론의 차이점 실무 - 안전하게 프로그래밍, 보안 이슈 진단 - 언어 사용의 실수, API 내 문제, 암호기술 및 통신 방법의 문제 - 매우 실무적이고 자세히 기술해야 하는 문제 이론 - 프로그램 실행 중단의 이유와 이의 해결 방법의 이해 - 자동화 도구를 포함한 최신 기술의 이해 - 개념과 방법론 2. 소프트웨어 보안의 일반적인 요소들 1) 위협 (Threats) - 공격자가 원하고 할 수 있는 것 - 악성코드의 종류: malware, spyware, worm - 어떻게 악성코드의 감염이 발생하나? (-> 접촉이 있어야 감염 발생!) - 취약점과 약점(weaknesses)의 분류 필요 (CVE and CWEs) 2) 취약점 (Vulnerabilities) - Overflows.. 2022. 9. 28. 이전 1 다음
