Với việc Twitter vô hiệu hóa xác thực hai yếu tố trong tin nhắn văn bản, tôi nghĩ sẽ rất thú vị nếu tìm hiểu sâu về cách hoạt động của gian lận SMS và cách các nhà phát triển ứng dụng có thể bảo vệ chống lại nó.
Đó là một câu chuyện hấp dẫn về những khuyến khích sai lầm, quy định thiển cận và sự khéo léo về kỹ thuật.
Nào cùng đào vào bên trong! 👇
Để bắt đầu, hãy tóm tắt thông báo gần đây của Twitter:
Nói một cách đơn giản, điều này có nghĩa là chỉ những người dùng phiên bản Twitter trả phí mới nhận được mã được gửi đến điện thoại của họ trong khi đăng nhập.
Chìa khóa để hiểu gian lận SMS là hiểu rằng một số số là cao cấp . Nếu bạn muốn gọi hoặc gửi SMS đến số này, bạn sẽ phải trả một số tiền — thường là hàng chục xu — và chủ sở hữu của số đó sẽ nhận được một phần trong số hàng chục xu đó cho chính họ.
Chủ sở hữu của những số điện thoại này thường cung cấp các dịch vụ hợp pháp tốn tiền để cung cấp và mang lại giá trị cho người dùng của họ, chẳng hạn như bỏ phiếu qua điện thoại, hẹn hò và hỗ trợ kỹ thuật.
Tuy nhiên, những con số này có thể được đánh bạc để kiếm lợi nhuận dễ dàng 🤑
Một diễn viên tồi, hãy gọi anh ta là Bob , nắm giữ một số số điện thoại cao cấp[1]. Bob có thể là một hacker, hoặc có thể là một nhà điều hành mạng điện thoại di động đã trở nên tồi tệ.
Bob tìm thấy một dịch vụ web sẽ gửi tin nhắn văn bản đến các số điện thoại cao cấp của anh ấy. Các tin nhắn này có thể là mã xác thực hai yếu tố, mật khẩu dùng một lần hoặc bất kỳ tin nhắn văn bản nào khác được gửi tới người dùng như một phần của dịch vụ (ví dụ: partiful.com gửi lời nhắc sự kiện qua SMS).
Bob tìm cách khiến dịch vụ gửi hàng nghìn tin nhắn SMS đến các số điện thoại cao cấp của anh ấy. Điều này có thể rất dễ dàng. Dịch vụ giao diện người dùng có thể dễ thao tác và các điểm cuối phụ trợ có thể không được bảo vệ và dễ dàng thiết kế ngược.
Tệ hơn nữa, nhiều dịch vụ sử dụng điểm cuối được tiêu chuẩn hóa để gửi SMS. Điều này giúp Bob dễ dàng tìm thấy các trang web để tấn công hơn rất nhiều. Ví dụ: nếu dịch vụ sử dụng bên thứ ba để xác thực người dùng và gửi mã 2FA hoặc mã OTP, chẳng hạn như Auth0, thì điểm cuối để gửi SMS hầu như đã được biết: tất cả những gì Bob cần làm là tìm ra cách khám phá Auth0 ID cho một dịch vụ web (khá dễ dàng, vì giao diện người dùng của dịch vụ web đưa ra yêu cầu chứa ID này), sau đó chúng có thể tấn công tất cả các trang web sử dụng dịch vụ của bên thứ ba đó.
Cuối cùng, Bob yêu cầu dịch vụ gửi hàng nghìn tin nhắn SMS đến các số điện thoại cao cấp của mình. Dịch vụ web lỗ 💵💵💵 và Bob lãi.
Không có viên đạn bạc nào để ngăn gian lận SMS. Nhưng đây là một vài ý tưởng có thể hoạt động:
Nếu sử dụng dịch vụ của bên thứ ba để xác thực người dùng, chẳng hạn như Auth0, bạn có thể làm xáo trộn điểm cuối được sử dụng để gửi SMS. Mặc dù điều này sẽ không ngăn chặn hoàn toàn một cuộc tấn công, nhưng nó sẽ khiến việc phát hiện ra rằng một cuộc tấn công có thể xảy ra trở nên khó khăn hơn nhiều.
Tương tự như cách một tên trộm xe đạp nhắm mục tiêu vào những chiếc xe đạp dễ ăn cắp nhất, một hacker giỏi sẽ chuyển sang các dịch vụ web dễ hack hơn. Linh cảm của tôi là cách tiếp cận này sẽ hoạt động đủ tốt cho phần đuôi dài của ứng dụng.
Chặn tất cả các yêu cầu từ các IP bắt nguồn từ nhà cung cấp đám mây, ISP lừa đảo hoặc các yêu cầu sơ sài khác. Điều này khá đơn giản để thực hiện — có nhiều dịch vụ cho phép bạn đánh giá chất lượng của một địa chỉ IP — và có thể sẽ rất hiệu quả.
Thêm giới hạn tốc độ dựa trên IP vào điểm cuối gửi SMS để chặn cuộc tấn công của Bob. Nếu được thiết lập chính xác, điều này sẽ không ảnh hưởng đến người dùng hợp pháp. Tuy nhiên, điều này chỉ hoạt động chống lại một cuộc tấn công đơn giản. Nếu Bob thiết kế cuộc tấn công của mình để gửi yêu cầu từ nhiều địa chỉ IP — một cuộc tấn công phân tán — thì điều này sẽ không hiệu quả.
Chỉ gửi tin nhắn SMS đến một số điện thoại cụ thể một số lần trước khi chặn số điện thoại đó trong một khoảng thời gian tạm dừng. Chúng tôi có thể làm điều này ở giao diện người dùng, nhưng nếu Bob quyết tâm, anh ta có thể tìm ra điểm cuối phụ trợ để tấn công thay thế. Chặn số điện thoại trên phần phụ trợ khó hơn: nó yêu cầu lưu giữ bản ghi số điện thoại và các lần đăng nhập gần đây của họ[2].
Buộc người dùng giải CAPTCHA trước khi gửi SMS cho họ. Mặc dù cách tiếp cận này hoạt động tốt trong việc ngăn chặn những kẻ tấn công — việc giải CAPTCHA rất khó và tốn kém khi thực hiện trên quy mô lớn — nhưng nó lại làm giảm trải nghiệm của người dùng đối với dịch vụ.
Xác định và chặn các số điện thoại trả phí , sử dụng libphonenumber . Trong khi điều này có vẻ hứa hẹn, tôi không biết dữ liệu đáng tin cậy như thế nào và phương pháp này hiệu quả đến mức nào.
Chỉ gửi tin nhắn văn bản đến các tài khoản trả phí. Đây là cách tiếp cận mà Twitter đã thực hiện. Đó không phải là một lựa chọn tồi, nhưng như bạn có thể thấy từ danh sách trên, có nhiều cách tiếp cận khác mà bạn có thể thực hiện.
Chặn các nhà khai thác mạng điện thoại di động có số lượng người dùng gian lận cao. Điều này sẽ chặn các nhà khai thác mạng rõ ràng là tồi, nhưng sẽ không hoạt động tốt nếu mạng có nhiều người dùng hợp pháp.
Thay vào đó, hãy sử dụng WhatsApp để gửi tin nhắn. WhatsApp miễn phí không giống như SMS, nhưng không phải tất cả người dùng trên toàn thế giới đều sử dụng WhatsApp[3].
Một giải pháp tốt sẽ tận dụng đủ các cách tiếp cận ở trên, ưu tiên đầu tư thời gian và hiệu quả, cho đến khi những kẻ tấn công chuyển sang các mục tiêu dễ dàng hơn.
Tôi đã có một số kinh nghiệm cá nhân khi thực hiện các biện pháp trên và có một hoặc hai câu chuyện để chia sẻ về cách nhóm của tôi xử lý bụi phóng xạ. Nhưng đó là câu chuyện của một thời điểm khác… 👨💻
Điều này đưa tôi đến điểm cuối cùng của tôi:
IMO, Twilio — API SMS chiếm ưu thế — có cơ hội rất lớn để cung cấp tính năng chống gian lận SMS dưới dạng tiện ích bổ sung (miễn phí? 🙏) cho API tiêu chuẩn của họ.
Vì Twilio có dữ liệu về các số điện thoại và nhà mạng lừa đảo trên tất cả các tài khoản của họ nên Twilio ở vị trí duy nhất để chặn các số xấu và nhà mạng một cách nhanh chóng — trước khi chúng trở thành vấn đề lớn đối với nhiều dịch vụ web.
Twilio thậm chí có thể phát hiện hoàn toàn các số điện thoại không hợp lệ bằng cách sử dụng Silent Network Auth — một cơ chế xác thực thế hệ tiếp theo — và có vẻ như tiện ích này nên được chia sẻ giữa những người dùng của họ.
Tôi muốn nghe bất kỳ suy nghĩ, ý tưởng và cách tiếp cận nào khác mà mọi người đã sử dụng — vui lòng chia sẻ bằng cách viết nhận xét bên dưới và tất cả chúng ta đều có thể học hỏi.
Vậy là xong ngay bây giờ — hãy bảo vệ các điểm cuối đó và chúc bạn có một tuần tuyệt vời!
Có một cuộc thảo luận tuyệt vời trên HackerNews.
[1] Lưu ý rằng những số điện thoại cao cấp này thậm chí không cần phải hoạt động: chúng không cần được kết nối với thẻ SIM đang hoạt động và không cần đăng ký với điện thoại. Miễn là chúng có thể được định tuyến đến, chúng có thể được sử dụng trong cuộc tấn công này.
[2] Tôi tò mò liệu có cấu trúc dữ liệu và thuật toán tốt để làm cho điều này hiệu quả và hoạt động trên quy mô lớn hay không. Hãy chia sẻ nếu bạn biết về một!
[3] Tín dụng cho @csharpminor trên HN vì đề xuất của họ.
Tôi là Apu , CTO của koodos và là một kỹ sư.
Bài đăng này ban đầu xuất hiện trên blog cá nhân của tôi - hãy đăng ký để có nhiều lượt thích hơn!