Lỗ hổng clickjacking trên WhatsApp có thể bị dùng cho tấn công phishing

• Đã phát hiện một lỗ hổng phishing trong đó tin nhắn WhatsApp hiển thị liên kết và bản xem trước trông như trang hợp lệ, nhưng cú nhấp thực tế lại đưa người dùng đến trang của kẻ tấn công
• Nguyên nhân nằm ở cấu trúc trong đó liên kết trong nội dung tin nhắn và dữ liệu xem trước được gửi riêng biệt, đồng thời việc loại bỏ matchedText có thể tạo ra sự không khớp ở bản xem trước
• Ký tự Right-To-Left Override U+202E đảo chiều hiển thị URL, khiến tên miền thực tế trông như tên miền hợp lệ
• Kẻ tấn công có thể chuẩn bị tên miền mirror của mục tiêu giả mạo, sau đó giữ nguyên bản xem trước của trang gốc và chỉ thay đổi giá trị text để đánh lừa nạn nhân
• Meta cho biết họ có thể điều chỉnh động logic chuẩn hóa URL, còn người dùng nên sao chép liên kết và kiểm tra địa chỉ thực trước khi nhấp

---

Điểm nơi bản xem trước liên kết WhatsApp và liên kết thực bị tách rời

• Nhà nghiên cứu đã gửi một liên kết webhook.site cho bạn bè để kiểm tra liệu người nhận tin nhắn WhatsApp có phát sinh HTTP request khi render bản xem trước liên kết hay không
• HTTP request chỉ phát sinh một lần ở phía người gửi, xác nhận rằng người nhận không render liên kết riêng
• Vì hành vi này, nhà nghiên cứu cho rằng tin nhắn WhatsApp được gửi kèm cả liên kết và thông tin xem trước, rồi thử nghiệm xem có thể làm cho hai phần này khác nhau hay không

Issue #1: Bản xem trước liên kết không khớp

• Nhà nghiên cứu đã cố chỉnh sửa trực tiếp tin nhắn WhatsApp Web qua proxy, nhưng do E2EE của WhatsApp nên khó có thể chỉnh sửa đơn giản bằng các công cụ như Burp Suite
• Thay vào đó, họ đặt breakpoint trong JavaScript ngay trước khi tin nhắn được mã hóa và gửi qua WebSocket để kiểm tra đối tượng tin nhắn
• Trong đối tượng tin nhắn, nội dung liên kết và thông tin xem trước tồn tại dưới các thuộc tính riêng biệt
  • text: nội dung tin nhắn
  • canonicalURL: tên miền hiển thị ở phần dưới của bản xem trước
  • matchedText: có vẻ là giá trị được so sánh với canonicalURL, và được kiểm tra xem giá trị này có xuất hiện trong text hay không
• Khi thay text thành google.com trong đối tượng tin nhắn dành cho instagram.com, bản xem trước biến mất và chỉ còn liên kết Google
• Khi xóa thuộc tính matchedText, có thể tạo một tin nhắn không khớp trong đó liên kết thực và bản xem trước khác nhau

Issue #2: Ngụy trang hiển thị liên kết bằng U+202E

• Để nội dung liên kết thực không bị lộ, nhà nghiên cứu fuzzing xem ký tự Unicode có làm thay đổi cách hiển thị văn bản hay không
• U+202E là ký tự Right-To-Left Override, khiến văn bản được hiển thị ngược thứ tự cho người dùng
• Nếu chỉ dùng U+202E, hình dạng liên kết trông gượng gạo và có vẻ ít khả năng được nhấp, nên cần cấu tạo một chuỗi đảo ngược để trông như URL hợp lệ

Cách cấu tạo URL mirror

• Mục tiêu là tạo một URL mà khi bị đảo ngược sẽ trông như https://instagram.com
• Chuỗi đảo ngược đơn giản sẽ là moc.margatsni//:sttph, nhưng các TLD như .margatsni không thể đăng ký
• Giải pháp là dùng một TLD có thể đăng ký thực tế sao cho nó trông như subdomain
  • Ví dụ, nếu dùng TLD của Hà Lan .nl, có thể tạo một chuỗi trông như ln.instagram.com
• Vì URL phải trông như bắt đầu bằng https://, nhà nghiên cứu thêm //:sptth ở phía sau như một đường dẫn hợp lệ
• Kết quả là https://moc.margatsni.nl//:sptth khi kết hợp với U+202E có thể trông như https://ln.instagram.com//:sptth
• Nhà nghiên cứu gọi kỹ thuật này là 2K2E

Luồng tấn công

• Kẻ tấn công mua tên miền mirror của trang muốn giả mạo
  • Ví dụ: để trông như ln.instagram.com, kẻ tấn công mua moc.margatsni.nl
• Trước tiên, tạo một tin nhắn chứa liên kết tên miền gốc để lấy bản xem trước của trang đó
  • Trong đối tượng ví dụ, text, matchedText, canonicalUrl đều là https://instagram.com/
  • Các giá trị liên quan đến bản xem trước như description, title, jpegThumbnail, thumbnailDirectPath cũng được bao gồm
• Sau đó xóa matchedText và đổi giá trị text thành dạng \u202ehttps://moc.margatsni.nl//:sptth
• Tin nhắn cuối cùng hiển thị bản xem trước Instagram, nhưng khi nhấp có thể chuyển đến tên miền do kẻ tấn công chuẩn bị

Phản hồi của Meta và so sánh với các nền tảng khác

• Meta trả lời rằng do họ hỗ trợ nhiều nền tảng và môi trường, cách chuẩn hóa URL theo từng nền tảng có thể khác với logic phía máy chủ
• Meta cho biết họ có hệ thống có thể điều chỉnh động logic chuẩn hóa URL khi xảy ra spam và lạm dụng thực tế
• Nhà nghiên cứu đánh giá rằng Meta dường như không chủ động xử lý vấn đề bảo mật này, mà chỉ muốn phản ứng khi hệ thống phát hiện là spam
• X, TikTok và Pinterest khác với WhatsApp ở chỗ họ có xử lý làm sạch đối với ký tự U+202E

Cách giảm thiểu mà người dùng có thể tự kiểm tra

• Liên kết WhatsApp khó có thể tin cậy chỉ dựa trên hình thức hiển thị
• Để tránh phishing 2K2E, người dùng nên sao chép liên kết trước khi nhấp và kiểm tra địa chỉ thực trong bản xem trước clipboard
• Bản xem trước clipboard có thể hiển thị địa chỉ liên kết ở trạng thái đã được làm sạch ký tự U+202E
• Nhà nghiên cứu sau đó cũng phát hiện thêm các dịch vụ khác dễ bị 2K2E do thiếu xử lý làm sạch phù hợp

[GN⁺]

Ý kiến trên Hacker News

• Đây là một tổ hợp lạm dụng tính năng khá khéo, nhưng có lẽ tác động bảo mật tổng thể là thấp
  Ngay cả trong trường hợp tốt nhất, nó cũng chỉ khiến người nhận mở liên kết trong trình duyệt; nếu kẻ tấn công không phải là cảnh sát hay cơ quan tình báo, thường sẽ cần một đòn tấn công tiếp theo kiểu khai thác phần mềm chưa được vá trên thiết bị
  Về mặt kỹ thuật, gọi chính xác đây là clickjacking thì hơi khó. Clickjacking thường chỉ một kỹ thuật rất cụ thể: chồng một khung HTML vô hình lên trên nội dung khác
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Tôi cũng sẽ không gọi đây là clickjacking. Clickjacking thật sự là kỹ thuật khiến nạn nhân thực hiện hành động liên quan đến tài khoản mà họ không hay biết; chỉ mở một liên kết ngoài ý muốn thì không nghiêm trọng đến mức đó
  • Nếu liên kết đó hiển thị màn hình đăng nhập giống hệt Instagram, tôi tự hỏi có bao nhiêu phần trăm người dùng sau khi bị nhầm một lần trong phần xem trước của WhatsApp rồi vẫn sẽ kiểm tra lại URL

• Mọi người đều chỉ tập trung vào ký tự phải-sang-trái của UTF, nhưng Meta ít nhất nên thừa nhận vấn đề rằng URL trong phần xem trước có thể khác với URL trong tin nhắn
  Tôi hiểu đây là hành vi để bung URL rút gọn, nhưng chắc chắn Meta và WhatsApp có thể triển khai một cách né tránh thông minh nào đó

  • Không. Với mã hóa đầu cuối, phần xem trước phải được tạo ở phía người gửi hoặc người nhận. Nếu người nhận tạo phần xem trước thì IP sẽ bị rò rỉ. Cuối cùng chỉ còn cách loại bỏ tính năng xem trước

• Clickjacking là kiểu bạn nghĩ mình đang nhấp vào một phần tử nào đó, nhưng thực ra một phần tử khác thường trong suốt nằm chồng bên trên đã chặn sự kiện nhấp
  Nếu đặt focus vào lớp bên dưới đang hiển thị và phát hiện sự kiện onblur, kẻ tấn công có thể biết được cú nhấp dù người dùng không nhận được sự kiện
  Thứ OP tìm ra rất hay, nhưng không phải clickjacking. Trước đây tôi cũng từng dùng ký tự RTL để làm cho một tệp trình bảo vệ màn hình — tức một tệp thực thi bình thường trên Windows chỉ khác phần mở rộng — trông như tài liệu Word. Hình như là để trêu bạn bè hoặc giáo viên, nhưng tôi không nhớ rõ lý do
  OP đã đi xa hơn một bước khi tìm ra cách khiến cách hiển thị thay đổi trên một hệ thống khác. Đây không phải là clickjacking, vì người dùng không nhầm về việc mình nhấp vào phần tử nào, mà nhầm về liên kết sẽ dẫn tới đâu; trang Wikipedia được liên kết ở đầu bài cũng xác nhận như vậy
  Tôi chưa từng thấy clickjacking bị khai thác trong thực tế, nhưng tôi nghĩ cách OP tìm ra có thể bị lạm dụng
  Thành thật mà nói, tôi đã từ bỏ kỳ vọng rằng người dùng có thể phân biệt domain cuối cùng khi nhấp vào liên kết từ lâu rồi. Đa số không hiểu chính khái niệm đó, phần còn lại thì cũng khó phân biệt
  Ngay cả những người nghĩ rằng mình phân biệt được cũng sẽ nản nếu mọi liên kết đều dẫn tới những nơi như sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. Hằng ngày chúng ta đang huấn luyện mọi người bấm vào các liên kết rác đáng ngờ bị làm rối để theo dõi, mà chẳng ai bận tâm

• Một màn hack rất hay. Vấn đề thật sự không phải là WhatsApp hay ký tự đảo chiều của Unicode, mà là URL khó hiểu
  Chỉ với ví dụ đơn giản như visa.securesite.com thôi cũng đã lừa được rất nhiều người. Tôi chưa thấy giải pháp tốt nào trong tương lai gần

  • Trường hợp cụ thể này gần với xử lý làm sạch kém hơn, vì nó chủ động đánh lừa khi người dùng cố hiểu thứ mình sẽ nhấp vào
    Sự nhầm lẫn nói chung quanh hostname và domain là vấn đề khó hơn, nhưng các trình duyệt đã cố giảm nhẹ phần nào bằng cách nhấn mạnh phần tên miền. Như hầu hết kỹ thuật phishing, cuối cùng có lẽ passkey sẽ chấm dứt nó

• RTL từ khi tồn tại đến nay đã là nguồn của vô số lỗ hổng bảo mật. Tôi không hiểu vì sao hệ điều hành không có thiết lập tắt toàn bộ RTL để những người không biết các ngôn ngữ đó khỏi bị phơi nhiễm rủi ro mà không nhận được lợi ích gì

  • Không chỉ ở cấp hệ điều hành; mọi widget hệ điều hành hiển thị văn bản đều nên có tùy chọn như vậy. Bao gồm cả Android TextView
    Mặc định nên vô hiệu hóa mọi đường vòng văn bản hai chiều, trừ khi nhà phát triển đã xem xét rõ ràng và cho phép một phạm vi văn bản cụ thể
    Không hợp lý khi mặc định biến toàn bộ stack render văn bản thành dễ tổn thương chỉ nhân danh việc hỗ trợ chưa tới 1% dân số thế giới

• Thật thất vọng khi Meta không sửa vấn đề này và cũng quyết định không trả bug bounty cho nhà nghiên cứu này

  • Đầu năm nay tôi đã báo cáo một vấn đề tương tự cho Google, nhưng bị từ chối với lý do “chỉ có thể xảy ra thông qua kỹ thuật xã hội” và “chúng tôi cho rằng việc khắc phục sẽ không làm người dùng bớt dễ bị tấn công một cách có ý nghĩa”
    Tôi sẽ không nói chi tiết ở đây, nhưng do cách Google Search đôi khi viết lại URL, kẻ tấn công có thể đánh lừa URL thật
    Tốt nhất là đừng bao giờ tin URL được hiển thị trong website và ứng dụng
  • Chắc họ quá bận gửi lời đe dọa pháp lý tới các dự án OSS
  • Có lẽ nhà nghiên cứu đã không nói rõ muốn họ sửa gì, chẳng hạn yêu cầu chặn ký tự RTL, và Meta có thể đã hiểu thành yêu cầu sửa mọi URL gây hiểu nhầm. Điều đó trên thực tế là bất khả thi
  • Họ sẽ sửa thôi. Chỉ là sẽ không thưởng cho thợ săn bounty

• Điểm “đúng như dự đoán, liên kết và phần xem trước được gửi riêng!” mới là vấn đề thiết kế UI lớn hơn. Tại sao người dùng bình thường lại phải so sánh liên kết với phần xem trước để được an toàn?

  • Đây là một đánh đổi về bảo mật. Để cung cấp tính năng hữu ích là xem trước liên kết, có vài lựa chọn
    1. Tạo ở phía người gửi. Nhược điểm là có thể bị giả mạo
    2. Tạo ở phía người nhận. Nhược điểm là IP người nhận bị rò rỉ
    3. Tạo thông qua bên thứ ba. Nhược điểm là thông tin bị rò rỉ cho bên thứ ba
       Nhìn chung tôi cho rằng phương án 1 là tốt nhất. Dù sao người gửi cũng có thể “giả mạo” toàn bộ tin nhắn của chính mình, và việc đưa phần xem trước vào như một phần của tin nhắn cũng không khác nhiều
       Vấn đề ở đây là không rõ ràng rằng nội dung này đến từ người gửi. Vì nó được hiển thị như một bong bóng chat riêng, tôi nghĩ 99% người dùng sẽ không biết nội dung đó do người gửi cung cấp
       Hơn nữa, dù sao URL mới là cốt lõi. Nếu bạn nhấp vào một URL do kẻ tấn công kiểm soát, kẻ tấn công có thể hiển thị bất cứ thứ gì họ muốn trong phần xem trước. Vì vậy lợi ích của việc ép phần xem trước phải “thật” là rất nhỏ
       Phương án 3 cũng có thể ổn. Đặc biệt nếu triển khai kiểu double-blind, bạn có thể kết nối tới một bên rồi để bên đó chuyển tiếp sang bên thứ hai. Khi đó bên thứ nhất thấy IP, bên thứ hai thấy đích đến, nhưng nếu không thông đồng thì không bên nào thấy cả hai cùng lúc
       Tuy nhiên lợi ích tương đối nhỏ so với việc xây dựng và duy trì hạ tầng ở mức đó

• Tôi thích việc ở cuối bài họ phân loại chuyện này là reverse engineering

• Đây không phải clickjacking. Clickjacking là khi kẻ tấn công chặn cú nhấp để khiến người dùng thực sự nhấp vào một mục tiêu khác mà họ không định nhấp hoặc không nhận ra
  Codepoint RTL khiến văn bản chảy từ phải sang trái là một tính năng quốc tế hóa, và dùng nó để làm người khác rối trí không phải là lỗ hổng mới