ภัยจาก “Social engineering” จากกรณีถูกแฮกเข้า Internet Banking

จากเรื่อง เตือนภัย K-Mobile Banking ถูก hack ครับ นั้น เอาจริงๆ จากในกระทู้ เป็นการถูกโจมตีในรูปแบบของ Social engineering (วิศวกรรมสังคม) เป็นหลัก คือใช้ข้อมูลส่วนตัวของผู้ใช้ท่านนั้นๆ ในการขอยกเลิก หรือแก้ไขข้อมูลผ่าน Call Center ซึ่งต้องมีข้อมูลอยู่พอสมควร พูดง่ายๆ คือถูกติดตามพฤติกรรมอยู่สักพัก หรือได้รับข้อมูลส่วนตัวที่สำคัญมากพอที่จะทำแบบนี้ ถ้าใครนึกภาพไม่ออก อ่านต่อที่ ทวิตเตอร์ Gizmodo ถูกแฮกเพราะช่องโหว่วิศวกรรมสังคมของ iCloud และ นักข่าว Gizmodo โดนขโมยบัญชี iCloud ไปได้อย่างไร ได้ เป็นรูปแบบเดียวกัน ซึ่งเป็นข่าวที่ “นักข่าว Gizmodo ถูกแฮกเพราะช่องโหว่วิศวกรรมสังคมของ iCloud” และสุดท้าย “โดน remote wipe จาก iCloud อีกต่อหนึ่งโดยใช้ช่องโหว่นี้ผ่านทาง Apple” เช่นกัน สรุปคือโดนกันหน้าแหละครับ

รูปแบบช่องโหว่นี้เกิดจาก “ความง่าย” ที่ต้องการให้ผู้ใช้งานทั่วไป “สะดวกสบาย” แน่นอนว่าผู้ใช้งานทั่วไปคงชอบ เพราะไม่เรื่องมาก แต่นั้นหมายถึงการนำมาซึ่ง “หายนะ” ได้ง่ายมากขึ้น ผู้ใช้งานควรศึกษา ทำความเข้าใจ และหวงแหน ข้อมูลส่วนตัวเช่น วัน-เดือน-ปีที่เกิด หมายเลขโทรศัพท์บ้าน ที่อยู่ปัจจุบัน หมายเลขบัตรประจำตัวประชาชน เป็นต้น เพราะถ้าใครติดต่อทำธุรกรรมผ่าน Call Center บ่อยๆ จะทราบว่า มันคือข้อมูลที่ใช้ในการระบุและสามารถเปลี่ยนแปลงข้อมูลทำธุรกรรมกับ ทางบริษัทต่างๆ ผ่าน Call Center ได้ เพราะฉะนั้น ข้อมูลพวกนี้ไม่แนะนำให้เปิดเผยเป็นปรกติบน Social Network ใดๆ เพื่อป้องกันการถูกนำไปใช้เพื่อการนี้

ในส่วนของ K-Bank ก็มีปัญหาเรื่องการระบุตัวตนตรงนี้เช่นกัน คงต้องมีการปรับปรุงส่วนนี้เพื่อให้รัดกุมมากขึ้น เช่นการเปลี่ยนแปลงหมายเลขโทรศัพท์สำหรับ OTP ต้องใช้เอกสารในการทำเท่านั้นเป็นต้น (เห็นว่าจริงๆ ต้องมีเอกสาร แต่ไม่รู้เคสนี้หลุดไปได้อย่างไร)

สำหรับคนทีใช้ Internet Banking ต่างๆ ควรศึกษาข้อมูลด้านความปลอดภัยในเครื่องคอมพิวเตอร์และมือถือให้มากพอ การใช้งานซอฟต์แวร์ที่อาจนำมาซึ่ง Key logger และ Malware ควรหลีกเลี่ยงการใช้งาน รวมไปถึงคอมพิวเตอร์ที่ไม่สามารถควบคุมการติดตั้ง หรือทราบแน่ชัดว่ามีอะไรติดตั้งอยู่บ้าง ควรหลีกเลี่ยง เวลาใช้อะไรเกี่ยวกับการเงิน ควรศึกษาเรื่องเหล่านี้ไว้ให้มากที่สุดครับ

ข้อคิดบางอย่างที่ได้หลังจากเหตุการณ์ Drupal.org ถูกแฮก

จาก

Important Security Update: Reset Your Drupal.org Password

Drupal.org ถูกแฮก รีเซ็ตรหัสผ่านผู้ใช้ทุกคน

เหตุการณ์ที่ Drupal.org ถูกแฮกนั้น เกิดจากเครื่องมือของผู้ให้บริการระบบที่ Drupal.org ที่ใช้บริการอยู่นั้นมีช่องโหว่ ทำให้ผู้เจาะระบบสามารถเข้าถึงฐานข้อมูลได้ โดยปัญหาที่เกิดขึ้นนี้ไม่ใช่ช่องโหว่ของ Drupal โดยตรงแต่อย่างใด ผู้ใช้งาน Drupal อยู่ตอนนี้สบายใจได้ (แต่ยังแนะนำให้ upgrade ตัว Drupal 7 ให้ไปใช้ Drupal 7.22 ซึ่งเป็นตัวล่าสุด)

สำหรับคนที่เป็นสมาชิก Drupal.org แบบผม ถึงแม้จะเอาข้อมูลผู้ใช้งานไปได้ แต่รหัสผ่านที่บันทึกไว้นั้นยังถูกนำไปผ่านกรรมวิธี hash และใช้ salt ร่วมด้วยเพื่อให้ได้ชุดข้อมูลเชิงเปรียบเทียบทางเดียว (ไม่สามารถแปลงกลับเป็นรหัสผ่านจริงๆ ได้อีก) แต่ก็มีรหัสผ่านบางส่วน (ที่เก่ามากๆ) มีแต่ hash อย่างเดียว (เป็นส่วนน้อย) จึงยังคงมีความปลอดภัยอยู่

แต่ทาง Drupal.org ยังแนะนำให้เข้าไปตั้งรหัสผ่านใหม่ เพื่อทำการสร้างชุด hash และ salt ใหม่อีกครั้งเพื่อความปลอดภัยและเพื่อป้องกันการใช้ชุดข้อมูลรหัสผ่านที่ถูกขโมยไปแล้ว ถูกนำไปผ่านกรรมวิธี rainbow hash cracking หรือการนำรหัสผ่านที่ได้จาก hash function ที่ยอดนิยมอย่าง md5 หรือ sha1 มาเปรียบเทียบกับ rainbow table แล้วย้อนกลับเป็นรหัสผ่านจริงๆ ได้อีกครั้ง โดยมักจะมีปัญหากับการใช้ hash กับรหัสผ่านโดยไม่มี salt มาช่วยในการ hash ตัวรหัสผ่านอีกรอบ

เหตุการณ์นี้ทำให้รู้ว่าบางครั้งระบบเราทำงานได้ดี และไม่มีช่องโหว่ใหญ่ๆ หรือแม้แต่เป็นช่องโหว่ที่ยังไม่เปิดเผยจนมีผลกระทบ แต่ก็ไม่สามารถรอดจากการถูกแฮกได้ ถ้าระบบที่ล้อมรอบหรือควบคุมระบบของเราชั้นนอกนั้น ดันมีช่องโหว่ที่สามารถเข้ามาผ่านทางช่องทางที่ไม่ปรกติได้ และช่องโหว่นั้นดันทำให้เกิดการเข้าถึงระบบของเราโดยไม่ผ่านระบบยืนยันตัวตน ซึ่งในไทยเราเจอบ่อยมากๆ ที่ระบบในส่วนของตัวเว็บไม่มีช่องโหว่ แต่ตัวระบบจัดการหลักของเว็บ หรือ Control Panel มีช่องโหว่ ก็เลยทำให้ระบบทั้งหมดอยู่บนความไม่ปลอดภัยไปด้วย

ลองเล่นๆ แงะ Backup ของ iOS 4 เพื่อดึงการเก็บข้อมูลพิกัดของผู้ใช้งาน

จากข่าว iOS 4 เก็บข้อมูลพิกัดทุกคนไว้โดยตั้งใจ ก็เลยรู้สึกคันไม้คันมือลองของ เนื้อหาตอนนี้เขียนขึ้นเพื่อเตือนและให้ระมัดระวังตัว เพราะฉะนั้นหวังว่าจะมีประโยชน์กับคนที่อ่าน แน่นอน อุปกรณ์และตัวอย่างทั้งหมด ไม่ได้ jailbreak หรือ hack/crack แต่อย่างใด เพราะส่วนตัวแล้วนั้นผมใช้ iPod Touch 4 อยู่แล้ว และไม่ได้ jailbreak ใดๆ Apps ทุกตัวซื้อทั้งหมด และใช้งานตาม EULA ของ Apple ซึ่งตัว iOS ที่ใช้ก็ือ 4.3.2 ตัวล่าสุด! แน่นอนว่ามันมีข่าว ผมก็ต้องจัดสักหน่อย ดูว่าเป็นอย่างที่เค้าว่ากันว่าไหม

จากแหล่งข้อมูลอ้างอิง ผมใช้ข้อมูลตัวอย่างจากการ Backup เป็นหลักแล้วกัน ถ้าจะให้เข้าไปเอาจากในเครื่องเลย ดูจะเสียเวลาและดูยุ่งยาก ซึ่งแน่นอนว่าเป็นข้อมูลที่เข้าถึงง่ายที่สุดและไม่ได้อยู่ติดตัวผู้ใช้ตลอด ทำให้โดนเอาไปใช้งานได้ทันที!!!! รหัสผ่านไม่ต้องกรอก แต่สามารถเข้าถึงเครื่องที่ iPhone/iPod Touch รุ่นนั้นๆ เคย Sync ไว้กับเครื่องของไว้ ก็จะสามารถนำข้อมูลส่วนนี้และนำไปใช้งานได้ทันที

เพราะฉะนั้นถ้าคิดว่าเอาไปให้ร้านมือถือ upgrade ให้ก็จงระวังให้หนักสำหรับเรื่องตรงนี้ครับ โดยเฉพาะคุณผู้หญิงทั้งหลาย เพราะมันลากไส้มาตั้งแต่คุณ activate เครื่องในการซื้อครั้งแรกเลย เพราะงั้น ถ้าเราเอาข้อมูลพวกนี้มาทำสถิติก็จะพอบอกได้ว่าบ้านและสถานที่ที่ไปบ่อยๆ นั้นอยู่ที่ไหนบ้าง

เรามาเริ่มกันเลย การเข้าถึงแหล่งข้อมูล Backup นั้นผมอ้างอิง path ของระบบผ่าน Microsoft Windows 7

C:\Users\[Windows's User Name]\AppData\Roaming\Apple Computer\MobileSync\Backup\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-yyyymmdd-hhmmss

[Windows’s User Name]
ชื่อ User Name ของ Windows ที่ใช้งานอยู่

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
คือรหัส 40 ตัวอักษรที่ hash ไว้

yyyymmdd-hhmmss
วันและเวลาที่ backup

ใน directory ปลายทาง หาไฟล์ที่ชื่อ

4096c9ec676f2847dc283405900e284a7c815836
เป็นไฟล์ฐานข้อมูลของ SQLite และ “ไม่ได้เข้ารหัส”

ใช้ SQLite Manager ที่เป็น Extension ของ Mozilla Firefox เปิดเอาก็ได้แบบนี้!

Table ในฐานข้อมูลที่ต้องสนใจคือ CellLocation และ WifiLocation ครับ

จะได้ข้อมูลเวลา สถานที่ที่เป็น lat/long ชัดเจนมาก โชคดีที่ผมใช้เป็น Wifi แต่ถ้าเป็นมือถืออย่าง iPhone ก็จะอยู่ที่ CellLocation โครงสร้างก็ไม่แตกต่างกันครับ เอาข้อมูลไป lat/long ไปค้นหาใน Google Maps ได้ทันที จะเขียนโปรแกรม ฯลฯ ก็น่าจะยากสำหรับคนที่ต้องการติดตามตัวครับ!!!

เนื้อหาตอนนี้เป็นการตีแผ่และหวังว่าในอนาคต Apple จะปรับปรุงการเก็บข้อมูลส่วนนี้ให้มีความปลอดภัยมากขึ้น และแจ้งผู้ใช้งานก่อนไม่ใช่อยากจะเก็บก็เก็บโดยไม่ได้บอกผู้ใช้ก่อนแบบนี้

ปล. เนื้อหาบทความนี้อาจจะอายุไม่ยืน ถ้ามีการแจ้งให้ลบบทความจากหน่วยราชการคงต้องลบนะครับ ;P

อ้างอิงจาก http://petewarden.github.com/iPhoneTracker/

หมายเหตุ : วิธีนี้จะใช้ได้ผลใน iOS รุ่นที่ต่ำกว่า iOS 4.3.3 ลงมา

อันตราย blockcheckerim.com

พอดีว่าเพื่อนผมแนะนำมา เลยเข้าไปดูในเว็บมีรายละเอียดให้กรอก username/password ด้วย ซึ่งโคตรจะอันตรายเลย และมาแนวเดียวกับเว็บหลอกลวงให้กรอกหมายเลขบัตรเครดิตต่าง ๆ ซึ่งลองเข้าไปหาข้อมูลก็ได้พบที่ ชานชาลาแห่งการเรียนรู้ เลยขอ copy มาใส่ที่นี่แล้วกัน ผมจะได้ไม่ตองให้ข้อมูลใหม่ เพราะใน ชานชาลาแห่งการเรียนรู้ ของ Blogger ท่านนี้ก็อธิบายไว้ดีอยู่ครับผม และถ้าใครหลงทำไปแล้ว รีบเปลี่ยน password โดยด่วนครับ ไม่งั้น account ท่านอาจจะโดน hack หรือโดยล่วงลูกได้ง่าย ๆ ครับ

อย่าคลิ๊ก www . blockcheckerim . com

วันนี้ได้รับข้อความจากเพื่อนคนหนึ่งให้คลิ๊กไปที่เว็บ www . blockcheckerim . com พอเข้าไปอ่านปรากฏว่าเป็นเว็บที่เช็คว่าใคร block หรือ delete เราจาก contact บ้าง โดยมันให้กรอก username / password

อ่านดูแล้วไม่กรอก เพราะเหตุผล 2 อย่าง

1. ดูแล้วไม่น่าไว้ใจ เว็บมันดูไร้หัวนอนปลายเท้า (555) แถมเข้าไปอ่านใน agreement (ทำเนียนนะมี agreement ด้วย) มันดันให้ติดต่อกลับ blockcheckerim@gmail.com ซะงั้น โดเมนตัวเองมีแต่ไม่มีปัญญาสร้างเมล์ใช้เอง

2. ไม่เคยสงสัยว่าใครจะ block หรือ delete (สงสัยไปทำไมเนี๊ยะ) ใครไม่คุยนานๆ หรือไม่รู้จักก็จะลบออกจาก contact list อยู่แล้ว ส่วนใหญ่จะทำกับคนอื่นว่างั้น หุหุ ส่วนใครจะไม่คุยกะเราบอกว่าไม่ต้องบล็อก เพราะไม่สน ไม่มีทางส่งอะไรไปกวน 5555

ต่อมาได้โทรไปคุยกับเพื่อนคนที่ส่งมา ปรากฏเค้าบอกไม่ได้ส่งอะไรมา เลยสันนิษฐานได้ว่าในเครื่องคงมีเวิร์มแล้วแน่ๆ มันถึงส่งข้อความนี้มาให้โดยเจ้าของเครื่องไม่รู้

ดังนั้นคนที่ไม่เคยคลิ๊กก็ไม่ต้องคลิ๊ก และห้ามกรอก username/password โดยเด็ดขาด ถ้ากรอกไปแล้วยังพอมีเวลาให้รีบเข้าไปเปลี่ยน password โดยด่วน ไม่งั้นอีเมล์ของท่านหรือ msn ของท่านอาจถูกใช้เป็นเครื่องมือในการหลอกลวงผู้อื่นต่อไป

โปรดระวังด้วยนะครับ เรื่องพวกนี้สำคัญมาก  ๆ ครับผม

เขียน รับ get / post ใน form method ระวังโดน hack หรือเป็นรูโหว่

นี่เป็นปัญหามาก ในเป็นการสร้างนิสัยเสียในการเขียนโปรแกรมในภาษา PHP ในเรื่องการที่คนเขียน นิสัยเสีย หรือติดจากหนังสือบางเล่ม ที่ไม่ค่อยใช้ GET หรือ POST ในการรับค่าจาก form ต่างๆ ใน method ต่างๆ มันยังผลไปสู่การ Hack หรือการเจาะได้ เช่น เมื่อเร็วๆ นี้ ทำ script PHP สำหรับการ vote freshy boys/girls ที่ ม. ที่ผมเรียนอยู่ ผมหล่ะปวดกับการหล่ะหลวม ของตัวผมเองในการเขียน script ระบบ vote อย่างแรง ตัว form คือ
[HTML]





[/HTML]
ตัวอย่างด้านล่าง มีช่องโหว่ครับ เพราะว่าในระบบ จะรับ แค่ poll_id เท่านั้นส่วน vote_for และ action ไม่ได้ทำการกรอง อ่าน POST หรือ GET แต่ประการใด จากด้านล่าง
[PHP]
$poll_id = $_POST[“poll_id”];
require (“poll/poll_cookie.php”);
include(“poll/booth_inc.php”);
[/PHP]
ทำให้เกิด !!!!
[CODE]


<body> </body>
[/CODE]
เห็นไหมคืออะไร เค้ายิงผ่าน GET Method แทนครับ อ่านหมด 3 ตัวแปรเลย เพราะอะไร ? อย่างแรกครับ $poll_id = $_POST[“poll_id”]; ไม่พอต่อการดัก method จาก GET แต่อย่างใด เพราะว่ายังไง ตัวแปรใน poll_id ที่อยู่ใน form มันก็ยังมาใส่ใน $poll_id ได้จาก GET Method ที่ไม่ได้ lock ซึ่งเช่นเดียวกับ vote_for เช่นกัน ที่มันก็ไปใส่ใน $vote_for ใน script ด้วยเช่นกัน ทำให้เกิดการตั้งเวลาการ vote ได้โดยที่คน vote ไม่ต้องอยู่ที่เครื่อง แค่เปิด browser page นี้ไว้ เท่านั้นเอง แถมถ้าเปิดไว้สัก 100 เครื่องนี่มหาศาลมากทีเดียว ผมเลยต้องกลับลำ และแ้ก้ระบบ script ใหม่หมดอีกครั้งโดยดัก 2 ตัวพอ เพราะว่า action อันนี้ไม่ค่อยสำคัญเท่า vote_for กับ poll_id ที่เป็นตัวจักรสำคัญ แก้คือ ดักทั้ง GET และ POST เราต้องการให้ Method ไหนเข้ามาก็ให้มันผ่านไปเท่าที่เราต้องการเท่านั้น
[PHP]
if(empty($_POST[“poll_id”])) {
$poll_id = $_GET[“poll_id”];
}
else {
$poll_id = $_POST[“poll_id”];
}
if(!empty($_GET[“vote_for”]) or !empty($vote_for)) {
header(“Location: index.php”);
exit;
}
else {
$vote_for = $_POST[“vote_for”];
}
require (“poll/poll_cookie.php”);
include(“poll/booth_inc.php”);
[/PHP]

ผมเลยดักด้วยการรับค่า poll_id จากทั้ง GET และ POST Method ทั้งหมดด้วยการดักไว้ก่อน ตามด้วย Condition ตรวจสอบ ว่าต้องไม่มีการใส่ vote_for ใน GET Method หรือ มีการลักลอบใส่ผ่าน $vote_for มาแต่อย่างใดถ้ามีก็เด้งไป index.php ทันที แต่ถ้าไม่มีก็รับค่าจาก POST มาเลย แล้วทำการ run ตัว script ต่อไปครับ นี่เป็นสิ่งที่รูโหว่ของคนที่ไม่ชอบใช้ POST / GET Method ใน PHP ครับ หรือตั้งชื่อตัวแปรที่มารับ POST / GET Method ที่เหมือนกัน ทางแก้คือ

  1. ใช้ GET / POST Method เสมอๆ ในการรับค่าผ่าน form ต่าง script กัน
  2. ตั้งตัวแปรใน script ที่แตกต่างจาก GET /POST Method เข้าไว้ครับ
  3. ถ้าจำเป็นต้องตั้ง ก็ต้องมี function ในการเช็คตัวแปรที่ส่งผ่านเข้าออก script ให้มากครับ
  4. ใช้ function / class มาแก้ปัญหานี้ครับ ช่วยได้มาก สำหรับคนที่มีเวลาเขียนโปรแกรม หรือ optimize / debug เยอะๆ ครับ (อันนี้เร่งๆ พอสมควรครับ) อันนี้เป็นสิ่งเตือนในการเขียน script ที่เป็น public ได้มากเลยหล่ะครับ

ซึ่งปัญหานี้เกิดจากการใช้ register_global ใน php ที่ตั้ง enable ไว้นั้นเอง ถ้าปิดไปการใช้ตัวแปรภายใน php script ปลอดภัยมากขึ้น