Bảo mật mật khẩu chỉ mạnh như chính mật khẩu đó. Thật không may, chúng tôi thường được nhắc nhở về mối nguy hiểm của mật khẩu yếu, được sử dụng lại và bị xâm nhập với các vi phạm an ninh mạng nghiêm trọng bắt đầu bằng thông tin đăng nhập bị đánh cắp. Ví dụ, vào tháng 5 năm 2022, trang web tổ chức đám cưới nổi tiếng, Zola, là nạn nhân của một vụ vi phạm an ninh mạng nghiêm trọng trong đó tin tặc đã sử dụng một cuộc tấn công được gọi là nhồi nhét thông tin xác thực. Nó dẫn đến hoạt động gian lận gắn liền với tài khoản khách hàng. Chúng ta hãy xem xét vụ vi phạm Zola và lý do tại sao nó nhấn mạnh sự cần thiết của các tổ chức để tăng cường bảo mật mật khẩu của họ và bảo vệ chống lại các loại tấn công mật khẩu khác nhau.
Điều gì đã xảy ra với cuộc tấn công Zola?
Thay vì truy lùng cơ sở hạ tầng quan trọng trong kinh doanh cốt lõi của Zola, tin tặc đã theo dõi tài khoản khách hàng với cuộc tấn công hồi tháng Năm. Những kẻ tấn công đã sử dụng một kỹ thuật lâu đời được gọi là nhồi thông tin xác thực để xâm nhập một số tài khoản khách hàng của Zola. Với quyền truy cập vào các tài khoản bị xâm phạm, họ đã cố gắng mua các phiếu quà tặng mà sau đó họ có thể sử dụng.
Người phát ngôn của Zola đã đề cập rằng khoảng 3.000 tài khoản, tức khoảng 0,1% tài khoản Zola, đã bị xâm phạm. Người dùng đã nhìn thấy thẻ quà tặng hoặc quà tặng trị giá hàng trăm đô la được lấy từ tài khoản của họ. Tin tặc thậm chí còn thay đổi email liên kết với tài khoản Zola của người dùng trong nhiều trường hợp, ngăn họ đăng nhập. Các tài khoản Zola bị xâm phạm nhanh chóng bị rao bán trên dark web. Những người dùng khác đã báo cáo các khoản phí gian lận trên thẻ tín dụng được liên kết với tài khoản Zola.
Emily Forrest, Giám đốc Truyền thông của Zola, đã đề cập đến những điều sau trong một tuyên bố liên quan đến thỏa hiệp:
“Những tin tặc này có thể đã giành được quyền truy cập vào tập hợp thông tin đăng nhập bị lộ trên các trang web của bên thứ ba và sử dụng chúng để cố gắng đăng nhập vào Zola và thực hiện các hành động xấu. Nhóm của chúng tôi đã hành động ngay lập tức để đảm bảo rằng tất cả các cặp vợ chồng và khách trên Zola đều được bảo vệ… Chúng tôi hiểu sự gián đoạn và căng thẳng mà điều này đã gây ra cho một số cặp vợ chồng của chúng tôi, nhưng chúng tôi vui mừng thông báo rằng tất cả các nỗ lực chuyển quỹ tiền mặt gian lận đã bị chặn. Tất cả các quỹ tiền mặt đã được khôi phục. ”
Là một phần của biện pháp khắc phục vụ tấn công, Zola, ngoài việc buộc người dùng đặt lại mật khẩu tài khoản của họ, đã tạm thời vô hiệu hóa các ứng dụng dành cho thiết bị di động được kết nối với nền tảng này. Kể từ đó, họ đã kích hoạt lại nền tảng ứng dụng dành cho thiết bị di động. Tuy nhiên, mặc dù Zola cho phép kết nối thông tin tài khoản ngân hàng với tài khoản Zola, họ vẫn không yêu cầu xác thực đa yếu tố như một phần của điều khoản bảo mật.
Điều gì đã xảy ra từ góc độ bảo mật với cuộc tấn công Zola?
Nhận thức sâu sắc thường là 20/20 khi nói đến phân tích sau khi khám nghiệm tử thi về các vi phạm an ninh mạng. Tuy nhiên, có rất nhiều điều có thể đã được thực hiện và có thể được thực hiện trong tương lai để ngăn chặn các cuộc tấn công như vụ hack Zola được thực hiện.
Nhiều công ty hiện yêu cầu xác thực đa yếu tố được bật trên tài khoản của bạn để tận dụng các dịch vụ của họ. Có thể cho rằng, bất kỳ dịch vụ nào nhằm mục đích thu tiền vào tài khoản hoặc cho phép kết nối tài khoản ngân hàng hoặc thẻ tín dụng đều phải yêu cầu đa yếu tố. Với tính năng đa yếu tố được bật, ngay cả khi kẻ tấn công có thông tin đăng nhập hợp pháp, chẳng hạn như tên người dùng và mật khẩu, với một yếu tố bổ sung được yêu cầu, chúng vẫn không có mọi thứ cần thiết để xác thực và đăng nhập.
Cuộc tấn công vào Zola giúp nhấn mạnh rằng các công ty cũng phải giám sát các tài khoản để tìm các hoạt động đáng ngờ. Ví dụ: theo dõi các vị trí địa lý đáng ngờ, số lần đăng nhập từ một nguồn duy nhất hoặc các số liệu khác có thể giúp xác định và khắc phục các hoạt động bất chính.
Nhồi nhét thông tin xác thực là gì?
Nhồi nhét thông tin xác thực là một kỹ thuật hack đã có từ lâu và phát huy điểm yếu của việc sử dụng lại mật khẩu của người dùng cuối. Nó được định nghĩa là việc tự động tiêm các cặp tên người dùng và mật khẩu bị đánh cắp. Điều đó có nghĩa là gì? Bản chất của con người là sử dụng lại mật khẩu trên nhiều trang web, dịch vụ và ứng dụng. Kỹ thuật này giúp bạn dễ dàng ghi nhớ thông tin đăng nhập trên nhiều nền tảng khác nhau. Tin tặc sử dụng logic này để đánh bại xác thực mật khẩu được sử dụng trên hầu hết các nền tảng. Nếu họ xâm phạm hoặc tìm thấy thông tin đăng nhập bị rò rỉ được liên kết với tổ hợp người dùng / email / mật khẩu trong một nền tảng, họ có thể thử các thông tin đăng nhập giống nhau trên nhiều nền tảng.
Nó có thể hiệu quả ngay cả khi họ không biết người dùng / địa chỉ email có liên kết tài khoản. Ví dụ: giả sử họ có thể truy cập một số bộ thông tin xác thực (tên người dùng, mật khẩu) bị xâm phạm. Trong trường hợp đó, họ có thể sẽ tìm thấy các tài khoản người dùng hợp lệ trên nhiều dịch vụ mà người dùng đã sử dụng cùng một tổ hợp tên người dùng / mật khẩu.
Lưu ý các thống kê đáng báo động sau liên quan đến việc sử dụng lại thông tin xác thực:
Khoảng 50% chuyên gia CNTT thừa nhận đã sử dụng lại mật khẩu trên tài khoản công việc Có một tỷ lệ phần trăm nhân viên CNTT sử dụng lại thông tin xác thực cao hơn đáng ngạc nhiên so với người dùng không có đặc quyền (tương đối là 39%) Trong một nghiên cứu kéo dài ba tháng, Microsoft phát hiện ra rằng khoảng 44 triệu người dùng đã sử dụng cùng một mật khẩu trên nhiều tài khoản Trong một nghiên cứu của Google năm 2019, họ phát hiện ra rằng 13% số người sử dụng lại cùng một mật khẩu trên tất cả các tài khoản, 52% phần trăm sử dụng cùng một mật khẩu cho nhiều tài khoản trực tuyến và chỉ 35% sử dụng một mật khẩu khác nhau cho mọi tài khoản
Một kịch bản đáng báo động khác mà các tổ chức phải xem xét là người dùng cuối có thể sử dụng cùng một mật khẩu cho môi trường Active Directory của công ty giống như đối với tài khoản cá nhân của họ. Mặc dù các doanh nghiệp không thể kiểm soát và thực thi các chính sách mật khẩu cho tài khoản cá nhân của người dùng cuối, việc giám sát các mật khẩu bị vi phạm và sử dụng lại mật khẩu trên cơ sở hạ tầng Active Directory của công ty là rất quan trọng.
Bảo vệ Active Directory chống lại mật khẩu bị vi phạm và sử dụng lại mật khẩu
Dịch vụ miền Active Directory tại chỗ (AD DS) không có tính năng bảo vệ tích hợp chống lại mật khẩu bị vi phạm hoặc sử dụng lại mật khẩu. Ví dụ: giả sử mọi tài khoản trong Active Directory đều có cùng một mật khẩu và mật khẩu đáp ứng chính sách mật khẩu đã định cấu hình. Trong trường hợp đó, không có thông báo hoặc cách nào để ngăn chặn điều này với chức năng Chính sách mật khẩu Active Directory gốc.
Hơn nữa, nhiều tổ chức đang liên kết Dịch vụ miền Active Directory tại chỗ với các giải pháp đám mây Đăng nhập một lần (SSO). Thật không may, điều đó có nghĩa là tất cả mật khẩu yếu, mật khẩu vi phạm và mật khẩu được sử dụng lại trong tổ chức của bạn hiện được liên kết để sử dụng với các dịch vụ đám mây, càng làm suy yếu vị thế bảo mật của bạn.
Chính sách mật khẩu Active Directory tích hợp không thể bảo vệ bạn chống lại:
Mật khẩu tăng dần Nói kỹ mật khẩu Mật khẩu dễ đoán nhưng “phức tạp” Mật khẩu bị vi phạm Mật khẩu được liên kết với doanh nghiệp hoặc ngành của bạn
Tăng cường bảo mật mật khẩu Active Directory với specops
Với những thiếu sót của khả năng tích hợp được cung cấp bởi Dịch vụ miền Active Directory (AD DS), các tổ chức cần tăng cường bảo mật mật khẩu Active Directory của họ bằng giải pháp của bên thứ ba. Specops Password Policy là một giải pháp mạnh mẽ cung cấp cho các doanh nghiệp các công cụ và khả năng cần thiết để tăng cường bảo mật mật khẩu và lập trường an ninh mạng tổng thể.
Specops Password Policy tích hợp liền mạch với Chính sách mật khẩu Active Directory hiện có và bổ sung các tính năng bảo mật mật khẩu còn thiếu để giúp bảo vệ tổ chức của bạn khỏi nhiều cuộc tấn công, bao gồm cả việc nhồi nhét thông tin đăng nhập. Lưu ý các tính năng chính sau được cung cấp bởi Chính sách mật khẩu Specops:
Bạn có thể tạo danh sách từ điển tùy chỉnh để chặn các từ phổ biến đối với tổ chức của mình Ngăn chặn việc sử dụng hơn 2 tỷ mật khẩu bị xâm phạm với Bảo vệ mật khẩu bị xâm phạm của Specops Tìm và xóa mật khẩu bị xâm phạm trong môi trường của bạn Người dùng nhận được thông báo thông tin từ Specops khi thay đổi mật khẩu không thành công, giảm các cuộc gọi đến quầy trợ giúp Thời gian thực, phản hồi động khi thay đổi mật khẩu với ứng dụng Xác thực Specops Hết hạn mật khẩu dựa trên độ dài với thông báo email có thể tùy chỉnh Chặn tên người dùng, tên hiển thị, từ cụ thể, ký tự liên tiếp, mật khẩu tăng dần, sử dụng lại một phần của mật khẩu Chi tiết, GPO- nhắm mục tiêu theo hướng cho mọi cấp GPO, máy tính, người dùng hoặc nhóm dân số Hỗ trợ cụm mật khẩu Hơn 25 ngôn ngữ được hỗ trợ Sử dụng Biểu thức chính quy để có chính sách mật khẩu chi tiết hơn
Các tổ chức có thể bắt đầu bảo vệ mật khẩu của người dùng của họ bằng Bảo vệ mật khẩu bị xâm phạm chỉ với một vài cú nhấp chuột trong cài đặt cấu hình Chính sách mật khẩu Specops. Với việc liên tục kiểm tra mật khẩu bị rò rỉ và buộc người dùng thay đổi cài đặt của chúng, bạn có thể tận dụng tính năng thông minh honeypot nâng cao của Specop Password Policy để tìm ra những mật khẩu vi phạm muộn nhất hiện có.
Cấu hình Specops Chính sách mật khẩu Bảo vệ mật khẩu bị vi phạm
Specops cung cấp các công cụ cần thiết để chống lại các rủi ro về mật khẩu như mật khẩu được sử dụng lại một cách dễ dàng.
Ngăn chặn mật khẩu gia tăng và yêu cầu số lượng thay đổi tối thiểu đối với mật khẩu hiện có
Kết thúc
Vụ hack Zola giúp nhấn mạnh tầm quan trọng của việc ngăn người dùng sử dụng lại mật khẩu trong các môi trường quan trọng. Nó dẫn đến nhồi nhét thông tin xác thực, đoán mật khẩu, mật khẩu bị vi phạm và nhiều kiểu tấn công mật khẩu khác. Specops Password Policy là một công cụ mạnh mẽ cho phép các tổ chức ngăn chặn hiệu quả việc sử dụng lại mật khẩu, mật khẩu gia tăng và một số thay đổi tối thiểu đối với mật khẩu hiện có ở lần thay đổi mật khẩu tiếp theo.
Tìm hiểu thêm về Chính sách mật khẩu Specops và xem cách nó có thể giúp doanh nghiệp của bạn củng cố chiến lược bảo mật mật khẩu của bạn bằng bản dùng thử miễn phí.
.
