KyumLab

CPU 범용 레지스터 (EAX,EBX,ECX,EDX,EBP,ESI,EDI,ESP)

- CPU 범용 레지스터란 범용적으로 사용되는(?) 레지스터 입니다. 모든 레지스터들은 각각 4byte(32bit)의 크기를 가진다고 하네요!

8개의 레지스터에서 상위 4개의 레지스터는 산술연산의 변수 값의 저장용도로, 하위 4개는 메모리 주소를 저장하는 포인터로 자주 사용된다고 합니다.

하지만 상황에따라서 레지스터의 용도가 다르게(?) 쓰일 수도 있습니다.

(* 앞의 E는 32bit 에서, 64bit는 R을 씀, RAX, RBX 이런식으로...)

* 요약ㅎㅎ

1) EAX : 산술 및 논리연산을 수행한 후에 함수의 반환값이 저장되는 용도 (쉽게 말해 함수의 리턴 값)

2) EBX : 메모리 주소를 저장하기 위한 용도

3) ECX : 반복문(for,while)에서 반복 카운트(loop count)로 사용 (루프 돌때마다 ECX 1씩감소)

4) EDX : EAX와 같이 쓰이고, 부호 확장 명령에 사용

5) ESI : 데이터를 조작 or 복사할 때 데이터의 주소가 저장됨

6) EDI : 데이터를 복사할 때 목적지 주소가 저장

7) ESP/EBP : ESP는 Stack의 끝 주소, EBP는 Stack의 첫 시작 주소를 의미함

그리고 각각의 레지스터는 32bit인데 16bit의 하위 호환을 위해 X로 나눠지고 X는 다시 H/L 구역으로 나눠짐 즉 EAX를 예로들면 32bit를 다 쓰고 싶으면 EAX를 사용하고 2바이트(16bit)만 쓰고 싶으면 EAX의 하위 비트 부분인 AX를 이용하면 되는 것, 1바이트만 쓰고싶으면 AH쓰면 되겠쥬? (알뜰하죠 ?ㅋ)

레지스터의 용도 정도만 간단하게 알고 넘어가야지~

Tomcat의 취약점에 대해서 조사해봅시다

Tomcat 취약점

Tomcat은 대부분의 사람이 아는것처럼 웹서버를 돌릴 때 사용된다.

아파치 소프트웨어 재단에서 개발한 서블릿 컨테이너만 있는 웹 애플리케이션 서버라고 한다.

[ 고양이 디자인 무엇;;;]

일단 대표적인 Tomcat 취약점에 대해서 설명해보겠다.

먼저 tomcat에는 서블릿 클래스를 등록하는 web.xml이 존재한다. 해당 문서에는 다음과 같이 PUT과 DELETE 메소드에 대해서의 거절유무를 설정하는

'readonly' 속성이 존재한다. 해당부분이 'false'로 되어있다면 취약점이 발생한다. (거절하시겠습니까 ? 아니요 = put,delete메소드 찬성!)

default는 true인데 개발자가 false로 변경하고 건들지 않았을수도 있음.

아무튼 간에 이후에 공격자는 위조된 요청을 보내서 PUT방식으로 업로드가 가능해짐

여기서 jsp파일을 업로드를 했을 때 확장자 필터링이 없을 시에는 당연히 PUT 요청이가서 취약점이 발생할 것.

하지만 대부분 확장자 필터링을 거치게되는데 어떠한 필터링 검증로직이냐에 따라서 다양한 우회 기법이 있을 수 있음.

기본적으로 공백이나 '\'같은 문자들은 치환되어 있는데 여기서 jsp파일 확장자 필터링을 우회하는 취약점이

CVE-2017-12615 이다.

오늘부터 리버싱이다!!!!

리버싱은 하는 방법에 따라서 2가지로 나뉘게 된다. 정적분석과 동적분석이다.

정적분석

정적분석은 파일의 겉모습을 분석하여 관찰하는 방법이다. 동적적인분석과는 다르게 파일을 실행시키지 않고 분석한다.

파일의 종류, 크기, 헤더정보, API 등 여러가지 정보를 얻어서 동적분석할 때 유용하게 사용될 수 있다.

정적분석 툴로는 IDA, Ghidra가 있고, 올해 3월에 기드라가 무료로 풀렸는데 ida랑 ghidra딱 두가지만 사용해 볼 예정이다.

[사진. Ghidra 짱짱]

동적분석

동적분석은 말그대로 동적으로 PE를 분석한다. 프로그램을 실행시켜보면서 분석하는 행위.

레지스트리, 메모리 상태 등을 확인하며 프로그램의 동작원리를 파악할 수 있다.

대표적인 동적분석 도구로는 x64dbg, ollydbg가 있으며 대세가 지난 올리디버거 보다는 x64dbg를 사용해볼 예정입니다

[그림2. 무려 한글버전의 xdbg] - 영어로 바꿔서 쓰는게 호환좋다고함;;

입문으로 블랙펄 콘치님의 리버싱 튜토리얼부터 시작하였다. (https://bpsecblog.wordpress.com/2016/06/10/re_tutorial_3/)

먼저 PE파일을 준비했다. 소스는 다음과 같이 준비했다. (환경 : 코드블록)

이 PE파일을 리버싱할 것이다. 

hellow!!.exe

먼저 무작정 x32dbg에 해당 파일을 넣고 돌려보았다. 그 후에 F7,F8,F9를 눌러가며 무슨 동작을 하는 키인지 구글링하면서 눌렀다.

F7 : 안으로 단계진행 (함수만나면 진입)

F8 : 건너서 단계진행 (함수만나도 그냥넘어감)

F9 : 실행 (첨부터 끝까지 실행됨)

짜잔! call을 지나서 hellow!!가 출력됨. 끝! (visual studio로 안해서 그런건진 모르겠는데 내용이 약간 달랐다)

1 page proposal

file-upload 취약점

apache tomcat 취약점

리버싱 입문 - 리버싱 핵심 원리 및 구글링을 통한 검색

FCKeditor

FCKeditor는 게시판 에디터 입니다. 버전이 업그레이드 되면서 CKeditor(?)로 바뀐거 같은데 확실하진 않아요

게시판이라는게 xss공격에 취약한 부분이 있기마련! 조심스럽게 구글에 'FCKeditor 취약점'을 검색했습니다. [검색!]

그랬더니 제가 생각한 xss보다는 fileupload취약점이 더 많이 검색되었습니다...

가장 대표적인 취약점 페이지로는 test.html이 되겠다.

해당 파일의 경로에 test.html를 서버로 돌려보면 업로드를 할 수 있는 부분이 있다.

이 부분에 웹셸을 업로드할 수있는 취약점이 있다고 한다. (ver. 2.6.11)

웹셸은 알아서 다운로드 받아서 실습하고, config과정 들은 [여기]를 참고하면 될 것같다.

이러한 취약점이 있는 페이지들은 다음과 같다.

- /FCKeditor/editor/filemanager/browser/default/connectors/test.html

- /FCKeditor/editor/filemanager/browser/default/browser.html

- /FCKeditor/editor/filemanager/upload/test.html

이거말고도 더있다능...

대처방법

일단 snort룰셋을 적용 시키는 방법

1. drop tcp any any -> $내부_네트워크 any (content:"test"; sid=10000001;)

2. alert tcp $내부_네트워크 any -> any any (msg:"wp-login access"; content:"test"; sid=10000003;)

1. 외부에서 내부의 test페이지로의 접근을 차단하고,

2. 내부에서 test페이지로의 접근을 탐지한다.

그 다음으로는 아얘 test파일 자체를 삭제하는 방안이 있고, 서버단에서 해당 파일의 실행권한을 제한하는 방법이 있겠다.

ㅋ이번엔 joomla 취약점 조사이다

Joomla

편하게 줌라(?)로 말하겠다. 줌라역시 wordpress와 더불어 세계 3대 CMS로 꼽힌다. (비교는 되지 않지만...)

줌라 역시 wordpress와 마찬가지로 수많은 취약점들이 존재합니다.

줌라의 공식 홈페이지에서 현재 올라오는 취약점들과 해결된 취약점들의 목록을 확인할 수 있습니다. [바로가기]

Joomla역시 Wordpress와 마찬가지로 joomla 자체 이슈, 플러그인 이슈, 테마 이슈등 홈페이지를 제작하는 프로그램이 갖는 이슈들에 대해서 다양한 취약점이 발견되고 있고, 그중에서도 sql injection 취약점 및 다른 취약점들이 업로드 되고 있습니다. (exploit-db)

joomla도 wordpress의 wp-login.php와 마찬가지로 고유의 페이지('administration')(를 가지고 있습니다. (administrator 입니다. administration 아님 ㅎ)

비슷하게 공격자는 joomla로 작성된 페이지임을 확인해보기 위해서 다음과 같이 URL을 요청해볼 수 있습니다.

물론 페이지가 뜨면 joomla로 작성되었을 수도 있겠다. 라고 생각할 수도 있을것 같습니다. /administration을 워낙 많이 쓰는지라 자세하게 모르겠습니다...

snort도 wordpress랑 마찬가지로

1. drop tcp any any -> $내부_네트워크 any (content:"administartor"; sid=10000001;)

2. alert tcp $내부_네트워크 any -> any any (msg:"wp-login access"; content:"administartor"; sid=10000002;)

이렇게 외부에서 내부로의 액세스는 차단하고 내부에서 해당페이지에 접근하는 것만 열어두면 되지 않을까 싶다.

다른 joomla 취약점

joomla도 내가알지 못하는 resolved된 취약점들이 많이 있다.

joomla의 권한 상승 취약점과 계정 생성 취약점에 대해서 잘 정리해 놓은 블로그가 있어서 소개한다. [바로가기] [원격 코드 실행 취약점]

wordpress와 joomla 취약점을 보면서 php를 배워보고 싶다고 느껴졌다!