- Tom McKay แห่ง IT Brew ออกจาก Gizmodo ในปี 2022 และ พรางบัญชี Slack ของตัวเองให้เหมือน Slackbot จนไม่ถูกลบอยู่นานหลายเดือน
- เดิม Slack บล็อกชื่อ “Slackbot” ที่มีการใช้งานอยู่แล้ว แต่ McKay เลี่ยงข้อจำกัดชื่อที่แสดงผลด้วยการใช้ อักขระ Unicode ที่หน้าตาคล้ายกัน
- เขายังเปลี่ยนรูปโปรไฟล์ให้เป็น เวอร์ชันโกรธ ที่คล้ายไอคอน Slackbot จริง ทำให้แอดมินไม่ทันสังเกต Slackbot ซ้ำที่คิ้วต่างกัน
- ระหว่างที่บัญชียังอยู่ McKay สามารถส่ง ข้อความที่ดูเหมือนบอต ให้เพื่อนร่วมงานได้ เช่น “Slackbot fact of the day”
- บางบริษัทอาจมี มาตรการความปลอดภัย เพื่อป้องกันการแกล้งแบบนี้ จึงสำคัญที่จะต้องจัดการบัญชีพนักงานที่ลาออกและตรวจสอบชื่อที่แสดงผล
บัญชี Slack ที่ยังคงอยู่หลังลาออก
- Tom McKay แห่ง IT Brew พรางบัญชี Slack ของตัวเองให้เหมือน Slackbot หลังออกจาก Gizmodo
- McKay แชร์ภาพหน้าจอจากตอนนั้นบน X และยืนยันกับ The Verge ว่าการแกล้งนี้เกิดขึ้นจริง
- บัญชีที่ปลอมตัวนี้ไม่ถูกผู้ดูแลของ Gizmodo ตรวจพบหรือลบออกอยู่นานหลายเดือน
วิธีทำให้ดูเหมือน Slackbot
- Slackbot เป็นบอตคุ้นเคยใน Slack ที่ช่วยเรื่องการแจ้งเตือน การดูรหัสผ่าน Wi‑Fi ของออฟฟิศ และการแจ้งเตือนเมื่อถูกเมนชันในช่องที่ไม่ได้เข้าร่วม
- ตอนลาออก McKay เปลี่ยนรูปโปรไฟล์เดิมของตัวเองเป็น ภาพเวอร์ชันโกรธ ที่คล้ายไอคอน Slackbot จริง
- เขายังพยายามเปลี่ยนชื่อที่แสดงผลเป็น “Slackbot” แต่ Slack ไม่อนุญาตให้เปลี่ยนแบบปกติเพราะเป็นชื่อที่มีการใช้งานอยู่แล้ว
- จากนั้นจึงใช้ อักขระ Unicode ที่คล้ายตัวอักษรปกติเพื่อเลี่ยงข้อจำกัดของชื่อ
- ตัวอย่าง: เปลี่ยน “o” เป็นอักขระ Unicode “о” ที่หน้าตาคล้ายกัน
สิ่งที่ทำได้อยู่นานหลายเดือน
- การเปลี่ยนแปลงนี้ทำให้บัญชี Slack ที่ยังใช้งานอยู่ของ McKay รอดจากการถูกลบ ไปได้หลายเดือน
- ระหว่างที่บัญชียังอยู่ เขาสามารถส่งข้อความให้เพื่อนร่วมงานโดยให้ดูเหมือนข้อความจากบอตได้
- ตัวอย่าง: “Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!”
- Victoria Song ซึ่งเคยทำงานที่ Gizmodo มาก่อน แสดงความเห็นว่าสถานการณ์นี้ไม่น่าแปลกใจนัก
แนวทางป้องกันในแต่ละบริษัท
- ไม่ใช่ทุกบริษัทจะถูกหลอกด้วยวิธีเดียวกัน และบางแห่งมี มาตรการความปลอดภัย เพื่อป้องกันสถานการณ์ลักษณะนี้อยู่แล้ว
- ผู้ดูแลของ Gizmodo อาจคิดว่าบัญชีของ McKay ถูกลบไปแล้ว
- หรืออาจไม่ได้สังเกตละเอียดพอที่จะเห็น Slackbot ซ้ำที่มีคิ้วน่าสงสัย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อดีตพนักงานคนหนึ่งที่เคยรู้จัก เคยสร้าง โปรไฟล์ provisioning สำหรับ dial-up/ISDN ชื่อ
Ringingไว้ในโมดูลควบคุม rack ของโมเด็ม เขาเลี่ยงไม่ไปสร้างบนเซิร์ฟเวอร์ Radius เพราะมันจะโจ่งแจ้งเกินไปถ้าดูหน้าสถานะของ rack โมเด็ม จะเห็นผู้ใช้ที่กำลังเชื่อมต่ออยู่ และมีสถานะ
Ringingอยู่หนึ่งรายการ เหมือนสายโทรศัพท์ที่ยังไม่มีคนรับ แล้วเขาก็ใช้ บริการ ISDN 128Kbit ได้นานกว่าหนึ่งปีโดยไม่ถูกจับได้เลยแน่นอนว่าไม่แนะนำให้ทำแบบนี้ โดยเฉพาะตอนนี้ที่ CFAA บางครั้งถูกตีความไปถึงขั้นครอบคลุมการเปลี่ยนพารามิเตอร์ URL หรือแม้แต่การดีดขี้มูกใส่พรม
ตามกฎหมายรัฐนิวเจอร์ซีย์ หากจะตัดสินว่ามีความผิดฐาน “เข้าถึงโดยไม่ได้รับอนุญาต หรือเข้าถึงเกินสิทธิ์” รัฐต้องพิสูจน์ว่าได้มีการหลบเลี่ยงกำแพงป้องกันที่อิงกับโค้ดหรือรหัสผ่าน และในคดีนั้นใจความคือ เขาเพียงเข้าถึงบางส่วนของหน้าล็อกอินที่เปิดสาธารณะ แล้ว scrape ข้อมูลที่ AT&T เปิดเผยโดยไม่ได้ตั้งใจเท่านั้น
https://law.justia.com/cases/federal/appellate-courts/ca3/13...
Computerแล้วแอบเข้าไปเล่นด้วยนิดหน่อยคนที่สนิทกันน่ะใช่ แต่ไม่ได้เหลือไว้เพราะน้ำใจหรอก เป็นเพราะการจัดการบัญชี Slack กับการเชื่อมต่อกับ Google Office เละเทะต่างหาก
นึกถึงวันอันรุ่งโรจน์ช่วงราวปี 2016 ที่บริษัทที่ปรึกษาแห่งหนึ่ง เราพบว่าสามารถเปลี่ยน ชื่อ Slack ของกันและกันได้ ช่วงหนึ่งชื่อของทุกคนกลายเป็นแค่
dadgrandadไม่งั้นจะปล่อยหลานสาว ๆ เข้ามา พวกนั้นโหดไร้ปรานีทีมฟริสบีมหาวิทยาลัยของเราใช้ Slack อยู่
หลายคนแนะนำให้ใช้วิธีป้องกันการเปลี่ยนชื่อ แต่แค่นั้นไม่ได้แก้ปัญหาได้ทั้งหมด อาจมีคนที่ชื่อจริงว่า Jira อยู่ที่ไหนสักแห่งก็ได้
ที่ $company ที่เคยทำงานด้วยก่อนหน้านี้ เราวางแดชบอร์ดลูกค้าไว้บน https://*.$company.com แบบ wildcard เช่น https://foo.$company.com
แต่ถ้ามีใครเลือก slug ของแดชบอร์ดที่ชนกับเรกคอร์ดจริงอย่าง
wwwหรือblogแดชบอร์ดนั้นจะเข้าถึงไม่ได้เลย การตั้งค่าสำหรับเปลี่ยน prefix ก็อยู่ที่ https://$dashboard.$company.com ด้วย ลูกค้าจึงแก้เองไม่ได้และต้องให้ทีมซัพพอร์ตช่วย แน่นอนว่าเครื่องมือซัพพอร์ตก็ไม่ได้เปิดฟีเจอร์ให้เปลี่ยน prefix ของ $dashboard โดยตรงการจะทำ blocklist ก็ไม่ใช่เรื่องเล็ก ต้องครอบคลุมทั้งรายการ DNS ที่มีอยู่, prefix ของ $dashboard ที่มีอยู่แล้ว, คำหยาบ, สัญลักษณ์ Unicode, prefix
xn--ของ Punycode, การ redirect จาก prefix เดิม และการจองเพื่อป้องกันการถูกยึดใช้ล่วงหน้าในอนาคตจึงไม่น่าแปลกใจที่ Slack จะมีช่องโหว่แบบนี้ มันเป็นปัญหาที่ยากโดยเนื้อแท้
https://support.zendesk.com/hc/en-us/articles/4408838571930-...
ผมคิดว่าอย่างน้อยควรแยก subdomain สำหรับหน้าลูกค้าไปไว้บน โดเมนแยกต่างหาก จะดีกว่า เหมือน GitHub หรือ Shopify โดย GitHub ใช้ GitHub.com เป็นโดเมนของตัวเอง และใช้ GitHub.io เป็นโดเมนสำหรับเพจผู้ใช้ ส่วน Shopify ก็แยก Shopify.com กับ myshopify.com
ข้อดีของโดเมนแยกสำหรับลูกค้าคือชนกับ subdomain ที่บริษัทใช้อยู่หรืออาจอยากใช้ในอนาคตน้อยลง และสามารถใส่โดเมนนั้นใน Public Suffix List เพื่อหลีกเลี่ยงปัญหาที่อาจเกิดขึ้นได้ ถึงอย่างนั้นก็ยังต้องกรองคำที่ดูหมิ่นหรือทำให้เข้าใจผิดอยู่ดี
https://publicsuffix.org/
Adminจริง ๆ ฝ่าย IT กำลังปวดหัวว่าจะจัดการเรื่องนี้อย่างไรoกับоนี่แทบจะเป็นหนึ่งในรูปแบบ homograph attack ที่ง่ายที่สุดแล้วhttps://en.wikipedia.org/wiki/IDN_homograph_attack
เรื่องคือ ตอนลาออก McKay เปลี่ยนรูปโปรไฟล์ให้เหมือนไอคอน Slackbot ที่ดูโมโหกว่าเดิม และเปลี่ยนชื่อเป็น
Slackbotซึ่ง Slack บล็อกเพราะชื่อนี้ถูกใช้แล้ว แต่ถ้าเปลี่ยนตัวoเป็นอักขระ Unicodeоก็ใช้ได้คู่ตัวอักษรอังกฤษ/ซีริลลิกนี้ถูกใช้แล้วแม้แต่ในหนึ่งในการโจมตี glyph หน้าตาเหมือนกันยุคแรก ๆ ที่เผยแพร่เมื่อปี 2001
https://web.archive.org/web/20200102175251/http://www.cs.tec...
ในปี 2022 Slack มีมูลค่าราว 20,000 ล้านดอลลาร์ และดำเนินงานมาเกือบ 10 ปีแล้ว แถมยังเป็นซอฟต์แวร์ที่อิงชื่อผู้ใช้และขายให้กับองค์กร/บริษัทที่ต้องการความปลอดภัยด้วย
ถ้าอยากอนุญาตสัญลักษณ์บางอย่าง ก็ใช้ allowlist หรือเช็กว่าชื่อผู้ใช้มี Levenshtein distance ห่างจากชื่อสำคัญอย่าง
slackbotพอสมควรหรือไม่ แล้วห้ามใช้หรือส่งให้คนตรวจสอบการปิดกั้นทุกอย่างเป็นเรื่องยากโดยเนื้อแท้ แต่การกันปัญหาใหญ่ ๆ ไม่ใช่เรื่องยาก
ที่ที่เหมาะที่สุดสำหรับซ่อนตัวคือทำให้ดูเหมือน service account ที่ทุกคนกลัวจะไปแตะ เพราะไม่รู้ว่าถ้าปิดแล้วอะไรจะพัง ทำได้ดีมาก
Jiraทิ้ง เพราะไม่รู้ว่าบัญชีนั้นมีไว้ทำไม และชื่อ$CompanySecretaryดูน่าสงสัยอีกไม่กี่วันต่อมา เราต้องเหนื่อยมากในการตามหาและแก้ workflow กับ ticket ทั้งหมดที่อ้างถึงผู้ใช้นั้น ก่อนที่สิ่งสำคัญจริง ๆ จะพัง
“แน่นอนว่าไม่ใช่ทุกบริษัทจะหลงกลมุกนี้” แต่บริษัทอาจเป็นฝ่ายหัวเราะทีหลังก็ได้: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
การแทนอักขระ ASCII ด้วย อักขระ Unicode ที่หน้าตาคล้ายกันเป็นมุกเก่าแล้ว อักขระแบบนี้มีค่อนข้างเยอะ และเอาไปใส่ในโค้ดเพื่อแกล้งเพื่อนนักพัฒนาก็ได้ วันที่ 1 เมษายนก็ใกล้เข้ามาแล้วด้วย
ผมยังเคยทำปลั๊กอิน Vim ที่ไฮไลต์อักขระ “อันตราย” แบบนี้ไว้ด้วย: https://github.com/vim-utils/vim-troll-stopper
ผมไม่เคยโดนแกล้งด้วยอักขระ Unicode แต่เคยมีแอปพังเพราะที่ปรึกษาชาวญี่ปุ่นเผลอใส่อักขระ “ช่องว่างแบบญี่ปุ่น” ลงในไฟล์แปลโดยไม่ได้ตั้งใจ ผมเปิดปลั๊กอิน Vim ไว้ตลอด เลยรู้สาเหตุได้เร็ว
ภายหลังมันถูกแปลงเป็นอักขระที่ไม่ใช่ตัวยก ทำให้ความหมายเปลี่ยนไปพอสมควร ที่ไม่เป็นมิตรกว่านั้นคือ หลังจากพยายามใส่สัญลักษณ์นั้นแล้วยังเขียนคำว่า
degreesตามไว้ด้วยถ้า Slack ไม่อนุญาตให้ล็อกการเปลี่ยนชื่อได้ ผมว่านั่นคงเป็น ช่องโหว่ด้านความปลอดภัย ขนาดใหญ่สำหรับองค์กรใหญ่
ถ้าเปลี่ยนชื่อเป็น CEO แล้วตั้งรูปโปรไฟล์ให้ตรงกัน โอกาสที่จะมีคนสังเกตเห็นความต่างก่อนสายเกินไปมีน้อยมาก การเปลี่ยนเป็น Slackbot ดูเป็นเรื่องเล็กไปเลย
ทุกครั้งที่เปิดแอปเดสก์ท็อปก็ต้องใช้ SSO ด้วย ดังนั้นถ้าออกจากบริษัทแล้วจะกลับเข้ามาไม่ได้แน่นอน บัญชีก็ถูกปิดใช้งานเร็วมาก จึงน่าจะไม่ต้องกังวลเรื่องมือถือมากนัก
สิ่งที่เปลี่ยนได้โดยไม่ต้องส่งทิกเก็ตจริง ๆ ก็มีแค่รูปกับช่องกรอกอิสระที่ไม่สำคัญเท่าไรไม่กี่ช่อง
พวกเราใช้มันในทางที่ผิด โดยใส่ข้อมูลการอยู่/ไม่อยู่ไว้ตรงชื่อแสดงเลย เช่น
mike-2/12~16vac.เพื่อให้คนที่ติดต่อมาคาดเดาเวลาตอบกลับได้ หรือรู้ว่าถ้าใกล้ถึงวันลาพักร้อนที่วางไว้ไม่กี่วัน ยังควรมอบหมายงานให้หรือไม่ดูเหมือนว่าไม่มีใครดูคุณสมบัติสถานะจริง ๆ และมันก็ดีกว่าต้องไปเปิดปฏิทินเช็ก
ถ้าดูภาพหน้าจอที่คนตอบเขา จะเห็นว่าพวกเขารู้อย่างชัดเจนว่าเขาไม่ใช่ Slackbot และยังเรียกเขาว่า Tom ด้วย ดังนั้นมันค่อนข้างขัดกับพาดหัว เขาไม่ได้อยู่ในสถานะ “ไม่ถูกจับได้” อย่างชัดเจน
ใน Slack ของเราก็ยังมีอดีตพนักงานอยู่ พวกเขาแวะมาทักทายเป็นครั้งคราว ซึ่งก็ดูดี ถ้าสักวันหนึ่งใครในนั้นเริ่มล้อเลียนทำตัวเป็น Slackbot แบบประชดประชัน พวกเราก็น่าจะหัวเราะแล้วปล่อยผ่าน
ที่ทำงานเก่าของผมปิดใช้งานบัญชี Slack ช้า ดังนั้นตอนลาออก ผมเลยสร้าง ช่องส่วนตัว ชื่อ
#daves_caveแล้วเชิญเพื่อน ๆ เข้ามาบางครั้งก็ทิ้งเรื่องสั้น ๆ หรือถ้อยคำคม ๆ ไว้ และมันก็สนุกดีจนกระทั่งผู้บริหารสังเกตเห็นและปิดใช้งานบัญชีผม
ข้อดีของวิธีนี้คือมันเป็น “การออกแบบที่ตั้งใจไว้” จึงมีโอกาสถูกปิดน้อย และมีโอกาสเข้าข่ายกฎหมายเกี่ยวกับการใช้คอมพิวเตอร์ในทางที่ผิดน้อยกว่าด้วย
ผมคิดว่าบริษัทคงมองว่าคำตอบของปัญหานี้คือ Single Sign-On
ทุกวันนี้ผมไม่ได้ดูแล IT แล้ว แต่ตอนที่เคยดูแล เราจะทำเครื่องหมายผู้ลาออกว่าไม่ใช้งานใน Azure Active Directory จากนั้นพวกเขาจะล็อกอินเข้า Office 365, Outlook, Teams หรือบริการใด ๆ ไม่ได้ และเข้าใช้บริการของบุคคลที่สามที่ใช้ MS SSO ไม่ได้ด้วย Slack ก็ควรผูกเข้ากับตรงนั้นไม่ใช่หรือ?