1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Người dùng LastPass nhận được thông báo rằng dữ liệu cá nhân và dữ liệu vụ việc hỗ trợ đã bị lộ do sự cố xâm phạm Klue của một đối tác bên ngoài
  • Phạm vi truy cập trong sự cố này chỉ giới hạn ở thông tin liên hệ kinh doanh tiêu chuẩn, dữ liệu CRM, dữ liệu vụ việc hỗ trợ và dữ liệu liên quan đến bán hàng; kho mật khẩu không bị ảnh hưởng
  • Các mục bị lộ bao gồm tên khách hàng, số điện thoại, địa chỉ email, địa chỉ thực; nền tảng Klue được tích hợp với các hệ thống SalesforceGong
  • Sau khi nhận biết sự cố, LastPass đã hủy quyền truy cập Klue của nhân viên, thay thế các API token bị lộ, đồng thời thông báo cho cơ quan thực thi pháp luật và tiến hành điều tra thông qua Klue và Salesforce
  • Thông tin liên hệ bị rò rỉ có thể bị lợi dụng cho phishing và các cuộc tấn công kỹ nghệ xã hội, vì vậy khách hàng và doanh nghiệp cần kiểm tra các chỉ báo tấn công đã được chia sẻ

Sự cố xâm phạm Klue và phản ứng của LastPass

  • LastPass đã gửi email cho những người dùng liên quan do ảnh hưởng từ sự cố xâm phạm xảy ra tại công ty nghiên cứu thị trường Klue
  • Thông qua vụ xâm phạm, hacker có thể truy cập thông tin khách hàng và dữ liệu vụ việc hỗ trợ
  • Thông tin bị truy cập được giới hạn trong phạm vi sau
    • Tên khách hàng, số điện thoại, địa chỉ email, địa chỉ thực
    • Dữ liệu quản lý quan hệ khách hàng (CRM)
    • Dữ liệu vụ việc hỗ trợ
    • Dữ liệu liên quan đến bán hàng
  • Kho mật khẩu của LastPass không bị ảnh hưởng trong sự cố này
  • Nền tảng Klue được tích hợp với các hệ thống SalesforceGong
  • Để ứng phó sự cố, LastPass đã thực hiện các bước chặn truy cập và điều tra
    • Hủy quyền truy cập Klue của nhân viên
    • Thay thế các API token bị lộ
    • Thông báo cho cơ quan thực thi pháp luật
    • Điều tra phạm vi sự cố thông qua việc liên hệ với Klue và Salesforce

Chỉ báo tấn công và các sự cố bảo mật trước đây

  • Khách hàng cần cảnh giác với các cuộc tấn công phishing hoặc nỗ lực kỹ nghệ xã hội sử dụng thông tin bị rò rỉ
  • Các chỉ báo liên quan đến kẻ tấn công đã được chia sẻ để doanh nghiệp có thể tìm kiếm hoạt động liên quan trong hệ thống của mình
    • Địa chỉ IP:
      • 138.226.246[.]94
      • 94.154.32[.]160
      • 159.183.215[.]61
      • 159.183.181[.]239
    • Tên miền gửi email:
      • baccarat.com[.]au
      • robinskitchen.com[.]au
      • house.com[.]au
  • LastPass từng trải qua nhiều sự cố bảo mật trong quá khứ
    • Năm 2015, địa chỉ email tài khoản, gợi ý mật khẩu, hash xác thực và salt mã hóa đã bị đánh cắp, nhưng dữ liệu kho đã mã hóa không bị truy cập
    • Năm 2022, kẻ tấn công xâm phạm tài khoản nhà phát triển, đánh cắp mã nguồn và thông tin kỹ thuật, rồi sau đó dùng chúng để truy cập các bản sao lưu đám mây chứa hồ sơ khách hàng và kho mật khẩu đã mã hóa
    • Sự cố cùng năm 2022 cũng bao gồm thông tin chưa mã hóa như tên, địa chỉ thanh toán, địa chỉ email và số điện thoại

1 bình luận

 
Ý kiến trên Hacker News
  • Giờ thì tôi không biết còn ai có thể thực sự tin tưởng LastPass nữa
    Vài năm trước tôi làm ở một công ty xử lý dữ liệu ngân hàng, và ngay cả sau sự cố bảo mật LastPass trước đó họ vẫn tiếp tục dùng LastPass và cũng không có kế hoạch chuyển đi

    • Nhiều cá nhân và tổ chức dùng sản phẩm bảo mật không phải để có bảo mật, mà là để diễn kịch bảo mật
      Phần lớn mọi người, kể cả nhiều người phụ trách bảo mật, có lẽ còn chưa nghe về vụ xâm nhập này, nên với họ LastPass vẫn đang hoạt động tốt
    • Nếu mật khẩu vẫn chưa bị lộ thì từ góc nhìn người dùng cuối, vụ “xâm nhập” đó không phải là thất bại
      Nếu mật khẩu chủ của kho vẫn an toàn, và cách duy nhất để truy cập kho vẫn chỉ là mật khẩu chủ, thì với người dùng cuối sản phẩm vẫn đang làm đúng chức năng họ cần
      Từ “xâm nhập” tự nó không có nhiều ý nghĩa nếu không kèm điều kiện cụ thể
    • Tôi đã làm khá nhiều tư vấn bảo mật cho hàng trăm công ty, và trên thực tế những công ty coi trọng bảo mật nhất lại là những công ty đã từng bị xâm nhập
      Trước khi ban điều hành và hội đồng quản trị trực tiếp thấy tác động về chi phí, thì chỉ đọc về nó thôi sẽ không bao giờ giúp chương trình bảo mật có được ngân sách cần thiết
      Điều đó không có nghĩa là tôi sẽ khuyến nghị LastPass vì lý do đó, nhưng cũng không đến mức loại bỏ hoàn toàn chỉ vì mỗi lý do ấy
    • Tôi không hiểu sao người ta có thể tin việc giao toàn bộ mật khẩu và khóa mã hóa cho bên thứ ba
      Việc thiết lập KeePassXC cực kỳ đơn giản
  • Có nhiều công ty bị ảnh hưởng hơn rất nhiều. Một số được liệt kê bên dưới

    "Klue has not said how many of its hundreds of customers are affected. Several companies have come forward to confirm they had data stolen during the attack, including Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium."
    Cybercrime group Icarus took credit for the breach, saying on its leak site that it will publish the stolen data on Monday if the company does not pay the hackers’ ransom."
    https://techcrunch.com/2026/06/22/klue-hack-results-in-data-...

  • Tôi không hiểu nổi tại sao LastPass lại chuyển chi tiết khách hàng cho một công ty nghiên cứu thị trường
    Loại dữ liệu đó đáng lẽ phải được ẩn danh hoàn toàn, không có tên, không có địa chỉ cụ thể, v.v.
    Với những ai hỏi gợi ý, tôi dùng KeepassXC và Keepass2Android. Chúng là mã nguồn mở, dùng cơ sở dữ liệu cục bộ, và bạn có thể tự chọn có đồng bộ hay không. Tôi đồng bộ qua Own cloud

    • Tôi đã dùng pwsafe nhiều năm rồi
      Nó cũng là mã nguồn mở miễn phí và là kho cục bộ thuần túy. Không cần phụ thuộc vào một dịch vụ đám mây có thể làm mất dữ liệu một cách ngớ ngẩn
      Tất nhiên bạn có thể chọn lưu kho trong Dropbox hay iCloud Drive, nhưng tôi không hiểu vì sao lại phải làm vậy
    • Any such data should have been fully anonymized: no names, no specific addresses, etc..
      Ngay từ đầu tại sao lại phải chuyển loại dữ liệu đó đi?

  • https://blog.lastpass.com/posts/klue-supply-chain-incident-a...

    The information accessed was limited to standard business contact information and related customer relationship management (CRM) data, including customer names, phone numbers, email addresses, and physical addresses, as well as support case data and sales-related data.

  • Cách này ở một khía cạnh nào đó có thể còn tệ hơn cả dùng LastPass, nhưng trong vài năm qua tôi đã làm với 90% mật khẩu theo kiểu cứ tạo rồi quên luôn
    Chỉ 10% còn lại tôi mới lưu trong trình quản lý mật khẩu. Với các dịch vụ không quá quan trọng, mỗi lần đăng nhập tôi chỉ dùng “quên mật khẩu” để tạo và đổi sang mật khẩu mới

    • Cách này hiệu quả nếu tài khoản không có xác thực hai yếu tố
      Ở ứng dụng side project gần đây nhất của tôi, người dùng chỉ có thể đăng nhập bằng mật khẩu dùng một lần gửi qua email
      Tất nhiên có nhược điểm bảo mật như phishing, khiến người dùng nhập mật khẩu dùng một lần vào trang giả mạo, nhưng vì đó là ứng dụng không lưu gì nhạy cảm nên tôi không xem là rủi ro bảo mật lớn
    • Tôi từng gặp rắc rối vì không còn truy cập được số điện thoại cũ nữa, trong khi mã SMS xác thực hai yếu tố vẫn được gửi tới số đó
    • Đó là lý do nhiều dịch vụ đang chuyển sang dùng liên kết ma thuật qua email để đăng nhập
      Rốt cuộc ở rất nhiều dịch vụ, chiếm được email gần như đồng nghĩa với chiếm được đăng nhập
  • Tôi đã dùng Enpass nhiều năm nhờ mua được giấy phép trọn đời với giá rẻ
    Enpass không tự vận hành dịch vụ đám mây riêng để đồng bộ mật khẩu, mà để người dùng xác thực với bộ nhớ đám mây của họ rồi đồng bộ vào đó. Tôi dùng Google Drive
    Tôi thấy cách tiếp cận này tốt hơn. Nếu ai đó ác ý vào được tài khoản Google của tôi thì coi như tôi cũng xong rồi, và có lẽ còn tệ hơn cả việc họ chỉ vào được trình quản lý mật khẩu
    Ngoài ra nó không tạo ra một đống dữ liệu tập trung mà nếu bị xâm nhập sẽ thành cú nổ lớn. Muốn lấy được toàn bộ mật khẩu Enpass, kẻ tấn công sẽ phải hack Google Drive, Dropbox, iCloud, v.v., rồi tự lần tìm file bằng tay

    • Ví dụ thì điều đó khác gì so với KeePass?
  • Cứ hùa nhau chửi LastPass vì thêm một vụ xâm nhập nữa, rồi nói rằng chuyển dữ liệu khách hàng cho bên thứ ba là hoàn toàn vô trách nhiệm thì cũng vui đấy, nhưng chỉ cần dừng lại một chút để xem chuyện gì thực sự đã xảy ra thì sẽ thấy câu chuyện trong đầu và thực tế khác nhau khá nhiều
    Klue là một trong nhiều dịch vụ quản lý quan hệ khách hàng mà các đội bán hàng dùng. Bạn phải chuyển email liên hệ khách hàng, hồ sơ khách hàng như phòng tài chính, v.v. thì Klue mới có thể cung cấp những thứ như “thông tin thị trường” về khách hàng đó
    Nếu bạn đi xem các thứ linh tinh mà đội bán hàng đang nối vào hệ thống của họ, rất có thể bạn sẽ thấy nhiều thứ tương tự
    Chuyện này có phải ý hay không là một vấn đề khác, cá nhân tôi cực kỳ ghét nó, nhưng đây là cách đội bán hàng vận hành ngày nay. Nếu cố tước nó đi thì bạn sẽ phải đối đầu với cả tổ chức bán hàng
    Tôi còn ngạc nhiên hơn là những vụ xâm nhập kiểu này không xảy ra thường xuyên hơn
    Cơ sở dữ liệu mật khẩu thực tế của LastPass không bị ảnh hưởng
    Tôi không có liên hệ gì với bất kỳ tổ chức nào liên quan

    • I am more surprised that these breaches don't happen more often.
      Thực ra chúng xảy ra thường xuyên lắm

  • Có lẽ đã đến lúc LastPass đổi thương hiệu thành First0wned

  • Nếu là công ty vẫn tiếp tục dùng LastPass hoặc mới triển khai sau vụ lộ kho trước đó, thì có lẽ lần này họ sẽ chẳng bận tâm gì vì đây chỉ là dữ liệu CRM
    Ở mức độ nào đó tôi cũng đồng cảm với các công ty vẫn dùng LastPass. Khi tôi phải chuyển cả tổ chức từ LastPass sang 1Password thì đó là một khối lượng công việc khổng lồ và cực kỳ phiền
    Nhưng thật khó đồng cảm với những người đã chọn LastPass sau năm 2022

    • Phần không đáng kể ở đây là mức độ quan trọng của dữ liệu khá thấp
      Điều cốt lõi thực sự là dù nhỏ đến đâu thì với LastPass, họ vẫn phải làm tốt hơn thế này
      Một công ty lưu trữ mật khẩu phải tốt hơn mức này thì mới xứng đáng được tin cậy
  • Tôi đã bỏ LastPass từ lâu và chuyển sang BitWarden, nhưng giờ thì phần lớn tôi dùng ứng dụng Passwords của Apple