취약점

- 로그인이 불필요한 계정이나 OS 및 패키지 설치 시 기본적으로 생성되는 계정으로 쉘이 설정되어있을 경우, 공격자는 기본 계정들을 통하여 중요파일 유출이나 악성코드를 이용한 root 권한 획득 등의 공격을 할 수 있음

 

- Session timeout 값이 설정되지 않은 경우 유휴 시간 내 비인가자의 시스템 접근으로 인해 불필요한 내부 정보의 노출 위험이 존재함

 

보안조치

 

1. 로그인이 필요하지 않은 계정에 대해 /etc/passwd에서 /bin/false/bin/nologin 쉘 부여

2. /etc/profile에서 TMOUT=600초(10분) 설정

동안 입력이 없을 경우 접속된 Session을 끊도록 설정

 

1. 사용자 shell 점검

#vi /etc/passwd 

root와 test 계정만 로그인 할 수 있고 이외의 계정은 로그인할 수 없게해주자

 

결과

 

 

2. TMOUT 설정

#vi /etc/profile
#source /etc/profile	//작성했으니 적용해주자!

600초 동안 미입력 상태일 경우 세션을 종료한다

더보기

쉘 종류에 따른 다른 적용방법

<sh, ksh, bash 사용 시>

#cat /etc/profile(.profile)

TMOUT=600

export TMOUT

 

<csh 사용 시>

#cat /etc/csh.login 또는 /etc/csh.cshrc

set autologout=10

 

계정별 적용방법

#cd ~ //홈디렉토리 이동

#vi .bash_profile

TMOUT=600

export TMOUT

결과

telnet이나 ssh 접속 중이라면 600초 이후 자동종료!

취약점

su 명령어를 모든 사용자가 사용하도록 설정되어 있는 경우, root 계정 권한을 얻기 위해 패스워드 무작위 대입 공격을 시도하여 root 계정 패스워드가 유출될 위협이 있음

 

따라서, su명령어가 su 관련 그룹에서만 허용되도록 설정하자!

 

보안조치

su 사용자를 지정하는 방법으로는 2가지 방식이 있다. 하나는 "PAM 설정", 두 번째는 "권한 설정"이다.

PAM 설정은 PAM 모듈을 이용하고 권한 설정은 wheel이라는 그룹을 관리하여 이 그룹의 구성원만이 su를 사용할 수 있도록 한다.

여기서는 두 번째 방식을 적용하도록 하겠다!

 

 

■ 먼저는 wheel 그룹을 확인해보자!

[root@localhost ~]# cat /etc/group | grep wheel
wheel:x:10:root,test

구성원으로서 root가 존재한다, test계정을 추가해주었다.

 

■  다음 3가지를 수행

#1 su명령어 위치 확인
[root@localhost ~]# which su
/usr/bin/su
[[root@localhost ~]# ls -l /usr/bin/su
-rwsr-xr-x. 1 root root 32128 10월  1 02:46 /usr/bin/su

#2 그룹변경
[root@localhost ~]# chgrp wheel /usr/bin/su
[root@localhost ~]# ls -l /usr/bin/su
-rwxr-xr-x. 1 root wheel 32128 10월  1 02:46 /usr/bin/su

#3 SetID설정
[root@localhost ~]# chmod 4750 /usr/bin/su
[root@localhost ~]# ls -l /usr/bin/su
-rwsr-x---. 1 root wheel 32128 10월  1 02:46 /usr/bin/su

#3에서 SetUID를 설정해주는 이유는 기본적으로 su명령어는 관리자 권한이 필요하기 때문이다.

따라서, 명령어가 실행될 때만 사용자의 권한을 위임받을 수 있는 setuid를 적용해준 것이다(su 사용자는 현재 root)

*chmod 4750 : other에게 실행권한을 주면 말짱도로묵

 

 

결과

test는 wheel에 속하므로 정상 사용이 되고

test2는 wheel에 속하지 않으니 사용이 안된다!

 

 

참조

취약점

1. root 계정과 동일 UID 계정이 존재하면 비인가자에게 노출되었을 경우, 시스템 권한을 탈취당할 수 있다(UID=0을 일반 계정이 갖는 경우)

2. OS나 Package 설치 시 Default로 생성되는 계정 및 불필요한 계정들이 존재할 경우, 스워드가 무작위 대입 공격에 의해 유출될 수 있다.

3. 시스템에 불필요한 그룹이 존재할 경우, 해당 그룹 소유의 파일이 비인가자에게 노출될 수 있는 위험이 존재함

4. 관리자 그룹에 속한 계정이 비인가자에게 유출될 경우, 시스템 권한이 탈취당 할 수 있다. 

5. 침해사고 이후 추적할 경우, 동일한 UID를 악용한 공격자의 추적이 어려움

 

따라서, UID(0)은 오직 루트에게만 설정하고 기타 사용자와 그룹에 대한 관리를 해주자!

 

 

보안조치

 

■ passwd파일에서 살펴볼것

[root@localhost ~]# vi /etc/passwd
root:x:0:0:root:/root:/bin/bash
test:x:1000:1000::/home/test:/bin/bash
test2:x:1001:1001::/home/test2:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
...

*0은 오직 루트만

*중복UID 없게끔

*디폴트계정은 nologin으로 설정

 

 

■ group파일에서 살펴볼것

[root@localhost ~]# vi /etc/group
root:x:0:
test:x:1000:
test2:x:1001:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:
disk:x:6:
lp:x:7:
mem:x:8:
...

*관리자 그룹에 불필요한 계정 없게끔
*불필요한 그룹 없게끔

 

 

참조

취약점

시스템의 사용자 계정 정보가  평문으로 저장되었다면 패스워드가 노출될 수 있음

따라서, 계정 정보를 포함하는 파일에 사용자 계정 패스워드가 암호화되어 있는지 점검하자!

 

보안조치

살펴볼 파일은 2가지로 /etc/passwd, /etc/shadow

각 각 계정 정보와 암호화된 패스워드가 저장된 파일이다.

 

■ 두번째 필드가 x인지 확인!

[root@localhost ~]# vi /etc/passwd
root:x:0:0:root:/root:/bin/bash
test:x:1000:1000::/home/test:/bin/bash
test2:x:1001:1001::/home/test2:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...

*x처리 되었다는 것은 /etc/shadow에 암호를 저장하겠다는 의미

*파일명 : 암호화여부 : UID : GID : 코멘트 : 홈디렉토리 : 쉘 종류

 

 

■ 암호화되어있는지 확인해보자

[root@localhost ~]# vi /etc/shadow
root:$6$8ENNViD/$vfuTIgR7auG3sTACSusNYHypDIUrrbDPeagimsVh96JZ9HDyst1AbtnWkLtWs78V8YmEK3EQWDH.T4icl1qUp1:18625:0:99999:7:::
test:$6$2SxS4Y3U$BobgW3YEDqlf04oy4z7uBR66ZDKJur6APphZpEdkRPCJS6fzo//S6pWwjPpI7REiz6e7WP/4uLPrZPDT6g3pm/:18625:1:60:7:::
test2:$6$B0PgwlUW$OXvi78nRXbCVLJ19.8wrFsJVfLIhBMQutlbE2ncQR9WtDGep793My.sIG2wvYl.OHoRJ/ONAqIZwibfl91upq0:18629:1:60:7:::
bin:*:18353:0:99999:7:::
...

암호화가 되어있는 것을 확인할 수 있다.

$SHA-512 해쉬$솔트 값$암호화된 패스워드

더보기

○ Hash 종류 
- $1 : MD5 
- $2 / $2a / $2y : Blowfish  
- $5 : SHA-256  
- $6 : SHA-512 
○ salt : 동일한 패스워드가 서로 같은 해시 값을 갖지 않도록 사용하는 랜덤 값  
○ hash 결과 : 패스워드 + salt 데이터를 해시 함수에 넣은 결과 값 

출처 : infosecguide.tistory.com/9

 

추가로 pwunconv명령어는 passwd에 암호를 표기하겠다는 뜻이지만

passwd파일이 모든 사용자에게 읽기 권한을 허용하기 때문에 리눅스에서는 자동으로 shadow에 저장되고 있다.

[root@localhost ~]# pwunconv
[root@localhost ~]# vi /etc/passwd
root:$6$8ENNViD/$vfuTIgR7auG3sTACSusNYHypDIUrrbDPeagimsVh96JZ9HDyst1AbtnWkLtWs78V8YmEK3EQWDH.T4icl1qUp1:0:0:root:/root:/bin/bash
test:$6$2SxS4Y3U$BobgW3YEDqlf04oy4z7uBR66ZDKJur6APphZpEdkRPCJS6fzo//S6pWwjPpI7REiz6e7WP/4uLPrZPDT6g3pm/:1000:1000::/home/test:/bin/bash
test2:$6$B0PgwlUW$OXvi78nRXbCVLJ19.8wrFsJVfLIhBMQutlbE2ncQR9WtDGep793My.sIG2wvYl.OHoRJ/ONAqIZwibfl91upq0:1001:1001::/home/test2:/bin/bash

 

참조

취약점

Google 같은 검색엔진은 검색로봇을 이용하여 웹페이지를 수집하고 검색결과에 노출시키는데

이때, 노출되어서는 안되는 정보가 검색엔진에 노출될 수 있다.

 

따라서, 외부에 공개할 정보의 범위를 제한하는 설정을 해주자!

 

보안조치

작성해줘야할 파일은 robots.txt

이 파일은 검색엔진에 의해 참고된다.

 

#cd $Web_Root	//웹서버 루트로 이동한다

#vi robots.txt	//파일 생성해주자
User-agent: *	//모든 검색엔진을 지정한다 구글:Googlebot 
Disallow: /	//적용할 디렉토리를 지정 웹루트로부터 하위 디렉토리를 포함

User-agent: *	//모든 검색엔진이 수집하는 것을 허용
allow: /

User-agent: Googlebot	//구글 엔진만 허용
Allow: /

User-agent: Naverbot	//네이버 엔진만 허용
Allow: /

그밖에 엔진들
Daumoa
Msnbot
Bingbot

 

 

마무리

robots.txt 파일은 텍스트 파일로서 누구나 URL을 통해서 열람이 가능한 파일이므로 관리자 페이지경로와 같은 민감한 경로는 포함해서는 안됨

(예를들어, Disallow : /admin/admin.jsp)

 

 

참조

' > 보안 설정' 카테고리의 다른 글

[JSP] 16. WebDAV 취약점  (0) 2020.12.30
[JSP] 14. 사용자 정보 및 기타 중요 정보 노출  (0) 2020.12.30
[JSP] 12. 에러 페이지 미비  (0) 2020.12.28
[JSP] 11. 백업파일  (0) 2020.12.27
[JSP] 10. 디폴트 페이지  (0) 2020.12.27

취약점

WebDAV는 웹서버 관리 프로그램으로 FTP와 유사하다.

윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인 WebDAV가 계속 사용가능하도록 설정되어 있고,

WebDAV 라이브러리 파일의 속성 및 홈페이지 디렉토리에 쓰기 권한이 모두 허용되어 있는 경우

해커가 WebDAV 도구를 사용, 원격에서 홈페이지 디렉토리에 임의의 파일을 삽입하여 화면을 변조할 수 있다.

 

따라서 윈도우 서버를 운용시에는 이 서비스를 사용안함으로 변경시켜준다!

 

보안조치

서버 환경이 리눅스인 관계로 내용만 기술하고 실습은 PASS

 

IIS 를 사용하지 않을 경우

 윈도우의 서비스 설정에서 [World Wide Web Publishing Service] 속성을 사용 안함으로 설정

 IIS 를 사용하지 않을 경우

 레지스트리 편집기(Regedt32.exe)에서 다음 키를 찾아 값을 수정하거나 추가함                                                                                                                                               

"JSP 보안 개발 가이드" 에서

참조

 
 

 

 

 

취약점

웹사이트에서 중요 정보에 대한 데이터 암호화를 적용하여도 정보가 노출될 수 있다.

2가지 유형으로 살펴보면

 

 첫 째, 웹사이트 운영상의 단순한 실수로 발생할수있다.

예를 들어, 관리되지 않고 방치되는 게시판 또는 삭제되지 않은 구 버전 웹사이트, 백업 파일 관리 미흡, 관리자의 실수로 업로드된 엑셀 파일 또는 게시물, 비공개 게시물이 설정 실수로 인해 전원에게 공개되는 경우 등을 들 수 있다.

 

 둘 째, 웹사이트 설정 오류나 보안 취약점으로 발생할 수 있다.

예를 들어 암호화가 미흡하거나 파일 업로드 취약점이나 파일 다운로드 취약점을 통해 서버 측의 리소스가 직접 유출되는 경우, 디렉터리 인덱싱에 의해 파일 목록이 유출되는 경우, 파라미터 변조 취약점 등에 의해서 발생하는 경우, SQL Injection으로 인한 유출 등을 들 수 있다.

 

따라서, 운영 담당자의 상시 웹사이트 점검 노력과 보안 취약점의 제거 대책이 종합적으로 적용되어야 한다.

 

 

보안조치

  • 공지사항에 올린 게시물에 개인정보가 포함되어 있지 않은가?

  • 게시판에 업로드한 첨부 파일에 개인정보가 포함되어 있지 않은가?

  • 웹사이트 리뉴얼 후 구버전 웹사이트가 계속 접속 가능한 상태로 방치되어 있지 않은가?

  • 웹사이트에 관리되지 않는 불필요한 포트가 허용되어 있지 않은가? (예: 80 포트와 8080 포트를 동시 허용된 상태로 8080 포트에 웹방화벽이나 SSL 적용이 이루어지지 않는 경우)

  • 공개/비공게 게시판 또는 서비스에 대한 접근 Role 설정이 적절하게 관리되고 있는가?

  • 웹 방화벽이나 SSL 적용이 누락된 페이지가 존재하지 않는가? 

또한 사회 공학적 유형의 정보 유출이 발생하지 않도록 다음과 같은 정책의 적용해야 한다.

  • 주민등록번호, 비밀번호와 같은 민감한 정보 입력 시 화면상에 ‘*’로 처리한다.

  • 관리자 페이지 등을 통해 사이트 운영자가 회원들의 개인정보에 무단으로 접근하여 열람하지 못하도록 대책을 강구한다.

  • 민감한 정보에 대한 접근은 로그를 기록하고 규정에 따라 보관하도록 한다.

                                                                                                                                                                 "JSP 보안 개발가이드" 에서

 

 

마무리

웹사이트의 보안 조치는 기술적인 측면뿐 아니라 민감정보 와일드카드 처리나 개인정보 보관에 관련한 정책 등 관리적 측면에서도 수행되어야 한다.

 

 

참조

' > 보안 설정' 카테고리의 다른 글

[JSP] 17. 검색 엔진 중요정보 노출  (0) 2020.12.30
[JSP] 16. WebDAV 취약점  (0) 2020.12.30
[JSP] 12. 에러 페이지 미비  (0) 2020.12.28
[JSP] 11. 백업파일  (0) 2020.12.27
[JSP] 10. 디폴트 페이지  (0) 2020.12.27

개요

앞서 암호를 크랙 해보았다. 이번에는 무선환경에서 암호화되어 송수신되는 암호 패킷을 복호화해보자!

 

실습환경

웹서버 : http://172.30.1.30:8080 

PC : 172.30.1.41 

 

시나리오 : 공격자는 네트워크 보안이 취약한 곳를 찾았고 패킷을 수집 중이다. 얼마 뒤 한 사용자가 이 네트워크에 접속하여 특정 홈페이지에 회원가입을 시도한다.

 

네트워크 정보 : 

사용자 화면 :

 

 

과정

1. 4way-handshake을 통한 재인증 패킷 수집(Wifi 패스워드 크래킹 참고)

2. airdecap-ng -p a123456789 /packetD/packets-01.cap  -e "KT_GiGA_2G_Wave2_1C49"

 

패스워드와 캡처된 패킷 그리고 ESSID를 인자로 넣어주자

 

복호화된 패킷이 만들어졌다

vi로 열어보자

 

잘 찾아보면 ID와 PW가 보이는 것을 확인할 수 있다!

 

마무리

http통신은 데이터 암호화를 하지 않는다 그래서 네트워크 패킷만 복호화하면 내용물을 볼 수 있다.

반면 https는 암호화를 지원하기 때문에 네트워크 패킷이 복호화되더라도 내용물은 볼 수 없다.

따라서 https을 지원하는 웹사이트가 더 안전할 수밖에!

'네트워크 > 무선 해킹' 카테고리의 다른 글

WPA-PSK 패스워드 크래킹  (0) 2020.12.29

개요

해킹의 핵심은 인증이 수행되는 패킷들을 수집하고 여기에 다수의 암호문을 대입!

 

 

과정

1. 패킷 캡처를 위한 무차별 모드 활성화 
#airmon-ng start wlan0 monitor 

 

2. 네트워크 정보 및 패킷 캡처
#airodump-ng --bssid 88:3C:1C:AE:1C:4D -c 2 -w packets wlan0

 

3. 재인증 발생 유도
#aireplay-ng --deauth 100 -a 88:3C:1C:AE:1C:4D wlan0

 

4. 크래킹
#aircrack-ng -b 88:3C:1C:AE:1C:4D -w /packetD/worldlist.txt /packetD/packet-01.cap

 

 

 

실습환경

운영체제 : 칼리리눅스

 

네트워크 환경

무선랜카드

iptime n150ua

 

특이사항

 암호 앞에 5자리는 안다고 가정한다(a1234*****)

 암호길이와 복잡성(숫자,대소문자,특수문자)이 커짐에 따라 암호문 리스트가 기하급수적으로 증가하기때문

 

무차별 모드 활성화

지금 상태에서는 나에게만 오는 패킷만을 수신하고 나머지는 드랍한다. 패킷 캡처를 위해 모니터모드로 전환해주자

 

 

 

 

네트워크 정보 및 패킷 수집

네트워크 정보 확인

여기서 확인할 것은 공유기 아이디와 채널 번호(88:3C:1C:AE:1C:4D와 2)

 

패킷 수집

 BSSID와 채널을 대상으로 수집을 시작

 다음 단계에서 노랑 박스에 주목하자!

 이 프롬프트 창은 끄지말고 유지

 

   

 

재인증 발생 유도

패스워드 크랙의 핵심은 4-way handshake 과정의 인증 수행 패킷을 수집하는 것

 

재인증을 위해 기존 연결을 끊어주자!(사용자는 재접속을 진행하게됨)

 

 

이제 handshake가 수집된것을 확인!

ctrl+z로 수집 종료

 

 

 

크래킹

무차별 대입 공격에 쓰일 파일을 생성해주자

문자길이 10, 숫자와소문자, -t패턴생성시 @는 모르는 문자를 의미

 

 

크랙

수집한 패킷에 암호문을 대입하자

 

 

크랙성공!

보안대책

WPA2-AES_CCMP 방식을 이용한다

SSID를 숨김모드로 설정하여 무선랜 노출을 방지한다(무차별모드에서는 노출됨)

공개되어있는 초기 패스워드는 변경 후 사용

AP의 도난이나 리셋 버튼 차단 등 물리적 보안대책을 확보한다

worldlist.txt

'네트워크 > 무선 해킹' 카테고리의 다른 글

WPA-PSK 암호문 복호화  (0) 2020.12.30

취약점

 첫째로, (1) 패스워드 복잡성 설정이 되어 있지 않은 사용자 계정 패스워드 존재 시

비인가자가 무작위 대입 또는 사전 대입 공격을 통해 패스워드를 획득할 수 있다.

 

 둘 째,(2) 로그인 시도 임계값을 제한하지 않을 경우

무작위 대입 공격을 허용하게 되어 패스워드가 유출당할 수 있다.

 

따라서 시스템 정책에 관련 설정이 되어 있는지 점검하자!

 

 

보안조치 - (1) 패스워드 복잡성 설정

계정과 유사하지 않은 8자 이상의 영문, 숫자, 특수문자의 조합으로 암호 설정 및 패스워드 복잡성 옵션 설정

손볼 파일은 두 가지, /etc/pam.d/system-auth/etc/login.defs

각 각, 패스워드 정책과 패스워드 사용 기간 등을 설정할 수 있는 설정 파일이다.

 

 

복잡성 추가

[root@localhost ~]# vi /etc/pam.d/system-auth
...
password    requisite     pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
...

*retry=3 변경 도중 3번 틀리면 실패 처리

*llcredit(소문자), ucredit(대문자), dcredit(숫자), ocredit(특수문자)

*-1은 최소 하나를 사용해야 한다는 의미

*결과적으로 전체 길이는 8이고 대소문자, 숫자, 특수문자를 적어도 하나씩은 포함해야 하는 정책

 

 

■ 패스워드 최대/최소 사용 기간을 지정

[root@localhost ~]# vi /etc/login.defs 
# Password aging controls:
...
PASS_MAX_DAYS   60
PASS_MIN_DAYS   1
PASS_MIN_LEN    5
PASS_WARN_AGE   7
...

*최대 사용 기간은 60일, 최소 사용 기간은 1일, 만료 전 알림은 D-7

 

 

결과

설정 전

설정 후

암호 복잡도 정책에 의해 쉽사리 패스워드가 변경되지 않고

계정을 추가 생성 시 사용 기간도 최소 1일, 최대 60일로 잘 적용되고 있음을 알 수 있다!

 

 

보안조치 - (2) 계정 잠금 임계값 설정

로그인 시도 횟수를 제한해보자

수정해야 할 파일은 /etc/pam.d/system-auth

 

 

■ 로그인 시도 횟수를 설정

다음 설정 2가지를 추가 및 수정하자!

[root@localhost ~]# vi /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run
...
auth        required      pam_tally2.so deny=5 unlock_time=120 no_magic_root
...

...
account     required      pam_tally2.so
...

*unlock_time=120 : 5회 초과로 잠겼을 경우, 120초 이후에 잠금 해제

*no_magic_root : 루트 계정에게는 마법(?)이 효력 없음

 

 

결과

재시도 5번이 발생하면 즉, 6번째에서 잠김이 발생!

 

 

마무리

아무리 강력한 패스워드를 설정한다 한들, 무차별 대입 공격에 뚫릴 수 있다.

따라서 패스워드 정책도 까다롭게! 대입공격 차단도 철저하게!

 

 

참조

'리눅스 > 계정관리' 카테고리의 다른 글

[CentOS 7] root 계정 su 제한  (0) 2020.12.30
[CentOS 7] UID,GID와 관련한 보안  (0) 2020.12.30
[CentOS 7] 패스워드 파일 보호  (0) 2020.12.30
[CentOS 7] root 계정 원격 접속 제한  (0) 2020.12.25
개요  (0) 2020.12.25

+ Recent posts