DEP는 스택에 있는 코드가 실행될 수 없게 만드는 기술 ASLR은 스택, 힙, 모듈 베이스 주소를 랜덤화 : 주소 또는 메모리의 위치를 예측 불가하게 만든다. ROP 체인 구성 기준 1. 전체 함수를 사용하는 대신에 명령어의 연속된 작은 덩어리를 이용한다.2. 명령어 조각은 2개~5개 정도가 적당하다.3. 모든 명령어 조각은 ret로 끝나야 한다. (핵심)4. 명령어 조각들은 'gadget'으로 서로 연결 되면서 명령어 덩어리가 된다.5. gadget은 의도 된 특정 행동을 수행한다.6. 공격자는 gadget를 조합해서 새로운 공격을 수행한다. DEP를 우회하지 않고는 스택에서 점프 혹은 명령어 실행을 절대 할 수 없다. DEP로 보호되고 있는 페이지에서 코드를 실행하려는 시도가 포착되면 접근 위반(S..

보호되어 있는 글입니다.

GS와 SafeSEH에 대해 배운 것을 정리해보았다. 1. 스택 쿠키 / GS 우회 방법스택 기반 오버플로우 보호 매너니즘을 우회할 수 있는 가장 쉬운 방법은 쿠키 값을 추측하거나 계산하는 것이라고 한다.쿠키가 정적인 값일 경우는 그대로 복사하여 쿠키 위치를 탐색한 뒤, 그 값을 페이로드에 삽입하면 된다.하지만, 대부분의 쿠키는 동적이다. (직관적으로 사용하기 어렵게 해둔다.) 그렇지만, 스택 쿠키가 있다고 겁먹을 필요 없다. 스택 쿠키의 원리를 조금 적다보면 그 이유를 알 수 있다.스택쿠키에 의해 bof를 감지하게 되면, 그 즉시 예외 핸들러의 존재 여부를 찾게 된다. 처음으로 찾는 예외 핸들러는 "개발자가 직접 코드로 작성한" 것이지만, 개발자가 직접 코드를 작성한게 없다면 운영체제가 설정해둔 핸들러..

보호되어 있는 글입니다.

이전 포스팅에서는 유동적으로 입력한 데이터가 기존의 버퍼의 크기를 초과 했을 때 스택이 오염 된다는 것에 언급하였다. 이번에는 조금 다른 얘기를 해볼까 한다. 정상적인 코드에 쓸데없이 라인이 추가되어 LOC(Line Of Code)가 증가하게 되면 퍼포먼스가 감소되는 것 같다. 그 이유는 여기에서 추측해볼 수 있었다. 순전히 나의 생각을 서술한 것 이기 때문에 틀릴 수도 있다. 컴파일러는 퍼포먼스 감소 영향을 최소화하기 위해 _alloca를 사용해 스택에 메모리를 할당하거나, 함수가 스트링 버퍼를 가지고 있을 때만 스택 쿠키를 추가하는 로직을 사용하게 되었고, 추가적으로 보호 매커니즘은 버퍼가 5바이트 이상의 데이터를 가질 때만 활성화 된다. 다음은 상기에 서술한 문장 PoC다. 아래는 버퍼가 5바이트 ..

공부 한 내용을 복습하는 공간으로 삼으려고 한다. 몇 년 전만 해도 익스플로잇 하는 것은 참 쉬웠다고 한다. 그 이유는 몇 가지가 존재하는데 그것부터 언급하고 시작하려 한다. 공격에 쓸 만한 리턴주소와 pop/pop/ret 주소를 쉽게 발견할 수 있었고, 애플리케이션이 쉘 코드로 점프할 수 있도록 만드는 것이 가능했기 때문이다. 또한 우리는 해당 가젯들의 주소를 운영체제나 애플리케이션에서 사용하는 dll에서 아주 쉽게 찾을 수도 있었다고 한다. 뿐 만 아니라 이 주소들은 시스템이 재 부팅 되더라도 변하지 않기 때문에 공격 코드 제작을 더욱 용이하게 할 수 있었다. 계속해서 애플리케이션에 공격이 진행되니까 마이크로소프트 사는 보호 할 수 있는 정책을 만들 수 밖에 없었다. 보호 매커니즘이라고도 표현할 수 ..