นักวิจัยพบข้อบกพร่องในเว็บไซต์ a16z ที่ทำให้ข้อมูลบางส่วนของบริษัทถูกเปิดเผย

 (kibty.town)
1 คะแนน โดย GN⁺ 2024-07-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยด้านความปลอดภัยรายหนึ่งพบว่าในซับโดเมนที่เกี่ยวข้องกับ a16z คือ portfolio.a16z.com มี process.env ทั้งหมด ของอินสแตนซ์ Heroku ถูกฝังแบบไดนามิกอยู่ใน JavaScript
  • ค่าที่ถูกเปิดเผยมี ข้อมูลประจำตัวของบริการ หลายรายการ เช่น DATABASE_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, MAILGUN_API_KEY
  • นักวิจัยระบุว่าระหว่างการตรวจสอบทั่วไปเพื่อหาซีเคร็ตในไฟล์ JS ด้วย lunchcat เขาพบการอ้างอิงถึงคีย์ AWS และสามารถตรวจสอบได้เพียงใช้ แท็บ Sources ในเครื่องมือนักพัฒนาของเบราว์เซอร์
  • ขอบเขตผลกระทบครอบคลุมฐานข้อมูลที่มี PII, AWS, Salesforce และ Mailgun โดยอ้างว่า Mailgun สามารถส่งอีเมลใด ๆ จากโดเมนของ a16z และอ่านอีเมลในอดีตได้
  • a16z ไม่จ่ายบั๊กบาวน์ตี โดยให้เหตุผลว่านักวิจัยพยายามติดต่อแบบสาธารณะ ขณะที่นักวิจัยระบุว่าเว็บไซต์หลักไม่มีช่องทางติดต่อ และอีเมลที่พบก็ถูกตีกลับ

ตัวแปรสภาพแวดล้อมที่ถูกเผยระหว่างตรวจสอบซับโดเมน

  • นักวิจัยระบุว่าเขาหาเป้าหมายด้วยวิธีค้นหาบริษัทบน Twitter แล้วลองทำ penetration test อย่างรวดเร็ว และใช้แท็บ Relevant People อยู่บ่อยครั้ง
    • เส้นทางในครั้งนี้เริ่มจากบริษัทที่เกี่ยวข้องกับ crypto → บริษัทเงินร่วมลงทุนด้านคริปโต → a16z crypto → a16z
  • ระหว่างการตรวจสอบ a16z เขาทำ การสแกนซับโดเมน แบบทั่วไป และใช้เครื่องมือ lunchcat เพื่อตรวจสอบโดเมนและค้นหาซีเคร็ตในไฟล์ JS
  • portfolio.a16z.com ดูเหมือนเป็น เครื่องมือจัดการพอร์ตโฟลิโอ สำหรับบริษัทที่อยู่ในเครือ a16z และระหว่างตรวจสอบพบการอ้างอิงถึงคีย์ AWS จากที่ใดที่หนึ่งในเว็บไซต์
  • ภายใน JS มีค่าที่ดูเหมือนเป็น process.env ทั้งหมดของอินสแตนซ์ Heroku ถูกใส่เข้ามาแบบไดนามิก
    • รายการที่รวมอยู่มี MARKETPLACE_URL, DATABASE_URL, SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, SESSION_SECRET, MAILGUN_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, COOKIE_SECRET, HEROKU_POSTGRESQL_CRIMSON_URL เป็นต้น
    • นักวิจัยตรวจสอบข้อมูลประจำตัวอย่างรวดเร็วและระบุว่า ดูเหมือนเป็นข้อมูลประจำตัวจริง ไม่ใช่ของปลอม
    • เขาอธิบายว่าระดับการเข้าถึงคือแค่เปิด แท็บ Sources ในเครื่องมือนักพัฒนาของเบราว์เซอร์

ขอบเขตที่อาจถูกเปิดเผยและข้อถกเถียงเรื่องบั๊กบาวน์ตี

  • บริการที่นักวิจัยระบุว่าอาจถูกละเมิดมีดังนี้
    • ฐานข้อมูล: ระบุว่ามี PII อยู่ภายใน
    • AWS: มีการกล่าวถึงความเป็นไปได้ในการเข้าถึงผ่านคีย์ที่ถูกเปิดเผย
    • Salesforce: ไม่ได้ตรวจสอบโดยตรง และเสริมว่าสิทธิ์ของบัญชีอาจมีข้อจำกัด
    • Mailgun: ระบุว่าสามารถส่งอีเมลใด ๆ จากโดเมนของ a16z และอ่านอีเมลในอดีตได้
    • ยังกล่าวถึงความเป็นไปได้ว่ามีบริการอื่น ๆ อีก
  • a16z ไม่จ่ายบั๊กบาวน์ตี โดยให้เหตุผลว่านักวิจัยไม่ได้ติดต่อแบบส่วนตัว แต่พยายามติดต่อแบบสาธารณะ
  • นักวิจัยให้เหตุผลสองข้อว่าทำไมจึงติดต่อแบบสาธารณะ
    • ไม่พบช่องทางติดต่อที่ใช้งานได้บนเว็บไซต์หลักของ a16z
    • อีเมลที่ส่งไปยังที่อยู่อีเมลที่หาได้ถูกตีกลับ
  • มีการแนบบทความที่เกี่ยวข้องคือ บทความของ TechCrunch โดยระบุว่า Lorenzo เห็นทวีตที่นักวิจัยโพสต์เพื่อพยายามติดต่อ a16z จึงติดต่อกลับและเขียนบทความนี้

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

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

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

  • ตอนที่เราเปิดตัว โปรเจกต์โอเพนซอร์ส ของเรา (https://github.com/heyPuter/puter/) Eva ได้ช่วยทำ penetration test ให้อย่างค่อนข้างกว้างขวาง และจัดการรายงานช่องโหว่ได้อย่างมืออาชีพมาก
    ตอนนั้นเรายังไม่มีโปรแกรม bug bounty ด้วยซ้ำ แต่เธอก็ไม่ได้เรียกร้องค่าตอบแทน Eva เป็นแฮกเกอร์ที่ทั้งเก่งและมีความรับผิดชอบ ดังนั้น a16z ควรปฏิบัติกับเธอให้ดีกว่านี้

  • ผมเคยทำพลาดคล้าย ๆ กัน
    เราใช้ Node.js CMS ชื่อ apostrophecms และใช้แผงผู้ดูแลระบบที่เรียกว่า global settings สำหรับจัดการ API key ของเซิร์ฟเวอร์ยืนยันตัวตน แต่ผ่านไปหลายเดือนถึงได้รู้ว่าค่านั้นถูกพิมพ์ออกมาใน ซอร์สโค้ด HTML
    เขาทำมาแบบนั้นเพื่อให้ใช้งานจาก JavaScript ได้ และก็มีระบุไว้ในเอกสารด้วย เลยไม่ได้โทษฝั่งนั้น แต่เป็นเราที่อ่านข้าม ๆ เอง
    ที่น่าหงุดหงิดกว่านั้นคือเราเคยจ่ายเงินไม่น้อยให้บริษัทที่ปรึกษารายใหญ่ทำ penetration test แล้ว แต่พวกเขาก็จับไม่ได้ สุดท้ายเราพบเอง พอตรวจ log ก็ไม่เห็นร่องรอยการถูกใช้ในทางที่ผิด แต่ก็ถือเป็นการรั่วไหลที่ชวนช็อกทีเดียว

    • penetration test อันนั้นอย่างน้อยก็น่าจะเรียก เงินคืน ได้
      penetration test ที่ผมเคยเห็นมาจนถึงตอนนี้ ไม่เคยเกินกว่าการติ๊กเช็กลิสต์เลย
    • เสียใจจริง ๆ ที่คุณเจอการเปิดเผยข้อมูลโดยไม่คาดคิดระหว่างใช้ ApostropheCMS
      อย่างที่คุณบอก วิธีแชร์ข้อมูลแบบนี้มีเขียนไว้ในเอกสาร แต่ก็ยังอาจทำให้ตกใจได้
      ขอเสริมไว้สำหรับคนที่จะค้นคว้าต่อว่า เวอร์ชันหลักของ Apostrophe ที่ยังรองรับอยู่ในปัจจุบันไม่ได้ทำงานแบบนี้อีกแล้ว
      การฝังข้อมูลเข้าไปใน frontend สำหรับผู้ใช้ที่ล็อกเอาต์อยู่ต้องเป็นสิ่งที่นักพัฒนาตั้งใจเลือกเอง และเราเปลี่ยนไปแบบนั้นเพื่อหลีกเลี่ยงความประหลาดใจแบบนี้
      อย่างไรก็ตาม ยังมี use case ที่ต้องใส่ API key เป็นส่วนหนึ่งของการตั้งค่าและคอนเทนต์ของวิดเจ็ตบางตัวอยู่
      หมายเหตุ ผมเป็นหัวหน้าฝ่ายออกแบบของ Apostrophe และก็มีบทบาทด้านวิศวกรรมด้วย
    • สงสัยว่าทำไมถึงใช้ ระบบจัดการเนื้อหา บนเว็บมาจัดการค่าลับ
    • แก้ไข: ไม่ได้ตั้งใจจะโทษ apostrophe cms
      สถานการณ์นี้เกิดจาก การตั้งค่าแบบ multi-tenant ของเราและความเข้าใจ apostrophe ไม่เพียงพอ
    • คุณบอกว่า “มีอยู่ในเอกสารแล้ว เลยไม่โทษเขา เป็นเราที่อ่านข้ามเอง” แต่ถึงอย่างนั้นก็ควรโทษพวกเขาอยู่ดี
      การทำพฤติกรรมที่อันตรายแล้วเขียนไว้ในเอกสารไม่ได้ทำให้พ้นความรับผิด และผมคิดว่าบทเรียนนี้ควรเป็นที่รู้กันอย่างแพร่หลายแล้ว

  • พอสร้างบริการใหม่แล้วติดใบรับรอง LetsEncrypt ให้เซิร์ฟเวอร์ด้วย ACME ไม่นาน log ก็เต็มไปด้วย request ขยะทันที
    เห็นชัดเลยว่ามีบอตที่มองหาค่าเริ่มต้นหละหลวม ๆ ที่นักพัฒนาอาจเปิดทิ้งไว้ และผมยังเคยเห็นบอตขอไฟล์ environment ของโปรเซสด้วยซ้ำ
    ไม่รู้ว่าช่องโหว่แบบนี้ไม่ถูกพบหรือถูกใช้ได้อย่างไร บางที a16z อาจโชคดีมาก หรืออาจถูกใช้ไปแล้วแต่ยังไม่เปิดเผยก็ได้
    เท่ากับว่านักวิจัยเจตนาดีหรือคนว่าง ๆ ที่มี mindset แบบ white hat ติดต่อไปก่อน น่าเสียดายที่ไม่มีกรอบกฎหมายสำหรับความสะเพร่าแบบนี้ แต่ผมคิดว่า a16z ควรถูกปรับหนัก

    • “ช่องโหว่แบบนี้ไม่ถูกพบหรือถูกใช้ได้อย่างไร?”
      บางทีมันอาจเกิดขึ้นแล้วก็ได้
      การปล่อยให้มันเปิดอยู่ต่อไปอาจมีค่ามากกว่าการทำลายทิ้งเฉย ๆ
    • ถ้าพูดอย่างเป็นธรรม ตัวเว็บหลักเองก็ไม่ได้ดูน่าสนใจขนาดนั้น
      แต่ ข้อมูลรับรองอย่าง OKTA บางตัวดูอันตรายมากทีเดียว

  • ส่วนที่ว่า “ไม่ได้ให้ bug bounty เพราะติดต่อมาแบบสาธารณะ เหตุผลที่ทำแบบนั้นคือเว็บหลักไม่มีช่องทางติดต่อ และ engineering@a16z.com ที่เจอก็เด้งกลับ” ดูเหมือน life hack อันชาญฉลาดเพื่อประหยัดเงินบริษัท
    ถ้าไม่มีวิธีติดต่อทีมวิศวกรรมแบบส่วนตัว รายงาน bug bounty ทั้งหมดก็จะต้องทำแบบสาธารณะ แล้วก็ไม่ต้องจ่ายอะไรเลย

    • ฉลาดในหลายแง่เลยนะ
      งานพัฒนาก็น่าจะประหยัดได้เยอะด้วยการกดราคาคนจากที่อย่าง fiverr และถ้ากลุ่ม ransomware รัสเซียเจาะไปได้ง่าย ๆ ก็อาจช่วยประหยัดต้นทุนบัญชีทางอ้อมได้มากเหมือนกัน
    • แต่ครั้งหน้าก็เท่ากับสอนนักวิจัยความปลอดภัยให้ เอาข้อมูลนั้นไปขายแทนที่จะรายงาน
    • บริษัทไม่จำเป็นต้องมี “แฮ็ก” แยกต่างหากเพื่อเลี่ยงจ่ายเงิน
      ถ้าไม่มีโปรแกรม bug bounty สาธารณะ ก็ไม่ได้ติดหนี้อะไร
      อีกอย่างที่ด้านล่างของ https://a16z.com/connect ก็มีอีเมลติดต่ออยู่ แต่นักวิจัยบังเอิญพลาดไปอย่างสะดวกพอดี
      ดูเหมือนตั้งใจหาความ เป็นที่รู้จัก มากกว่าการเปิดเผยอย่างรับผิดชอบ
    • ถ้าเรื่องแบบนี้เกิดซ้ำ ๆ ก็จะถูกมองว่าเป็นที่ที่ไม่จ่าย bounty และโอกาสที่คนจะรายงานปัญหาที่พบก็จะลดลง
    • ถ้าไปโพสต์ใน HN ถามหาวิธีติดต่อฝ่ายวิศวกรรมของ a16z ก็น่าจะได้ผลพอสมควร

  • เวลาองค์กรต่าง ๆ พูดว่า “ถูกแฮ็ก” ตอนนี้ฟังเหมือน สำนวนองค์กร ที่แปลว่า “เราไม่ได้ปกป้องข้อมูลรับรองสำคัญให้ดี แต่ช่วยโยนความผิดให้ตัวตนนิรนามที่เราเรียกว่า ‘แฮกเกอร์’ หน่อย”

    • ถ้าคุณเผลอเปิดประตูหน้าบ้านทิ้งไว้กว้าง ๆ แล้วมีคนมาขโมยของไปหมด คุณก็ยังจะพูดว่า “ถูกขโมย” อยู่ดี
      มันมีการแบ่งแยกทางกฎหมายอย่าง “บุกรุกเคหสถาน”, “ลักทรัพย์”, “บุกรุกโดยไม่ได้รับอนุญาต” และการที่ประตูเปิดอยู่หรือไม่อาจมีผลต่อความผิดหรือโทษ แต่ในภาษาพูดทั่วไปก็ยังถือว่าถูกขโมยอยู่ดี

  • ช่องโหว่ที่เปิดกว้างขนาดนี้ แต่ไม่ให้ bounty แม้แต่ จำนวนเชิงสัญลักษณ์ ก็ถือว่าแย่มาก

    • ครั้งหน้าถ้ามีใครเจอ key ของพวกเขา อาจเห็นบทความนี้แล้วเอาไปใส่ใน GitHub repository สาธารณะแทนการรายงานก็ได้

  • พวกเขาคงยุ่งอยู่กับการเขียน whitepaper เรื่อง สถาปัตยกรรม generative AI ขนาดมหึมา
    ปล่อยให้พักหน่อยเถอะ พวกเขากำลังฝันถึงโลก agent แห่งอนาคตที่ขับเคลื่อนด้วย chatbot ครึ่ง ๆ กลาง ๆ
    ขณะที่โลกกำลังลุกไหม้เพราะอัปเดตซอฟต์แวร์ที่พัง

    • โลกกำลังลุกไหม้อยู่แล้วจากผลกระทบของ การเปลี่ยนแปลงสภาพภูมิอากาศ
      อัปเดตซอฟต์แวร์ที่พังเมื่อวันศุกร์ก็แค่เป็นการเติมเชื้อไฟปิดท้ายเท่านั้น
    • “engineering@a16z.com เด้งกลับ”
      ไม่แปลกใจเลยสักนิด

  • ถ้าเข้าถึง Salesforce instance ได้จริง ๆ ในมุมผู้ก่อตั้งคงน่ากังวลมาก
    โดยปกติที่อย่าง Salesforce จะมีอีเมลถูกบันทึกไว้ และในนั้นอาจยังมี แผนระดมทุน หรือแผน M&A ที่ผู้ก่อตั้งบริษัทในพอร์ตไม่ได้แชร์กับภายนอกค้างอยู่ตลอด

    • การเก็บ key จากซอร์สโค้ดสาธารณะของหน้าเว็บเป็นสิ่งถูกกฎหมายและสามารถรายงานได้อย่างปลอดภัย
      แต่การใช้ key นั้นเข้าถึงระบบที่ไม่มีสิทธิ์เป็นอาชญากรรม
      ความต่างนี้ใหญ่มาก
    • ถ้ามีข้อมูล LP อยู่ด้วย นั่นก็อาจเป็นความเสียหายค่อนข้างใหญ่เหมือนกัน

  • ความจริงที่ว่า VC รายนี้ไม่จ่าย bug bounty สำหรับ ช่องโหว่ด้านความปลอดภัยขนาดใหญ่ แบบนี้ไม่ได้สร้างความน่าเชื่อถือเลย

    • ถ้าดูว่าผู้ร่วมก่อตั้งตอนนี้เป็นผู้สนับสนุน Trump ก็ไม่น่าแปลกใจ: https://siliconangle.com/2024/07/17/co-founders-andreessen-h...
    • ถ้ายังทำเว็บดี ๆ ไม่ได้ แล้วมันบอกอะไรเกี่ยวกับความสามารถในการจัดสรรเงินทุนกันล่ะ?

  • ทีมดูแล HN เปลี่ยนชื่อเรื่องให้ดูน่าอายน้อยลงแล้วสินะ
    ไม่แปลกใจเลย

    • คอมเมนต์ของผมก็คงวิจารณ์ a16z แรงเกินไปเหมือนกัน
      คะแนนไม่เปลี่ยน แต่ถูกย้ายจากบนสุดไปล่างสุด
      วิธีตอบสนองนี่มีหลายแบบจริง ๆ