반응형

1. 내용

SMTP 서버가 모두에게 허용되어 있어, 인가된 사용자뿐만이 아니라 인터넷에 있는 누구나 해당 서버를 이용하여 이메일을 전송할 수 있는 취약점입니다.


2. 영향도

 - 해당 취약점은 비인가자에게 SMTP 서버의 남용을 허용하여, 임의의 주소로 이메일을 보낼 수 있다.

 - 서버 자원이 낭비되어 과부하에 걸리거나 디스크 가용성 문제가 발생할 수 있다.

 - 내부망으로 메일 전송이 가능할 경우 메일의 출발지 주소를 임원진 메일 주소로 변경하여 스팸 메일의 피해가 더욱 커질 수 있습니다.

 - 관련 CVE 코드 : CVE-2006-5545, CVE-2006-0977, CVE-2005-2857, CVE-2002-0054, CVE-1999-0512, CVE-1999-0682


3. 대응방안

3.1 OS Level

※ Linux

 * 허용된 IP에 대해서만 Relay되도록 설정

   - 외부의 인가된 IP 혹은 서버에 대한 접근 권한 설정 ( /etc/mail/access 파일을 이용한 RELAY, REJECT, DISCARD 설정 )

   - KISA '스팸 메일 발송자 차단 및 서버릴레이 차단 방법' 참고 ( 링크 : https://spam.kisa.or.kr/spam/sub7_15.do )

 * IP기반 차단 도구를 이용하여 비정상 로그인 IP 차단


※ Windows

 * SMTP 서버 [속성] - [액세스], 릴레이 제한 설정

   - 인가된 도메인 및 IP에만 사용하도록 릴레이 제한 설정

 * SMTP 서버 [속성] - [액세스], 액세스 제어 인증 설정


3.2 Application Level

※ Solution

 * 솔루션에서 제공하는 RELAY 관련 설정

 * 이메일 전송 한도 등 메일 발송 제한 기능

 * 인가된 서버에만 메일 송수신을 허용하는 제한 기능

   - 메일 솔루션이 악용되지 않도록 솔루션에서 제공하는 기능을 검토하여 설정 및 적용


3.3 User Level

※ Credential

 * 메일을 전송하는 계정에 대해 인증을 요구하고 STARTTLS를 통해 암호화한다.

 * 패스워드 관리

   - 패스워드가 충분히 길도 높은 복잡도를 갖도록 설정

   - 다른 계정에서 중복으로 쓰지 않는 독립적인 패스워드 사용



참고)

https://www.blackhillsinfosec.com/how-to-test-for-open-mail-relays/

https://m.blog.naver.com/skinfosec2000/221920576711

반응형

'Hacking > Network' 카테고리의 다른 글

usage of Docker  (0) 2020.03.10
NIST, TDES 암호알고리즘의 사용제한 권고  (0) 2019.05.06
SSlv3 취약점 (POODLE vulnerability)  (0) 2019.05.06
SSH Dynamic Port Forwarding with SOCKS  (0) 2017.03.10
WPE 활용 SQL Injection  (0) 2017.03.08
블로그 이미지

rootable

,

usage of Docker

2020. 3. 10. 15:34

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

반응형

금융보안원에서 2018년 8월, 2030년까지 안전성을 허용했던 TDES의 사용을 점진적으로 중지하도록 권고하는 문서가 공개되었다.


여기서 TDES는 Triple Data Encryption Standard의 줄임말로써 3DES라고도 불린다.


보통 컨설팅 시 데이터 암호화에 권고하는 암호알고리즘으로 TDES를 포함하는데 이제는 제외하여야겠다.


자세한 사항은 아래 금융보안원의 문서를 참고하길 바란다.


☞ 다운로드 링크 : http://www.fsec.or.kr/common/proc/fsec/bbs/42/fileDownLoad/1605.do




반응형

'Hacking > Network' 카테고리의 다른 글

SMTP Open Mail Relay vulnerability  (5) 2020.12.07
usage of Docker  (0) 2020.03.10
SSlv3 취약점 (POODLE vulnerability)  (0) 2019.05.06
SSH Dynamic Port Forwarding with SOCKS  (0) 2017.03.10
WPE 활용 SQL Injection  (0) 2017.03.08
블로그 이미지

rootable

,
반응형

SSLv3이 취약한 HTTPS 프로토콜이라고 하여 어떤 취약점이 존재하는지 알아본 결과 POODLE 취약점(CVE-2014-3566)이 존재하여 취약하다고 하고 있다.


그래서 POODLE 취약점이 무엇인지, 어떤 식으로 동작하는지를 알아보았다.


1. POODLE이란 무엇인가?

 : POODLE은 Padding Oracle On Downgraded Legacy Encryption의 약자이다.

이를 해석하면 다운그레이드된 구식 암호화에 대한 패딩 오라클이라고 할 수 있다. 그렇다면 다운그레이드가 된다는 것은 무엇이며, 패딩 오라클이란 무엇인가에 대한 궁금점이 생긴다.


2. 다운그레이드의 의미와 POODLE 취약점 효과

 이에 대해서는 먼저 아래의 이미지를 보고 가자.


 SSL과 TLS는 서버와 클라이언트 중 한쪽이라도 최신 버전을 호환하지 않는 경우 이전 버전의 프로토콜로 연결을 재시도하는 동작이 있다.


 위의 이미지를 보면 Client에서 Browser를 이용하여 Server쪽으로 최신 버전의 암호화인 TLS를 이용하여 요청을 보내는데 이 때 공격자가 일부러 TLS에 대한 연결을 끊어 SSL 3.0까지 다운그레이드를 시킨다. 이 후 공격자는 패딩을 이용한 공격을 실행하여 Web 서버와 클라이언트 간의 통신을 Sniffing 할 수 있다.


3. Padding Oracle

 패딩 오라클에 대해서는 간단히 하나의 포스팅으로 넘어가기엔 방대한 설명이 필요하여 간단히만 설명하도록 하겠다.


 패딩 오라클이란 [복호화 시스템에 암호문을 넣었을 때 그에 대한 패딩의 올바름 유무를 보여주는 오라클]이라고 할 수 있다. 이 때, 바로 이 패딩이 올바른지에 따른 서버측의 응답을 이용해 암호화된 값을 평문으로 복호화할 수 있는 취약점이라고 할 수 있다.


부르트포싱을 통한 공격이라고는 하나 현재 Padding Oracle 공격을 위한 툴(https://github.com/iagox86/Poracle)도 존재할 뿐더러, 실제로 암호화된 값이 복호화가 되어 값 변경까지 가능하게 된다면 보안상 큰 구멍이 될 가능성이 존재하므로 많은 고객들을 관리하는 기업에서는 SSLv3가 아닌 TLS만을 사용할 것을 권고한다.


4. 대응방안

 대응방안이라고 하면 말그대로 보안상 취약한 SSLv3를 사용하지 않고 최신의 암호화 기법인 TLS(Transport Layer Security)를 이용할 것을 권고한다.


 아래는 서버 별 설정 정보이다.


☞ Apache

Apache SSL 설정 파일에 적용 후 서비스 재시작

- 파일 : /etc/apache2/mods-available/ssl.conf


SSLProtocol ALL -SSLv2 -SSLv3


☞ Nginx

nginx 설정 파일에 아래 내용을 추가한 후 서비스 재시작


ssl_protocols TLSv1 TLSv1.1 TLSv1.2


☞ IIS

regedit(레지스트리편집)을 통해 아래 레지스트리 키 편집

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols registry key

-> 하위 키에서 SSL 3.0에 대해 "00 00 00 00"으로 설정


참고)

https://blog.trendmicro.com/trendlabs-security-intelligence/poodle-vulnerability-puts-online-transactions-at-risk/

https://www.opentext.com/file_source/OpenText/en_US/PDF/OpenText-POODLE-Vulnerability-FAQ-KO.pdf

https://www.hahwul.com/2015/10/exploit-sslv3-poodle-attack-check-and.html

- http://bperhaps.tistory.com/attachment/cfile30.uf@21B98D33597949BB36C50B.pdf


반응형

'Hacking > Network' 카테고리의 다른 글

SMTP Open Mail Relay vulnerability  (5) 2020.12.07
usage of Docker  (0) 2020.03.10
NIST, TDES 암호알고리즘의 사용제한 권고  (0) 2019.05.06
SSH Dynamic Port Forwarding with SOCKS  (0) 2017.03.10
WPE 활용 SQL Injection  (0) 2017.03.08
블로그 이미지

rootable

,
반응형

1. 복습


1.1 SSH 터널링이란?

 - SSH 프로토콜을 이용하여 직접 접속할 수 없는 곳과 연결통로(터널)을 만들어 접근할 수 있도록 만드는 기술


1.2 옵션

 - 총 3가지 옵션이 존재한다. (L, R, D)

 - L = Local = 클라이언트측에서 지정한 포트를 listening하다가 연결이 요청되면 미리 설정된 원격지의 해당 포트로 데이터를 전송하는 옵션

 - R = Remote = 서버측에서 지정한 포트를 listening하도록 만들고, 해당 포트로 연결이 요청되면 클라이언트측의 지정한 포트로 데이터를 전송하는 옵션



2. SSH Dynamic Portforwarding


2.1 D옵션

 - D = Dynamic = 클라이언트측에서 지정한 포트를 listening하다가 연결이 요청되면 미리 설정된 원격지로 데이터를 전송하는 옵션


2.2 L,R 옵션과의 차이

 - L,R 옵션 : 하나의 포트와의 연결(1;1 매핑)

 - D 옵션 : 여러 포트와의 연결(1:n 매핑) => 지정한 포트로 접속하면 원격지에 내 PC가 존재한다고 생각할 수 있다.


2.3 명령어

[Linux 환경]

ssh -D [리스닝할 port] [계정]@[포워딩할 목적지 ip] [-p 목적지 ssh 포트]


- (ex) ssh -D 1111 root@10.10.10.10 -p 7899

- 만약 목적지의 ssh 포트가 default인 22번이라면 적지 않아도 된다.


[Windows 환경]

plink -D [리스닝할 port] [포워딩할 목적지 ip] [-P 포트] -l 계정 -pw 패스워드


- (ex) plink -D 1111 10.10.10.10 -P 7899 -l root -pw 1234

- 만약 목적지의 ssh 포트가 default인 22번이라면 적지 않아도 된다.


3. 실습


가정 : Web 서버에 웹쉘이 업로드 되어 있는 상태이다. 라우터와 첫번째 DB의 SSH 계정 정보를 알고 있을 때 방화벽을 넘어 두번째 DB에 접속하여라.


3.1 해결방법 1 = WEB Server에서 -D 옵션 사용

 - WEB server -> plink -D 3333 2.2.2.2 -P 22 -l test -pw test

(이 명령어를 작성할 경우 WEB server에 3333 포트로 연결이 요청되면 2.2.2.2의 22번으로 접속을 하여 공격자가 2.2.2.2에 위치한다고 볼 수 있다. 첫 번째 DB와 두 번쨰 DB는 서로 연결이 되는 상태이므로 Web Server의 3333포트로만 요청이 가면 목적지까지 도달이 가능한 것이다.)


 - WEB server -> plink -R 1111:localhost:3333 111.222.333.444 -P 1234 -l admin -pw admin

( 이 명령어를 작성할 경우 Router의 1111포트로 연결이 요청되면 WEB server의 3333포트로 요청을 넘겨준다. 위의 명령어로 인해 목적지까지 도달할 수 있다.)


- 공격자 PC -> plink -L 2222:localhost:1111 111.222.333.444 -P 1234 -l admin -pw admin

( 이 명령어를 작성할 경우 공격자 PC에서 2222포트로 연결을 요청하면 Router의 1111포트로 요청을 넘겨준다. )


- 공격자 PC -> localhost:2222 

( 이 명령어를 작성하면 Router의 1111포트로 넘어가고 이는 WEB server의 3333포트로 넘어가서 결과적으로 목적 DB까지 접속이 가능하다. )


3.2 해결방법 2 = Router에서 -D 옵션 사용

 - Web server -> plink -R 3333:2.2.2.2:22 111.222.333.444 -P 1234 -l admin -pw admin

(이 명령어를 작성하면 라우터의 3333포트로 연결이 요청되면 그 요청을 첫번째 DB로 넘겨준다.


 - Router -> plink -D 2222 localhost -P 3333 -l admin -pw admin

(이 명령어를 작성하면 라우터의 2222 포트로 연결이 요청되면 그 요청을 자신의 3333 포트로 넘겨준다. 위의 명령어로 인해 요청이 자연스럽게 첫번째 DB까지 하게되고 결과적으로 목적 DB까지 접속이 가능하다)


 - 공격자 PC -> plink -L 1111:localhost:2222 111.222.333.444 -P 1234 -l admin -pw admin

(이 명령어를 작성하면 공격자 PC에서 1111 포트로 연결이 요청되면 router의 2222포트로 연결을 넘겨준다.)


- 공격자 PC -> localhost:1111

( 이 명령어를 작성하면 위의 흐름대로 진행되어 목적 DB까지 접속이 가능하다)


3.3 해결방법 2가 가능한 이유

Q> 첫번째 DB가 내 것처럼 되야지 두번째 DB로 접속이 가능할텐데 해결방법 2처럼 진행하면 WEB 서버가 내 것처럼 되는 것 아닐까?

A> 결과부터 말씀드리면 아닙니다. D 옵션을 사용할 경우 터널링 흐름의 끝이 자기 자신처럼 동작하는 것입니다. 위의 흐름에서 터널링의 끝은 첫번째 DB이므로 공격자가 첫번째 DB에 있다고 볼 수 있게 되어 두번째 DB에 접속이 가능한 것입니다.













반응형

'Hacking > Network' 카테고리의 다른 글

SMTP Open Mail Relay vulnerability  (5) 2020.12.07
usage of Docker  (0) 2020.03.10
NIST, TDES 암호알고리즘의 사용제한 권고  (0) 2019.05.06
SSlv3 취약점 (POODLE vulnerability)  (0) 2019.05.06
WPE 활용 SQL Injection  (0) 2017.03.08
블로그 이미지

rootable

,
반응형

0. WPE란?

 - http 뿐만 아니라 아래 단계인 TCP 패킷도 잡는 프로그램

 - burp suite의 경우 TCP 패킷을 잡지 못하기 때문에 WPE를 사용한다.

 - 게임 해킹에 주로 사용되는 프로그램 (요즘에도 통하는 게임이 있을지는 모르겠다.. 해도 불법이니 하지는 말자)


1. WPE 사용법



 - Target Program 버튼을 통하여 현재 작동 중인 프로그램을 잡는다.

 - ▶ 버튼을 클릭해서 패킷을 잡도록 명령한다.

 - 패킷을 잡도록 하면 지나간 패킷의 수가 출력되며 오른쪽에 새로운 창이 뜨며 잡힌 패킷들의 정보가 출력된다.


2. 공격 순서

 - USERNAME에 sql injection을 진행해보았다. 하지만 ', " 등등 sql injection에서 사용하는 모든 것들을 필터링 하였다. 문제 자체가 WPE를 활용해보라는 것이기 때문이라 생각한다.

 - WPE를 통해 문제 파일을 Target으로 잡은 뒤 패킷을 잡도록 하고 123을 보내보았다. 잘 잡히는 것을 확인할 수 있었고 이제 수정을 하도록 하였다.

 - 123을 보냈을 때 [ ' or '1'='1'# ]으로 수정하도록 Filter를 이용하여 하였다. 하지만 이 때 [ ' o ] 까지만 수정이 되었다. 왜 그럴까 생각해봤더니 내가 입력해준 것만 수정을 해주는 것은 아닐까 생각하였다.

 - 그래서 수정해주고자 하는 문자와 수를 같게 하여 1231231231231 을 입력하여 수정하도록 하였다. 

 - 그랬더니 성공!!



반응형

'Hacking > Network' 카테고리의 다른 글

SMTP Open Mail Relay vulnerability  (5) 2020.12.07
usage of Docker  (0) 2020.03.10
NIST, TDES 암호알고리즘의 사용제한 권고  (0) 2019.05.06
SSlv3 취약점 (POODLE vulnerability)  (0) 2019.05.06
SSH Dynamic Port Forwarding with SOCKS  (0) 2017.03.10
블로그 이미지

rootable

,