1 điểm bởi GN⁺ 2024-02-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tom McKay của IT Brew khi rời Gizmodo vào năm 2022 đã ngụy trang tài khoản Slack của mình thành Slackbot và tránh bị xóa trong nhiều tháng
  • Slack đã chặn tên “Slackbot” vì đã được sử dụng, nhưng McKay đã vượt qua giới hạn tên hiển thị bằng các ký tự Unicode trông tương tự
  • Anh cũng đổi ảnh hồ sơ thành một phiên bản giận dữ giống biểu tượng Slackbot thật, khiến quản trị viên không nhận ra Slackbot trùng lặp này chỉ khác ở cặp lông mày
  • Trong thời gian tài khoản vẫn còn, McKay có thể gửi cho đồng nghiệp những tin nhắn trông như bot, chẳng hạn “Slackbot fact of the day”
  • Tùy công ty, có thể có các biện pháp bảo mật để ngăn những trò đùa như vậy, nên việc dọn dẹp tài khoản của người đã nghỉ việc và xác minh tên hiển thị là rất quan trọng

Tài khoản Slack vẫn còn sau khi nghỉ việc

  • Tom McKay của IT Brew sau khi rời Gizmodo đã ngụy trang tài khoản Slack của mình thành Slackbot
  • McKay đã chia sẻ ảnh chụp màn hình khi đó trên X, và cũng xác nhận với The Verge rằng trò đùa này là có thật
  • Tài khoản được ngụy trang đã không bị ban quản trị Gizmodo phát hiện hoặc xóa trong nhiều tháng

Cách làm cho tài khoản trông giống Slackbot

  • Slackbot là bot quen thuộc trong Slack, hỗ trợ thông báo, tra cứu mật khẩu Wi-Fi văn phòng, thông báo khi bạn được nhắc đến trong các kênh chưa tham gia, v.v.
  • Vào thời điểm nghỉ việc, McKay đổi ảnh hồ sơ cũ thành một hình ảnh phiên bản giận dữ giống biểu tượng Slackbot thật
  • Anh cũng cố đổi tên hiển thị thành “Slackbot”, nhưng Slack không cho phép đổi theo cách thông thường vì đây là tên đã được sử dụng
  • Thay vào đó, anh dùng các ký tự Unicode giống chữ cái để vượt qua giới hạn tên
    • Ví dụ: thay “o” bằng ký tự Unicode “о” trông tương tự

Những gì có thể làm trong nhiều tháng

  • Nhờ thay đổi này, tài khoản Slack đang hoạt động của McKay đã tránh bị xóa trong nhiều tháng
  • Trong thời gian tài khoản vẫn còn, anh có thể gửi cho đồng nghiệp những tin nhắn trông như bot
    • Ví dụ: “Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!”
  • Victoria Song, người từng làm việc tại Gizmodo, phản ứng rằng tình huống này không có gì đáng ngạc nhiên

Khả năng phòng vệ tùy từng công ty

  • Không phải công ty nào cũng bị đánh lừa theo cách này; một số công ty có các biện pháp bảo mật để ngăn những tình huống kiểu này
  • Ban quản trị Gizmodo có thể đã nghĩ rằng tài khoản của McKay đã bị xóa
  • Hoặc họ có thể đã không xem xét kỹ đến mức phát hiện một Slackbot trùng lặp với cặp lông mày đáng ngờ

1 bình luận

 
GN⁺ 2024-02-25
Ý kiến trên Hacker News
  • Một cựu nhân viên tôi từng biết trước đây đã từng tạo một hồ sơ provisioning dial-up/ISDN tên là Ringing trong mô-đun bộ điều khiển modem rack. Làm trên máy chủ Radius thì quá lộ nên họ tránh làm vậy
    Khi nhìn vào trang trạng thái của modem rack, sẽ thấy một trạng thái Ringing giống như một cuộc gọi chưa được trả lời bên cạnh các người dùng đang kết nối, và người đó đã dùng dịch vụ ISDN 128Kbit hơn 1 năm mà không bị phát hiện hoàn toàn
    Tất nhiên tôi không khuyến khích làm kiểu này. Đặc biệt là bây giờ CFAA đôi khi còn bị diễn giải theo kiểu bao gồm cả việc đổi tham số URL hay búng cục gỉ mũi lên thảm

    • Không rõ có căn cứ nào về vụ CFAA này không. Ngược lại, có vẻ việc thay đổi tham số URL nhiều khả năng không phải là vấn đề
      Theo luật New Jersey, để bị kết tội vì “truy cập trái phép hoặc vượt quá quyền truy cập được cấp”, chính phủ phải chứng minh rằng đã vượt qua một rào cản dựa trên mã hoặc mật khẩu; còn trong vụ đó thì về cơ bản chỉ là truy cập một phần của màn hình đăng nhập công khai và thu thập thông tin mà AT&T vô tình công khai
      https://law.justia.com/cases/federal/appellate-courts/ca3/13...
    • Làm tôi hơi nhớ lại lần hai anh em chơi co-op đấu máy trong Warcraft II qua mạng LAN, tôi đổi tên thành Computer rồi lén vào trận
    • Ở công ty cũ, tôi từng lặng lẽ chờ nhiều tháng để họ xóa tài khoản Slack của tôi. Gần 1 năm sau tôi vẫn còn toàn quyền truy cập vào khá nhiều kênh nội bộ, thật sự rất kỳ lạ
      Với những người thân quen thì đúng thật, nhưng không phải họ cố tình để lại vì quý mến đâu, mà vì việc quản lý tài khoản Slack và tích hợp Google Office của họ quá lộn xộn
    • Tôi không hiểu câu chuyện CFAA và cục gỉ mũi là sao. Tìm kiếm cũng không thấy tài liệu tham khảo nào
  • Làm tôi nhớ đến một ngày huy hoàng ở một công ty tư vấn vào khoảng năm 2016, khi chúng tôi phát hiện ra có thể đổi tên Slack của nhau. Có một thời gian tên của mọi người đều chỉ là dad

    • Nghe rất giống lúc bọn trẻ nhận ra rằng tên và ảnh hồ sơ Netflix/Disney+ thì ai cũng đổi được
    • Cũng hay đấy nhưng tôi sẽ kiên quyết dùng grandad. Không thì tôi sẽ thả lũ cháu gái ra, mà chúng thì tàn nhẫn lắm
    • Giờ chuyện này vẫn còn làm được à?
      Đội ultimate frisbee của trường đại học đang dùng Slack
  • Nhiều người khuyên nên chặn việc đổi tên, nhưng như vậy cũng không giải quyết triệt để vấn đề. Ở đâu đó vẫn có thể có người tên thật là Jira
    Ở một công ty cũ của tôi, bảng điều khiển khách hàng được đặt trên wildcard https://*.$company.com. Ví dụ như https://foo.$company.com
    Nhưng nếu ai đó chọn slug dashboard trùng với bản ghi thực tế như www hoặc blog, thì dashboard đó sẽ hoàn toàn không thể truy cập được. Cài đặt để đổi tiền tố cũng nằm ở https://$dashboard.$company.com, nên khách hàng không thể tự sửa và phải cần đội hỗ trợ. Dĩ nhiên, công cụ hỗ trợ cũng không hề hiển thị chức năng đổi trực tiếp tiền tố $dashboard
    Việc xây dựng danh sách chặn cũng không hề đơn giản. Cần tính đến các mục DNS hiện có, các tiền tố $dashboard đã tồn tại, từ ngữ tục tĩu, ký hiệu Unicode, tiền tố xn-- của Punycode, cả chuyển hướng từ tiền tố cũ lẫn phần đặt trước để ngăn chiếm chỗ trong tương lai
    Tôi không ngạc nhiên khi Slack có lỗ hổng kiểu này. Về bản chất đây là một bài toán khó

    • Zendesk đặt dashboard khách hàng trên subdomain trực tiếp của domain chính của họ. Họ cũng cho phép dùng domain riêng, và để dùng thì phải tạo CNAME trỏ tới subdomain do Zendesk cấp
      https://support.zendesk.com/hc/en-us/articles/4408838571930-...
      Theo tôi, giống GitHub hay Shopify, subdomain dành cho trang khách hàng ít nhất nên được đặt trên một domain riêng. GitHub dùng GitHub.com cho chính mình và GitHub.io cho trang người dùng, còn Shopify cũng tách Shopify.com và myshopify.com
      Lợi ích của domain riêng cho khách hàng là ít va chạm hơn với các subdomain hiện tại và tương lai mà công ty muốn tự dùng, đồng thời có thể đưa domain đó vào Public Suffix List để tránh các vấn đề tiềm ẩn. Dù vậy vẫn nên lọc các từ ngữ mang tính xúc phạm hoặc dễ gây hiểu lầm
      https://publicsuffix.org/
    • Ở chỗ làm của vợ/chồng tôi thực sự có một nhân viên tên Admin. Bộ phận IT đang đau đầu không biết phải xử lý chuyện đó thế nào
    • Ở đây thật sự có ai đang cố biện hộ cho Slack sao? oо gần như thuộc nhóm dễ nhất trong các kiểu tấn công ký tự đồng hình có thể xảy ra
      https://en.wikipedia.org/wiki/IDN_homograph_attack
      Khi nghỉ việc, McKay đã đổi ảnh đại diện thành biểu tượng Slackbot trông cáu kỉnh hơn và đổi tên thành Slackbot. Slack chặn vì tên Slackbot đã tồn tại, nhưng nếu thay o bằng ký tự Unicode о thì lại hoạt động
      Cặp chữ cái Latin/Cyrillic này đã xuất hiện trong một trong những cuộc tấn công homograph đời đầu được công bố từ năm 2001
      https://web.archive.org/web/20200102175251/http://www.cs.tec...
      Năm 2022, Slack được định giá khoảng 20 tỷ USD và đã vận hành gần 10 năm. Hơn nữa, đây còn là phần mềm dựa trên tên người dùng, phục vụ các tổ chức và doanh nghiệp cần bảo mật
    • Chỉ cần giới hạn các ký tự được phép dùng, rồi trước khi cho phép thay đổi thì kiểm tra nguyên trạng xem trang đó đã được phân giải hay chưa. Như vậy khách hàng sẽ không bị khóa ngoài, đồng thời cũng khó giả mạo đối tượng khác chỉ bằng ký tự
      Nếu muốn cho phép một số ký hiệu, có thể dùng allowlist, hoặc kiểm tra xem tên người dùng có khoảng cách Levenshtein đủ xa với các tên cốt lõi như slackbot hay không, rồi cấm hoặc gắn cờ để con người xem xét
      Về bản chất, chặn mọi thứ là rất khó, nhưng chặn những vấn đề lớn nhất thì không khó
    • Trong trường hợp này, nguyên tắc “đừng để các không gian tên vốn khác nhau va chạm với nhau” thực ra không phải vấn đề quá khó
  • Nơi ẩn mình tốt nhất là trông giống như một tài khoản dịch vụ mà ai cũng sợ đụng vào vì không biết vô hiệu hóa nó thì sẽ làm hỏng thứ gì. Làm hay lắm

    • Ngược lại, ở công ty tôi từng có một nhân viên IT quá nhiệt tình đã xóa tài khoản tự động hóa Jira. Người đó không biết vì sao tài khoản này tồn tại và thấy cái tên $CompanySecretary có vẻ đáng ngờ
      Vài ngày sau, trước khi thứ gì thực sự quan trọng bị hỏng, chúng tôi đã khổ sở lần tìm và sửa toàn bộ workflow lẫn ticket đang tham chiếu tới người dùng đó
    • Làm tôi nhớ tới các loại malware nổi tiếng và tên tiến trình của chúng
  • Dù “tất nhiên không phải công ty nào cũng mắc bẫy trò đùa này”, nhưng công ty vẫn có thể là bên cười sau cùng: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

    • Đó cũng là điểm mấu chốt của việc anh ta đợi 2 năm rồi mới kể ra. Nó trùng đúng với thời hiệu truy tố của CFAA
    • Đó là điều đầu tiên tôi nghĩ tới khi thấy cụm từ “trò đùa vô hại”
    • Người cười sau cùng cũng có thể là Slack. Rốt cuộc thì anh ta đã tiếp cận được rất nhiều “dữ liệu kinh doanh nhạy cảm”
  • Việc thay các ký tự ASCII bằng ký tự Unicode trông tương tự là một trò cũ. Có khá nhiều ký tự kiểu này, và có thể dùng chúng để trêu đồng nghiệp lập trình bằng cách chèn vào code. Mùng 1 tháng 4 cũng sắp đến rồi
    Tôi thậm chí còn làm một plugin Vim để làm nổi bật những ký tự “nguy hiểm” như vậy: https://github.com/vim-utils/vim-troll-stopper
    Tôi chưa từng bị chơi khăm bằng ký tự Unicode, nhưng từng có lần một tư vấn viên người Nhật vô tình chèn ký tự “khoảng trắng kiểu Nhật” vào file dịch nên ứng dụng bị hỏng. Vì tôi luôn bật plugin Vim đó nên đã nhanh chóng tìm ra nguyên nhân

    • Nhiều ứng dụng “tốt bụng” bắt đầu đổi hai dấu gạch nối thành dấu gạch dài Unicode trông đẹp hơn, và vì thế làm hỏng các công cụ dòng lệnh
    • Nhớ cái này: https://news.ycombinator.com/item?id=10438363
    • Ngay cả ký tự rác vô tình xuất hiện cũng có thể gây hậu quả lớn. Tôi nhớ có người trong một báo cáo y tế đã dùng chữ O ở dạng superscript như thể đó là ký hiệu độ
      Sau đó nó bị chuyển thành một ký tự không còn là superscript nữa, khiến ý nghĩa thay đổi khá nhiều. Điều còn khó chịu hơn là sau nỗ lực dùng ký hiệu đó, họ còn viết kèm luôn từ degrees
  • Nếu Slack không cho phép khóa việc đổi tên thì với doanh nghiệp lớn đây có vẻ là một lỗ hổng bảo mật khổng lồ
    Chỉ cần đổi tên thành CEO và chỉnh ảnh đại diện cho khớp thì khả năng nhận ra sự khác biệt trước khi quá muộn là cực thấp. Đổi thành Slackbot có vẻ chỉ là chuyện nhỏ

    • Có thể khóa việc đổi tên. Tôi đang ở một tổ chức Enterprise Grid, nơi tên hiển thị và username được đồng bộ với hồ sơ nhân sự
      Mỗi lần chạy ứng dụng desktop đều bắt buộc SSO, nên đã nghỉ việc thì tuyệt đối không thể vào lại. Tài khoản cũng bị vô hiệu hóa rất nhanh, nên thiết bị di động chắc cũng không phải mối lo lớn
      Thực tế, những gì có thể thay đổi mà không cần gửi ticket chỉ là ảnh và vài trường nhập tự do không mấy quan trọng
    • Có thể làm trong phần cài đặt tổ chức. Chuyện SAML/SSO bên dưới cũng vậy. Nếu vẫn đổi được tên thì gần như là do không có quản trị viên IT hoặc họ quá lười
    • Các công ty lớn dùng SAML hoặc cơ chế liên kết danh tính khác để bạn không thể đăng nhập nếu không có xác thực của công ty
    • Đồng thời, tính năng đổi tên cũng thực sự là một phước lành lớn
      Bên tôi đang lạm dụng nó bằng cách ghi luôn thông tin vắng mặt vào tên hiển thị. Ví dụ như mike-2/12~16vac. để người liên hệ có thể ước lượng thời gian phản hồi, hoặc biết rằng vài ngày trước kỳ nghỉ dự kiến thì có nên giao việc hay không
      Có vẻ chẳng ai xem thuộc tính trạng thái thật sự, và cách này vẫn tốt hơn là phải vào lịch để kiểm tra
    • Tôi đoán đây cũng là một trong những lý do gần đây công ty tôi đã gỡ tính năng cho mọi người tự đổi tên trong hệ thống họp video
  • Nhìn các ảnh chụp màn hình người khác trả lời anh ta thì rõ ràng họ biết anh ta không phải Slackbot, thậm chí còn gọi anh ta là Tom. Vậy nên điều này hơi mâu thuẫn với tiêu đề. Rõ ràng anh ta không hề ở trạng thái “không bị phát hiện”
    Trong Slack của bọn tôi cũng vẫn còn nhân viên cũ. Thỉnh thoảng họ ghé vào chào hỏi, nhìn cũng vui. Nếu một ngày nào đó có người bắt đầu giả làm Slackbot theo kiểu châm biếm thì chắc bọn tôi cũng chỉ cười cho qua

    • Ý ở đây là “không bị ban quản lý phát hiện”. Bài báo cũng nói rõ vậy. Bạn bè của anh ta biết anh ta vẫn ở đó và cùng cười về chuyện đó
    • Chỗ chúng tôi cũng tương tự. Slack không phải kênh liên lạc chính, nhưng được dùng cho tư vấn viên bên ngoài, và những người đã rời đi vẫn chưa bị đuổi khỏi đó, tiếp tục hẹn nhau đi ăn trưa
  • Nơi tôi từng làm trước đây vô hiệu hóa tài khoản Slack rất chậm. Vì vậy khi nghỉ việc, tôi đã tạo một kênh riêng tư tên là #daves_cave và mời bạn bè vào
    Thỉnh thoảng tôi để lại vài mẩu chuyện ngắn hoặc câu đùa hóm hỉnh, và cũng khá vui cho đến khi ban quản lý nhận ra rồi vô hiệu hóa tài khoản của tôi

    • Tôi có một Slack team trả phí cá nhân, hình như khoảng 10 USD mỗi tháng. Bạn có thể mời người từ các Slack team trả phí khác vào phòng để trò chuyện
      Điểm hay của cách này là nó là “thiết kế có chủ đích”, nên ít khả năng bị đóng lại, và cũng ít khả năng vướng các luật liên quan đến lạm dụng máy tính
  • Tôi nghĩ ở công ty, câu trả lời cho vấn đề này hẳn là đăng nhập một lần
    Giờ tôi không còn vận hành IT nữa, nhưng hồi còn làm thì tôi đánh dấu nhân viên nghỉ việc là vô hiệu hóa trong Azure Active Directory. Khi đó họ sẽ không thể đăng nhập vào bất kỳ dịch vụ nào như Office 365, Outlook, Teams, v.v., cũng như không vào được các dịch vụ bên thứ ba dùng SSO của Microsoft. Chẳng phải Slack cũng nên nối vào đó sao?

    • Một bộ phận IT có năng lực hoặc đủ nhân lực thì đương nhiên sẽ làm vậy. Chỉ là cũng có thể một phòng ban khác đã tự thiết lập Slack mà không bàn với IT