Skills/Drill or Guard 2016. 10. 6. 22:15

오랜만에 올리는 글,


https://fossbytes.com/this-single-line-of-code-can-crash-a-linux-system/


현재 위와 같은 systemd 관련 서비스 거부 취약점이 발견되면서

다소 두려워 하는 관리자들도 있을 것이라고 생각하여 대처방안을 생각해 보았다.


사실 대처방안이라고 하기에도 그렇고,  단순한 Workaround 가 아닐지도  모르고

어차피 패치된 버젼 나오면 그 패키지를 사용하면 되지만,


언제 나올지 모를(금방 나올테지만)  패치,  그리고 리부팅이 필요할 것으로 보이므로

리부팅이 부담되는 사람을 위한 꼼수를 생각해 내었다.


(원래 어제 하도 난리일때 기사도 제대로 안보고 있다가 오늘 퇴근하고 집에오면서 생각좀 해봄)


1. NOTIFY_SOCKET 을 세팅하는 과정에 시스템은 어떤  감사가 이루어 질까?


-  해당 내용을 확인하기 위해 우선 audit 설정을 해주었다.


# auditctl -w /usr/bin/systemd-notify -p x -k systemd_notify


위 설정은 systemd-notify 가 수행되면 systemd_notify 라는 라벨(키워드)  로

audit log 를 남기도록 설정한 룰이다.


간단히 테스트 해보자.


#  NOTIFY_SOCKET=/run/systemd/notify systemd-notify "test"

# ausearch -i -k systemd_notify

type=PATH msg=audit(10/06/16 08:02:05.657:79) : item=1 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=s
ystem_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 08:02:05.657:79) : item=0 name=/usr/bin/systemd-notify inode=325712 dev=00:1d mode=file,755 ouid=root ogid=root
 rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 08:02:05.657:79) :  cwd=/root
type=EXECVE msg=audit(10/06/16 08:02:05.657:79) : argc=2 a0=systemd-notify a1=test                <<<<<<
type=SYSCALL msg=audit(10/06/16 08:02:05.657:79) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x2491450 a1=0x232cfe0 a2=0x246f850 a3=0
x7ffde71a9e40 items=2 ppid=4535 pid=5743 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=6 tty
=pts1 comm=systemd-notify exe=/usr/bin/systemd-notify subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify


여기서 execve 타입에서 해당 Argument 가 나오는게 확인되었다.


자,  그럼 일단 감사시스템은 구축했으니,  그냥 누가 이거 실행하면 조지면 되는건가?


하지만 이미 시스템은 망가진 뒤  일텐데?


2.  기존 systemd-notify 를 대체할 만한 방법이 없을까?

-  이 아이디어를 바탕으로 고민해보다가 누구나 간단히 사용 할 수 있을 만한

Bash scripts 를 이용한 커맨드 대체 를 생각했다.


#!/bin/bash

if [ -n $NOTIFY_SOCKET ]
then
    systemd-notify_org $1
fi


그래,  문제의 원인은 NOTIFY_SOCKET 이라는 환경변수의 사용이며,

notify 프로그램 뒤에 Argument 를 넣지 않았다는 것이 핵심이었다.


따라서,  이를 체크하여 만약 해당 내용이 Null 이 아니라면

( 나의 테스트로는 Redhat 계열에선 기본 Null 인거같다 -  레댓계열밖에 몰라!)

해당 변수를 먼저 해제하거나 그냥 해당 내용을 echo 로 뿌려주면 될 것 이다.


만약 해당 변수가 아무것도 없다면,  혹은 정상적으로 사용된 것이라면

원래 있던 이름이 바뀐 systemd-notify 를  실행시켜주면  아무 문제 없이 수행 될 것이다.


테스트 해 보았다.


[root@perftest ~]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify "test"
[root@perftest ~]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
systemd-notify_org [OPTIONS...] [VARIABLE=VALUE...]

Notify the init system about service status updates.

  -h --help            Show this help
     --version         Show package version
     --ready           Inform the init system about service start-up completion
     --pid[=PID]       Set main pid of daemon
     --status=TEXT     Set status text
     --booted          Check if the system was booted up with systemd
     --readahead=ACTION Controls read-ahead operations
[root@perftest ~]# echo $NOTIFY_SOCKET

[root@perftest ~]#


Audit 내용은 아래와 같다.


type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=2 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=1 name=(null) inode=6081 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(10/06/16 09:05:33.533:199) : item=0 name=/usr/bin/systemd-notify inode=437427 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 09:05:33.533:199) :  cwd=/root
type=EXECVE msg=audit(10/06/16 09:05:33.533:199) : argc=2 a0=/bin/bash a1=/usr/bin/systemd-notify         <<<<<
type=EXECVE msg=audit(10/06/16 09:05:33.533:199) : argc=3 a0=/bin/bash a1=/usr/bin/systemd-notify a2=test
type=SYSCALL msg=audit(10/06/16 09:05:33.533:199) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1af3c00 a1=0x1b44a40 a2=0x1b28870 a3=0x7ffc2e391ca0 items=3 ppid=2191 pid=7914 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=1 tty=pts0 comm=systemd-notify exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify
----
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=2 name=(null) inode=379981 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=1 name=(null) inode=6081 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:shell_exec_t:s0
type=PATH msg=audit(10/06/16 09:05:36.597:200) : item=0 name=/usr/bin/systemd-notify inode=437427 dev=00:1d mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0
type=CWD msg=audit(10/06/16 09:05:36.597:200) :  cwd=/root
type=EXECVE msg=audit(10/06/16 09:05:36.597:200) : argc=2 a0=/bin/bash a1=/usr/bin/systemd-notify
type=EXECVE msg=audit(10/06/16 09:05:36.597:200) : argc=3 a0=/bin/bash a1=/usr/bin/systemd-notify

type=SYSCALL msg=audit(10/06/16 09:05:36.597:200) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x1b45a20 a1=0x1abb040 a2=0x1b28870 a3=0x7ffc2e391ca0 items=3 ppid=2191 pid=7916 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=1 tty=pts0 comm=systemd-notify exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=systemd_notify


사실 -z 를 넣어야 하는게 맞나?  싶었는데 테스트 해본결과 -n 로 넣어 놓는게 훨씬 무탈하고 자연스러워

해당 내용을  유지하기로 했다.


각자 script 및 원본 명령 위치등은 알아서 수정하면 될거같다.  보안적으로.


간단한 테스트만 하고 올린 글이라 각자 상황에 맞게 이런 컨셉으로 보완해 사용하시길.


아주 간단히 테스트만 한두시간 해보고 올리는 글이니 문제가 된다면 삭제할 예정

(나에게 책임이란 없다.)


끝.

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of https://seblog.mirr4u.com BlogIcon mirr

    심심해서 몇번 테스트 해본 결과 위와같이 스크립트를 통하게해서 직접적으로 /run/systemd/notify 라는 소켓파일에 Null 인자로 write access 하는 부분만 막으면 큰 문제 없는 것 같다..
    어차피 패치 나올것이므로 간단하게만 테스트 한거니, 컨셉만 생각해서 적용하면 될거같다...

    2016.10.07 00:00 신고

Skills/Drill or Guard 2008. 9. 5. 11:38
http://www.securityfocus.com/brief/812?ref=rss

대략 명박이가 주장하는 간첩 원정화에 대한 내용인데... 흥미롭다...ㅋㅋ
posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2008. 9. 4. 09:08
공개된지 얼마나 됐다고 벌써부터 취약점들이랑 익스플로잇이 나오고있는거야...

구글의 인기와 크롬의 관심도가 높음을 증명해 주는 모습일 듯 하다.

버그트랙에 보고된 취약점 내용은 "크롬"으로 파일다운로드시 

묻지않고 자동 다운로드가 되는 점을 이용해 스크립트를 실행 키는듯 하다.

또한 크롬이 크래쉬 되서 리스타트를 해야 할 경우 EIP레지스터를 이용한 

메모리 조작 가능성이 있다고 보고됐다..물론 밀X에서 ㅋㅋ
posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2008. 4. 7. 14:28
좋은진호님이 예전에 말씀하셨떤 중국 정부기관사이트 내의 악성코드 배포페이지

관련 글을 정리해주셨다.....

트랙백을 배워보자 ( 이제서야?? 캭 )

posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2008. 3. 24. 18:30
진호님께서 알려주셨다.

[17:56:43] <좋은진호> 아~ 미래에셋에 임시 설치된 장비는
[17:56:52] <좋은진호> 시스코의 가드&디텍터네요
[17:57:19] <좋은진호> 21일 오후 4~5시경 안랩 서비스사업부에 긴급 설치 구축 의뢰.
[17:57:29] <좋은진호> 17:21부터 설치 완료 및 동작개시
[17:57:38] <좋은진호> 17:30~ 서비스 정상화
[17:57:53] <좋은진호> .
[17:57:53] <좋은진호> .
[17:58:21] <좋은진호> 시스코 자체 자료임.

마당발 진호님.....캭

ps : 오타있던거 수정해달레서 그냥 놔두려다 수정했다 캭
posted by mirr
TAG DDOS, System

댓글을 달아 주세요

Skills/Drill or Guard 2008. 3. 21. 17:48
요즘 역시 DDoS 공격이 대세다...

미래에셋은 프리즘 IDC에 위치해 있따. 어디겠는가.. 아이템베이가 있던 곳이다.

자세한건 좋은진호님께서 정리해주시면 트랙백으로 달아놔야겠다..

사실 좋은진호님 블로그에 트랙백 달아보고싶어서 트랙백 쓰는법좀 알아볼까해서 쓴 글이다.

내가 글 쓰고 관련글 쓴 진호님께 트랙백 보내기 하면 되는거 맞나?? 맞지?? 맞죠??

수정 : 블로그에 쓰신줄알았떠니 커피닉스에 쓰셨다 ㅋㅋ 링크걸어야지

미래에셋 DDoS 공격
posted by mirr
TAG DDOS, hacking

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of http://truefeel.tistory.com/ BlogIcon 좋은진호

    블로그에 쓸 걸 그랬나. ^^

    2008.03.22 00:53

Skills/Drill or Guard 2008. 3. 18. 11:02
커피닉스( http://coffeenix.net ) 진호님의 CONCERT 보안세미나 정리글을 링크한다.

이시기에 난 예비군 향방작계훈련과, 이직등의 문제로 복잡해서 세미나참석을 할 수 없었따.

CONCERT 보안세미나 정리글
posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2008. 2. 14. 16:35
패치된 커널 올라옴...
posted by mirr

댓글을 달아 주세요

Skills/Drill or Guard 2007. 7. 24. 14:13

그녀는 multiple vulnerability를 가지고 있어 malicious code를 삽입하기 유용하다.
일단 애인이 있는 그녀는 애인자체가 취약하다.
Phone number spoofing 기법을 이용하여 sms message에 malicious code를 삽입하여 보내면
신뢰된 관계를 없앨수 있다.
일단 DDOS공격으로 신뢰관계에 있는 애인의 SMS에 더이상의 message가 가지 않게 만든다.
인터넷 상에는 우리가 사용하기 쉬운 무료 SMS Message sending service가 즐비하다.
그후 Phone number spoofing 기법으로 그녀의 SMS에 malicious message를 보내고
그녀의 ack message를 추측하여 다음 message를 보낸다.
그녀와 애인의 신뢰관계가 깨지기 시작하면 일단 틈새가 보이기 시작한것이다.

그녀의 nobody privilege shell을 얻기 위하여 우리는 remote exploit을 준비한다.
일단 external로 connect할수 있는 hole을 찾아보도록 하자.
여기서 우리는 여러가지 vulnerability를 찾아서 잘 짜여진 각본대로 순식간에 해결하는것이 필요하다.
필요하다면 비슷한 host를 찾아 충분한 연습후 실전에 들어가는 지혜도 쓰일수 있다.
일단 그녀의 이름과 나이를 이용하여 searching.......
cyworld에 minihome page의 XSS Vulnerability가 있다는 것이 확인되었다.
그녀의 environment들에 접근하여 유용한 script들을 띄운다.
a coincidence... 이것이 그녀의 nobody privilege shell을 얻기 위한 기반이 되었다.
일단 script들을 이용해 그녀와의 자연스러운 drink shell을 얻었다.

이제부터는 local exploit을 위한 vulnerability를 찾아야한다.
일단 그녀에게는 alcoholic drinks overflow vulnerability가 있다는것을 알게 되었다.
게다가 그녀는 religion string bug가 있는것으로 판명났다.
일단 안타깝게도 첫번째 vulnerability에서는 egg hunter들인 술먹으면 데려다주는 친구들이 있는것으로 판명났다.
그리고 단둘이 있을때는 1 cup overflow밖에 일어나지 않는다는 것을 알았다.
그리고 religion string bug인 교회에서는 L.O.V.E로 인한 one night stand가 힘들다는것을 알게 되었다.

나는 1 cup overflow의 해법을 알고 있었기에 그곳을 공략하기로 마음먹었다.
실전에 들어가기 전에 같은 환경으로 만든 girl에게 실전테스트도 잊지 않았다.
일단 단둘의 drink shell을 빠르게 얻어나간후 1 cup overflow를 일으켰다.
완전한 overflow가 아니기 때문에 조심스럽게 내가 원하는 place로 return 시키기 위해 유도했다.
결국 그녀는 내가 원하는 곳으로 return 했고 나는 local root를 딸수 있게 되었다.
물론 root를 딴 후에는 내 흔적을 지우기 위해 그녀의 cel-Phone의 log를 delete하였다.
그녀는 뒤늦게 내 주변의 모든 marks가 spoofing된 것임을 알수 있어지만 이미 폭풍은 지나가고 난 후였다.

writed by ganseo.

ㅎㅎ
posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of http://blog.badung.org BlogIcon badung

    이러고 싶어? ㅋㅋ

    2007.07.24 23:24

Skills/Drill or Guard 2007. 7. 21. 02:41
워낙 오랜만에 이런짓 하다보니...감이 안잡히네..

레벨 3까진 뭐...해커라기보단 시스템어드미니스트레이터나 시스템엔지니어쪽

문제였던듯 하고..

오늘 딱 5번까지 보고 자자...

서버 너무 느리고 공격받는지 자꾸 끊어져서 오늘은 포기하려고 생각중...
posted by mirr

댓글을 달아 주세요