Các cuộc tấn công ‘MFA Bombing’ gần đây nhắm vào người dùng Apple

 (krebsonsecurity.com)
1 điểm bởi GN⁺ 2024-03-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Thông báo đặt lại mật khẩu của Apple xuất hiện lặp đi lặp lại với số lượng lớn, khiến một số người dùng phải chịu kiểu tấn công lừa đảo ở mức khó có thể sử dụng thiết bị bình thường
  • Sau đợt dồn dập thông báo, kẻ tấn công gọi điện với số người gọi giả mạo là Apple Support và giả làm quy trình bảo vệ tài khoản để yêu cầu mã dùng một lần
  • Trong trường hợp của Parth Patel, ngay cả bí danh không chính xác có trong PeopleDataLabs cũng bị lợi dụng; nếu giao mã đặt lại Apple ID, tài khoản có thể bị khóa và thiết bị bị xóa từ xa
  • Các trường hợp của Chris và Ken cho thấy số điện thoại đăng ký trên tài khoản có thể là đầu mối then chốt trong chuỗi tấn công, và chỉ riêng Apple Recovery Key không thể ngăn việc gửi thông báo đặt lại
  • Một biện pháp giảm thiểu được nhắc đến là dùng số VOIP ít người biết hoặc bí danh email, nhưng nếu bỏ số di động thật thì iMessage và Facetime có thể bị vô hiệu hóa

Tấn công làm mệt mỏi MFA bằng cách lạm dụng thông báo đặt lại mật khẩu của Apple

  • Gần đây nhiều khách hàng Apple đã gặp các cuộc tấn công MFA Bombing hoặc MFA fatigue
  • Cuộc tấn công lợi dụng hành vi trông giống một lỗi trong tính năng đặt lại mật khẩu của Apple
    • Hàng chục thông báo ở cấp độ hệ thống xuất hiện trên thiết bị Apple của nạn nhân
    • Người dùng phải nhấn Allow hoặc Don’t Allow trên từng thông báo
    • Nếu thông báo tiếp tục chồng chất, bản thân việc sử dụng thiết bị cũng có thể bị cản trở
  • Kẻ tấn công nhắm tới việc khiến người dùng mệt mỏi vì các yêu cầu lặp đi lặp lại và bấm nhầm Allow, hoặc chấp thuận chỉ để lấy lại khả năng dùng điện thoại
  • Sau khi tất cả thông báo bị từ chối, sẽ có cuộc gọi tiếp theo với số gọi đến được giả mạo để trông như từ Apple Support
    • Số điện thoại có thể hiển thị là số hỗ trợ khách hàng thật của Apple: 1-800-275-2273
    • Kẻ lừa đảo nói rằng tài khoản đang bị tấn công và cần xác minh mã dùng một lần

Trường hợp của Parth Patel: dồn dập thông báo rồi đến cuộc gọi hỗ trợ giả

  • Ngày 23/3, Parth Patel đã ghi lại trên Twitter/X chiến dịch lừa đảo nhắm vào mình
  • Thông báo đổ về cùng lúc trên Apple Watch, laptop và điện thoại của anh, và anh đã phải từ chối hơn 100 thông báo đặt lại mật khẩu
  • Sau khi từ chối hết các thông báo, iPhone của anh nhận một cuộc gọi trông như đến từ Apple Support
  • Khi kẻ lừa đảo được yêu cầu xác minh thông tin cá nhân của Patel, chúng đưa ra thông tin cá nhân chính xác nhưng lại không nói đúng tên thật
    • Cái tên mà kẻ lừa đảo nói ra là một bí danh sai mà Patel chỉ từng thấy trong báo cáo hồ sơ nền của PeopleDataLabs
    • Patel cho biết anh đã cố gắng xóa thông tin của mình khỏi nhiều trang tìm kiếm người, nhưng bí danh đó vẫn tiếp tục xuất hiện trong hồ sơ người tiêu dùng tại PeopleDataLabs
  • Mục tiêu của cuộc lừa đảo qua giọng nói là khiến mã đặt lại Apple ID được gửi tới thiết bị của người dùng, rồi lấy được mã dùng một lần đó
    • Nếu người dùng tiết lộ mã, kẻ tấn công có thể đặt lại mật khẩu tài khoản và khóa người dùng ra ngoài
    • Sau đó chúng cũng có thể xóa từ xa các thiết bị Apple của người dùng

Số điện thoại có thể là đầu mối của cuộc tấn công

  • Chris, chủ sở hữu một quỹ phòng hộ tiền mã hóa, cũng gặp một nỗ lực lừa đảo tương tự vào cuối tháng 2
  • Ngay sau khi từ chối thông báo đầu tiên bằng Don’t Allow, khoảng 30 thông báo khác đến liên tiếp, và các thông báo đặt lại tiếp tục xuất hiện trong nhiều ngày
  • Anh cũng nhận một cuộc gọi trông như từ Apple Support, nhưng đã cúp máy và nói sẽ tự gọi lại
    • Khi gọi cho Apple thật, Apple không thể xác nhận liệu vừa có cuộc gọi hỗ trợ nào hay không
    • Apple cho biết họ không chủ động gọi trước trừ khi khách hàng yêu cầu được liên hệ
  • Chris đã đổi mật khẩu, mua một iPhone mới tại Apple Store và tạo một tài khoản iCloud mới với địa chỉ email mới
  • Nhưng ngay cả khi đang ngồi tại Genius Bar của Apple, chiếc iPhone mới và tài khoản iCloud mới của anh vẫn tiếp tục nhận các thông báo hệ thống
    • Chris cho rằng yếu tố duy nhất không thay đổi ở tài khoản mới là số điện thoại đăng ký trên tài khoản
    • Anh nghi ngờ rằng để tạo nhanh các thông báo hệ thống của Apple, kẻ tấn công có thể cần biết số điện thoại của tài khoản Apple mục tiêu

Thông báo của Ken vẫn không dừng lại dù đã bật Recovery Key

  • Ken, người có kinh nghiệm trong ngành bảo mật, từ đầu năm nay đã nhận các thông báo hệ thống không mong muốn trên thiết bị Apple, nhưng khác với các trường hợp khác, anh không nhận cuộc gọi hỗ trợ Apple giả
  • Có lần anh bị đánh thức lúc 12 giờ 30 đêm bởi thông báo trên Apple Watch; trên Watch, Allow hiện trước, còn muốn nhấn Don’t Allow thì phải cuộn bánh xe
  • Chỉ riêng việc nhấn Allow không có nghĩa kẻ tấn công có thể đổi mật khẩu của Ken ngay
    • Khi nhấn Allow, thiết bị của Ken sẽ hiển thị mã PIN 6 chữ số cần thiết cho việc đổi mật khẩu
    • Các thông báo đặt lại lặp đi lặp lại dường như được dùng để khiến cuộc gọi mạo danh Apple sau đó trở nên thuyết phục hơn
  • Ken đã liên hệ bộ phận hỗ trợ Apple thật, và được một kỹ sư Apple cấp cao hướng dẫn rằng bật Apple Recovery Key sẽ làm các thông báo dừng lại
  • Apple Recovery Key là một tính năng tùy chọn để tăng cường bảo mật tài khoản Apple ID, gồm một mã ngẫu nhiên 28 ký tự
    • Khi kích hoạt, quy trình khôi phục tài khoản tiêu chuẩn của Apple sẽ bị vô hiệu hóa
    • Nếu mất recovery key và mất luôn mọi thiết bị Apple, người dùng có thể bị khóa tài khoản vĩnh viễn
  • Ken đã bật recovery key, nhưng cứ vài ngày một lần, các thông báo hệ thống không mong muốn vẫn tiếp tục xuất hiện trên mọi thiết bị
  • Kết quả thử nghiệm cho thấy ngay cả khi bật recovery key, luồng gửi thông báo đặt lại mật khẩu tới thiết bị Apple từ iforgot.apple.com vẫn không bị chặn
    • Trang này yêu cầu địa chỉ email và CAPTCHA
    • Sau đó nó hiển thị hai chữ số cuối của số điện thoại gắn với tài khoản
    • Nếu nhập các chữ số còn lại và gửi đi, thông báo hệ thống sẽ được gửi bất kể Recovery Key có được bật hay không

Câu hỏi về giới hạn tốc độ và các trường hợp MFA Bombing trước đây

  • Việc một hệ thống xác thực vẫn cho phép gửi hàng chục yêu cầu đổi mật khẩu trong vài phút dù người dùng chưa phản hồi yêu cầu đầu tiên đặt ra nhiều nghi vấn về thiết kế
  • Apple hiện vẫn chưa phản hồi đề nghị bình luận
  • Năm 2022, nhóm hack tội phạm LAPSUS$ đã dùng MFA Bombing và đạt hiệu quả trong các vụ xâm nhập Cisco, Microsoft và Uber
  • Microsoft bắt đầu áp dụng biện pháp đối phó là MFA number matching
    • Hệ thống hiển thị một dãy số cho người đang đăng nhập
    • Chủ tài khoản phải nhập dãy số đó vào ứng dụng Microsoft Authenticator trên thiết bị di động để hoàn tất xác minh đăng nhập
  • Nhà nghiên cứu bảo mật Kishan Bagaria cho rằng phía Apple có vấn đề
    • Năm 2019, anh đã báo cáo lỗi AirDoS cho Apple
    • Lỗi này có thể khiến lời nhắc chia sẻ tệp AirDrop hiển thị vô hạn trên các thiết bị iOS ở gần
    • Apple đã sửa lỗi này vào tháng 12/2019 và cảm ơn Bagaria trong thông báo bảo mật liên quan
    • Theo Bagaria, bản sửa của Apple là bổ sung giới hạn tốc độ nghiêm ngặt hơn cho các yêu cầu AirDrop
  • Có thể ai đó đã tìm ra cách vượt qua giới hạn tốc độ của yêu cầu đặt lại mật khẩu Apple, và đây có thể là một lỗi rate limiting của Apple cần được báo cáo chính thức

Các biện pháp giảm thiểu người dùng có thể thử

  • Tài khoản Apple dường như cần có số điện thoại, nhưng sau khi thiết lập tài khoản thì không nhất thiết đó phải là số di động
  • Kết quả thử nghiệm cho thấy Apple chấp nhận số VOIP như Google Voice
    • Đổi số điện thoại tài khoản sang một số VOIP ít được biết đến có thể là một biện pháp giảm thiểu
  • Tuy nhiên, nếu không bao gồm số di động thật thì iMessage và Facetime sẽ bị vô hiệu hóa trên thiết bị đó
    • Với những người muốn giảm toàn bộ bề mặt tấn công của thiết bị Apple, đây thậm chí có thể là một lợi thế
    • Các zero-click zero-day trên iMessage và Facetime đã nhiều lần bị các nhà cung cấp spyware khai thác
  • Hệ thống đặt lại mật khẩu của Apple dường như chấp nhận và tôn trọng bí danh email
    • Người dùng có thể thêm + và nhãn theo từng dịch vụ sau tên người dùng để tạo địa chỉ email riêng gắn với cùng một tài khoản
    • Ví dụ có thể dùng định dạng như krebsonsecurity+example@gmail.com
    • Với bí danh dành cho Apple, có thể nên dùng một nhãn ít lộ liễu hơn thay vì quá dễ đoán như +apple

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-28
Ý kiến trên Hacker News

  • Có một phần quan trọng bị bỏ sót trong bài viết và các bình luận hàng đầu: ngay cả khi bạn vô tình bấm Allow, kẻ tấn công cũng không thể đổi mật khẩu từ trình duyệt của chúng
    Khi bấm Allow trên thiết bị, một mã PIN 6 chữ số sẽ hiển thị trên thiết bị đó, và bằng mã PIN đó bạn có thể đổi mật khẩu trên chính thiết bị của mình. Bước cuối cùng của cuộc tấn công là kẻ tấn công gọi điện bằng số điện thoại Apple giả mạo và yêu cầu bạn đọc mã PIN 6 chữ số đó. Nếu bạn nói mã PIN đó cho kẻ tấn công trong cuộc gọi đến, chúng mới có thể đặt lại mật khẩu từ trình duyệt của chúng
    Khá bất ngờ là Krebs lại bỏ qua chi tiết nhỏ này trong blog bảo mật, khiến mọi chuyện như thể chỉ cần xác nhận là bạn có thể hoàn toàn trao quyền truy cập tài khoản khi đang ngủ

    • Ngay đoạn đầu của bài viết đã giải thích như sau:

      Assuming the user manages not to fat-finger the wrong button on the umpteenth password reset request, the scammers will then call the victim while spoofing Apple support in the caller ID, saying the user’s account is under attack and that Apple support needs to “verify” a one-time code.

    • Trong bài có đoạn này:

      Ken didn’t know it when all this was happening (and it’s not at all obvious from the Apple prompts), but clicking “Allow” would not have allowed the attackers to change Ken’s password. Rather, clicking “Allow” displays a six digit PIN that must be entered on Ken’s device — allowing Ken to change his password. It appears that these rapid password reset prompts are being used to make a subsequent inbound phone call spoofing Apple more believable.

    • Nói đúng và cũng đáng biết, nhưng dù vậy có vẻ cả những người đủ tỉnh táo cũng vẫn có thể bị lừa. Đây không chỉ là vấn đề của người già 80 tuổi
      Ngay cả nếu không bị lừa, vẫn có một phiền toái nghiêm trọng mà Apple có thể loại bỏ chỉ bằng cách áp giới hạn tần suất yêu cầu cho những yêu cầu này. Không hiểu vì sao lại có thể gửi hàng trăm yêu cầu trong thời gian ngắn

  • Gọi là “gần đây” thì hơi mơ hồ
    Năm 2021, muộn nhất là 2022, tôi và vợ đã gặp chuyện tương tự cách nhau vài ngày. Ban đầu là vài lần mỗi ngày, sau đó tăng lên thành mỗi giờ một lần. Hình như cả hai chúng tôi cũng vài lần nhận được SMS trông như đến từ Apple
    Ngay khi tần suất tăng vọt, chúng tôi thiết lập khóa khôi phục cho cả hai tài khoản; vốn dĩ đây cũng là biện pháp đã định làm vì không muốn Apple, hoặc ai đó gây sức ép/chiếm quyền Apple, có thể truy cập tài khoản của chúng tôi. Việc này chặn cuộc tấn công ngay lập tức
    Vì lý do tương tự, tôi bật Advanced Data Protection ngay khi tính năng này ra mắt và cũng tắt truy cập web. Chỉ các thiết bị tin cậy mới có thể xem dữ liệu, và việc đăng ký thiết bị mới cũng chỉ có thể thực hiện từ thiết bị tin cậy

    • Tôi không biết Recovery Key là gì, hóa ra là tài liệu này: https://support.apple.com/en-us/109345
      Cái này cũng khá đáng sợ. Nếu mất khóa thì không ai có thể giúp bạn khôi phục tài khoản
    • Việc vấn đề dừng lại sau khi dùng khóa khôi phục rất thú vị, nhưng hiện giờ có vẻ nó không còn làm được vai trò đó
      Theo bài viết: “Ken said he enabled a recovery key for his account as instructed, but that it hasn’t stopped the unbidden system alerts from appearing on all of his devices every few days.
      KrebsOnSecurity tested Ken’s experience, and can confirm that enabling a recovery key does nothing to stop a password reset prompt from being sent to associated Apple devices.”
    • Bản thân phương thức này không mới, nhưng có vẻ đây là một chiến dịch gần đây dùng nó trên nhiều người. Có khả năng ai đó vừa lấy được danh sách mật khẩu bị hack từ một kho dữ liệu rò rỉ gần đây và đang rà các tài khoản Apple trong đó
    • Nên mua vài chiếc YubiKey, ít nhất là ba chiếc, rồi dùng chúng để xác thực Apple ID thay vì kiểu xác thực đa yếu tố bằng push ngu ngốc
      https://support.apple.com/en-gb/HT213154
    • Thật ngạc nhiên là những thứ như thế này đương nhiên phải có giới hạn tần suất. Sau khoảng hai lần thử, nên tăng dần thành mỗi 15 phút một lần, rồi một giờ, 4 giờ, một ngày. Cứ xử lý như các lần đăng nhập sai là được

  • Nếu sau khi bấm Allow mà có thể đặt lại mật khẩu từ thiết bị khác thì thiết kế thông báo đó thật tệ hại. Câu chữ ghi rõ là Use this iPhone to reset, nên người bấm Allow hẳn sẽ nghĩ đây là luồng đặt mật khẩu mới trên chính thiết bị đó
    Nhưng nếu nó cũng hiện trên Apple Watch, điều đó có nghĩa đây không phải chỉ là phản chiếu thông báo cuộc gọi đơn giản bỏ qua chế độ im lặng; thật khó tưởng tượng ý định lại là bấm Allow trên đồng hồ rồi nhập mật khẩu bằng bàn phím của nó

    • Tôi cho rằng riêng việc bấm Allow không có rủi ro. Sau đó vẫn còn xác thực 2 bước và còn phải chọn mật khẩu mới. Rủi ro hoàn toàn đến từ cuộc gọi điện thoại, nơi chúng có vẻ muốn moi mã xác thực 2 bước
    • Tính năng này đã thực sự cứu nguy khi mẹ tôi 90 tuổi quên mật khẩu iMac. Tôi cũng đã quên mất là mình từng tạo một tài khoản quản trị viên thứ hai
      Dù bị khóa trên iMac, bà vẫn vào được iPad nên có thể đặt lại. Bà cũng quên cả PIN iPad, nhưng may là tìm thấy chỗ đã ghi lại

  • Từ một thời điểm nào đó, tôi nghĩ bản thân việc có thể làm hiện các prompt như thế này trên thiết bị Apple đã là một vấn đề. Những thứ như prompt thiết lập thiết bị mới dựa trên Bluetooth từng gây chú ý năm ngoái cũng tương tự
    Tất nhiên việc đặt lại mật khẩu phải có khả năng thực hiện, nhưng theo bài viết thì có vẻ có thể gửi 30 yêu cầu đặt lại mật khẩu trong một khoảng thời gian ngắn
    Rốt cuộc có lý do gì để chuyện này xảy ra trong một tình huống không mang tính độc hại?

    • Không có. Chỉ là họ chưa thêm logic kiểm tra như vậy mà thôi. Nhưng điều đó cũng không nhất thiết đồng nghĩa với việc phải chỉ trích Apple thật nặng nề
      Nhìn lại thì có vẻ hiển nhiên, nhưng giữa sprint, OKR/KPI và tài liệu thăng chức, những tính năng kém hào nhoáng như thế này rất dễ bị lọt qua

  • Tôi tò mò không biết còn bao lâu nữa thì một mục đích khác của những cuộc gọi kiểu này sẽ trở thành bước thu thập đủ mẫu để nhân bản giọng nói một cách thuyết phục

    • Đã có một biến thể là khiến ai đó nói “yes”, rồi dùng bản ghi đó làm “bằng chứng” rằng họ đã đồng ý với một hợp đồng nào đó
    • Tôi không nghĩ nói “hello?” 100 lần là có thể nhân bản giọng nói. Nhưng việc nhân bản giọng nói cũng không nhất thiết cần đến bom xác thực đa yếu tố
      Chỉ cần gọi điện với một lý do có vẻ hợp lý và khiến họ nói chuyện dài là được. Ví dụ như “tôi là tài xế Uber/Doordash”, “tôi gọi từ bệnh viện/trường học/nhà trẻ”
    • Vì vậy đây lại là một lý do nữa để không xác thực người dùng bằng cuộc gọi hay số điện thoại. Cái gọi là nhận diện bằng giọng nói hay voice ID cũng có thể bị phá dễ dàng bằng công nghệ nhân bản giọng nói cao cấp

  • Tôi hơi rối. Nếu bấm Allow thì chính xác chuyện gì xảy ra tiếp theo? Không rõ Apple sẽ hiển thị biểu mẫu đặt lại mật khẩu cho người đang ở trang iForgot, hay chỉ hiển thị trên thiết bị

    • Có vẻ trên thiết bị sẽ hiển thị mã xác minh. Sau đó kẻ lừa đảo sẽ gọi điện để cố lấy mã đó

  • Có đoạn nói rằng trên iPhone nó hiển thị như cuộc gọi từ Apple Support, và số cũng là số hỗ trợ khách hàng thật của Apple: 1-800-275-2273
    Tôi cũng từng gặp đúng một lần, hai ngày sau khi đặt mua một chiếc MacBook mới trên Apple Store trực tuyến. Vì đang chờ giao hàng nên suýt nữa tôi đã nghe máy, nhưng thay vào đó tôi tự gọi cho Apple Support để hỏi xem họ vừa gọi cho tôi không, và được trả lời là không

    • Tôi thắc mắc là bạn đặt hàng ngay sau khi mẫu mới ra mắt, hay việc họ gọi ngay sau đơn hàng chỉ tình cờ khớp may mắn

  • Instagram cũng có cùng vấn đề. Thật vô lý khi các công ty lớn như vậy lại không giới hạn tần suất trong luồng khôi phục tài khoản

    • Vấn đề khi thêm giới hạn tần suất, đặc biệt là giới hạn toàn cục theo từng người dùng, là lần này nó sẽ tạo ra một vấn đề từ chối dịch vụ mới, khiến mọi người không thể khôi phục tài khoản

  • Từ vài ngày trước tài khoản LinkedIn của tôi cũng bắt đầu nhận những thứ như thế này. Cứ vài giờ lại có email chứa liên kết đăng nhập ma thuật, trông như được gửi từ nhiều khu vực khác nhau trên thế giới và có vẻ hợp pháp

    • Hôm qua tôi cũng gặp và ban đầu khá hoảng, nhưng sau đó biết rằng chỉ cần biết email liên kết với tài khoản LinkedIn là có thể yêu cầu mật khẩu dùng một lần. Vì vậy không phải mật khẩu đã bị lộ
      Dù vậy tôi vẫn đổi mật khẩu và email chính, đồng thời gỡ việc công khai email trong phần cài đặt quyền riêng tư của LinkedIn
    • Tôi cũng nhận được kiểu này. Vì tôi đã dùng nhiều hình thức xác thực hai bước như TOTP và Passkey, nên sẽ tốt nếu có thể tắt tính năng này trong tài khoản
    • Trường hợp của tôi là Uber

  • Tôi đã không thích MFA dạng push ngay từ khi nó mới xuất hiện
    Nhập một mã thì khó đến mức nào chứ? Cuối cùng, khi cố chặn push bombing, ta lại quay về với thông báo push yêu cầu nhập mã

    • Với MFA của Apple ID, có thể dùng HSM thay thế. Chính vì mục đích này mà tôi đặt 3 YubiKey ở nhiều nơi
      https://support.apple.com/en-gb/HT213154
    • Ít nhất với đăng nhập iCloud, còn đặt lại mật khẩu có như vậy không thì tôi lười kiểm tra, nhưng bấm Allow không cho phép đăng nhập ngay, mà chỉ hiển thị mã 6 chữ số cần nhập khi đăng nhập