Tôi bị đánh thức một cách thô lỗ vào sáng thứ Tư tuần này. Người viết HaD không nhất thiết phải giữ giờ bình thường - đừng phán xét. Một khách hàng địa phương đã gọi điện, phàn nàn rằng Google Maps đang chặn trên một trong các máy tính của họ và trình duyệt cho biết đó là một trang web độc hại. Vâng, điều đó đã thu hút sự chú ý của tôi. Phản hồi sự cố tiêu chuẩn: “Tắt các máy tính bị ảnh hưởng, tôi đang trên đường tới đây.” Hóa ra, chính Malwarebytes đã phàn nàn và chặn Google Maps cũng như nhiều tên miền khác của Google. Máy cụ thể đó tình cờ có bản cài đặt mới của chương trình và vẫn đang trong giai đoạn dùng thử Malwarebytes cao cấp, bao gồm tính năng chặn tên miền và IP độc hại.

Ôi, điều này có thể tệ lắm. Khả năng đầu tiên tôi nghĩ đến là một vụ chiếm quyền điều khiển DNS. DNS của máy tính để bàn được đặt thành bộ định tuyến và DNS của bộ định tuyến được đặt thành ISP. Có lẽ ISP đã xâm phạm máy chủ DNS của họ? Chiếc điện thoại di động đã bị ngắt kết nối WiFi được lấy ra để tra cứu DNS trên một số tên miền của Google. Bởi vì Google hoạt động ở quy mô lớn như vậy nên họ có nhiều IP phục vụ mỗi miền, nhưng vì hai kết quả khác nhau đều đến từ cùng một mạng con nên máy chủ DNS đáng ngờ có thể vẫn ổn. MỘT whois trên IP bị chặn cũng xác nhận đó là địa chỉ do Google sở hữu. Chúng tôi đã hết lời giải thích, và như một thám tử hư cấu nổi tiếng đã nói, “điều còn lại, dù khó tin đến đâu, đều phải là sự thật”. Và vâng, Malwarebytes thực sự đã vô tình thêm Google vào danh sách xấu của nó. Ưu điểm là khách hàng của tôi không bị tổn hại. Nhược điểm? Tôi phải trả lời một cuộc điện thoại trước tách cà phê đầu tiên của mình. Blegh.

Uber

Trong bản tin p0wnage tuần này, Uber bị xâm phạm thông qua tài khoản VPN của nhân viên. Uber sử dụng xác thực hai yếu tố cho các tài khoản đó và kẻ tấn công đã sử dụng cuộc tấn công “MFA mệt mỏi” để đánh bại tài khoản đó. Về cơ bản, hãy gửi các yêu cầu 2FA lặp đi lặp lại và hy vọng người dùng cảm thấy mệt mỏi với nó và xác nhận. Hoặc, bạn có thể liên hệ với họ sau một vài lần thử, tự nhận là nhân viên CNTT của công ty và yêu cầu họ phê duyệt lời nhắc hoặc đọc lại số. Kẻ tấn công đó là [Tea Pot], bằng cách nào đó có liên kết với Lapsus$.

Quyền truy cập VPN đã đưa TP vào mạng nội bộ của công ty và một số kẻ đánh hơi đã tìm thấy một phần có thể truy cập được với các tập lệnh Powershell trên đó. Và trong các tập lệnh đó có một số thông tin xác thực được mã hóa cứng của quản trị viên đối với tài khoản Thycotic của Uber — dịch vụ quản lý tất cả quá trình xác thực của họ. Nói tóm lại, đó là chìa khóa của vương quốc. “Bằng cách sử dụng tính năng này, tôi có thể trích xuất bí mật cho tất cả các dịch vụ, DA, DUO, Onelogin, AWS, GSuite.”

Uber đã phát hành một tuyên bố về cơ bản tuyên bố rằng không có bằng chứng nào về việc giả mạo mã hoặc truy cập dữ liệu người dùng. Khi TP có thể xâm nhập sâu vào hệ thống của Uber, điều này có vẻ hơi đáng ngạc nhiên, mặc dù đây là một tin đáng mừng. Tất nhiên, cuối cùng người ta có thể tiết lộ rằng sự giả mạo nghiêm trọng hơn đã xảy ra.

Lỗ hổng hàng đầu của Rack

Tôi không chắc liệu Đơn vị phân phối điện (PDU) có được tính là IoT hay không, nhưng chữ S dường như vẫn tượng trưng cho bảo mật. iBoot PDU gặp một số vấn đề nghiêm trọng. Trang đầu tiên là một trang trên giao diện web, dường như đã bị nhà sản xuất bỏ rơi, không chứa mã xác thực. Điều khá chuẩn là khi viết giao diện web bằng PHP, phải có mã xác thực trong một tệp duy nhất và chỉ bao gồm mã đó từ mỗi trang cần được bảo vệ. Mã cho git-update.php điểm cuối bị thiếu bao gồm. Không có vấn đề gì, việc tải xuống các bản cập nhật từ kho GitHub của nhà sản xuất đã được mã hóa cứng và sử dụng mã thông báo truy cập không còn được GitHub hỗ trợ. Mã chết, không có gì phải lo lắng.

Vâng, nó rất dễ bị tổn thương. Điểm cuối này nhận hai đối số làm tham số HTTP POST, branchvà token. Cả hai đều không được làm sạch chút nào, vì vậy tham số nhánh có thể sử dụng tính năng truyền tải đường dẫn để trỏ đến một tài khoản GitHub hoàn toàn khác và tham số mã thông báo có thể được đặt thành &, về cơ bản có nghĩa là nó bị bỏ trống trong yêu cầu tới GitHub. Một yêu cầu xác thực trước duy nhất và thiết bị sẽ lịch sự tải xuống webshell cho bạn.

À, nhưng chúng tôi không phải kẻ ngốc. Đừng bao giờ để những thứ này xuất hiện trên Internet chưa được lọc. Họ có chức năng truy cập đám mây cho việc đó. Để kết nối, bạn xác thực rồi gửi tham số ID thiết bị trong yêu cầu URL. Nhưng các ID thiết bị đó là tuần tự và mọi cookie xác thực hợp lệ đều hoạt động để kết nối với bất kỳ thiết bị nào. Vì vậy, nếu bạn có thể kết nối với một PDU, bạn có thể kết nối với tất cả chúng. Và vì quyền truy cập vào đám mây là một proxy ngược đơn giản nên trang cập nhật có thể bị lạm dụng như minh họa ở trên. Ôi! Sự cố đã được khắc phục và nếu bạn có PDU Dataprobe, hãy kiểm tra chương trình cơ sở đã cập nhật! Và có thể ngắt kết nối hoàn toàn khỏi Internet và chỉ cho phép truy cập VPN. Xin chân thành cảm ơn Team82 tại Claroty vì đã tìm ra thông tin này và báo cáo riêng tư.

Nâng cao đặc quyền của Seagate

Trong một bài viết hay, [x86matthew] chia sẻ cách khai thác rất đơn giản bằng Seagate Media Sync, để thêm một dịch vụ tùy ý vào máy Windows. Media Sync sử dụng mô hình Giao diện người dùng và Dịch vụ, trong đó dịch vụ chạy dưới dạng HỆ THỐNG để thực hiện công việc nặng nhọc và ứng dụng giao diện người dùng chạy với tư cách là người dùng đã đăng nhập. Một chút điều tra và gỡ lỗi cho thấy định dạng được sử dụng cho Giao tiếp giữa các quá trình (IPC) là một đường ống có tên đơn giản. Ống đó hỗ trợ một số lệnh, nhưng lệnh thú vị nhất gọi một hàm trong dịch vụ, MXOSRVSetRegKey.

Như mọi người có thể mong đợi, nó đặt khóa đăng ký thành một giá trị, tạo khóa nếu không có. Trong trường hợp cụ thể này, không có kiểm tra nào về nơi tạo khóa đó, vì vậy bất kỳ ai có thể nói chuyện với đường ống đều có thể tạo khóa trong HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices. Và nếu bạn có thể tạo một dịch vụ tùy ý trên máy Windows, thì bạn sở hữu máy đó.

Nâng cao OpenRazer - Gần như

Và bởi vì việc khai thác Linux cũng xứng đáng được chúng ta yêu thích, nên Dự án OpenRazer có vấn đề khai thác tương tự gần đây đã được sửa. Đối với những người chưa biết, chúng tôi, những người đam mê Linux, thích bàn phím kêu lạch cạch, có đèn LED, cũng giống như người dùng Windows, nhưng thật đáng buồn là Razer chỉ xuất bản các công cụ và trình điều khiển Windows. Để lấp đầy khoảng trống, các dự án như OpenRazer triển khai lại bộ điều khiển Razer LED và các chức năng khác cho Linux. Một phần của dự án OpenRazer là mô-đun hạt nhân Linux sẵn có, cho phép một số bit giao tiếp USB phức tạp được sử dụng để giao tiếp với bộ điều khiển trên thiết bị. Đó là một sự cố nhỏ và chất lượng mã không ngang bằng với nhân chính của dòng chính, bằng chứng là lỗi tràn bộ đệm cổ điển được Cyberark phát hiện. Lẽ ra đây là một con đường dễ dàng để khai thác, nhưng bắt đầu với kernel 5.18, Củng cố nguồn tính năng được kích hoạt để ngăn chặn memcpy() các hàm từ các trường tràn trong một cấu trúc. Vì vậy, trong một kernel đủ mới, khi bật tính năng bảo vệ này, bạn chỉ gặp sự cố thay vì bị khai thác. Gọn gàng!

Mẹo kiểm tra

Một trong những nhiệm vụ khi thực hiện bài kiểm tra của đội đỏ là tìm kiếm tài khoản người dùng. Rắc rối mà bạn có thể gặp phải là tên người dùng có thể bị ép buộc một cách thô bạo sẽ để lại các mục nhật ký và điều đó có thể khiến bạn bị bắt. [Lars Karlslund] đã nắm bắt được các Yêu cầu Ping LDAP và ngay lập tức kết nối với bảng liệt kê người dùng. Mục đích của việc này ban đầu là để dễ dàng kiểm tra khả năng tiếp cận của bộ điều khiển miền cũng như các khả năng hoặc cấu hình nhất định. Một trong những thông số kỹ thuật kiểm tra bạn chọn là tên người dùng. Công cụ mới của [Lars], ldapnomnom, sử dụng cơ sở này để truy vấn 10,000 tên người dùng một giây. Tìm tất cả người dùng!