Tuần này về bảo mật: Git Deep Dive, Mailchimp và SPF

Tuần này về bảo mật: Git Deep Dive, Mailchimp và SPF

Dấu thời gian: ngày 20 tháng 2023 năm 10 00:XNUMX sáng
Nút nguồn: 1910203

Đầu tiên, git đã được kiểm tra. Đây là nỗ lực được tài trợ bởi Quỹ cải tiến công nghệ nguồn mở (OSTIF), một tổ chức phi lợi nhuận hoạt động nhằm cải thiện tính bảo mật của các dự án Nguồn mở. Bản thân việc kiểm tra được thực hiện bởi các nhà nghiên cứu từ X41 và GitLab, và hai lỗ hổng nghiêm trọng đã được tìm thấy, cả hai đều do thói quen viết mã xấu giống nhau - sử dụng một int để giữ độ dài bộ đệm.

Trên các hệ thống hiện đại, một size_t luôn không dấu và có cùng độ dài bit với độ rộng bit của kiến ​​trúc. Đây là kiểu dữ liệu thích hợp cho độ dài chuỗi và bộ đệm, vì nó được đảm bảo không bị tràn khi xử lý độ dài lên tới bộ nhớ có thể định địa chỉ tối đa trên hệ thống. Mặt khác, một int thường dài bốn byte và có chữ ký, với giá trị tối đa là 2^31-1 hoặc 2147483647 — khoảng 2 GB. Một bộ đệm lớn nhưng không phải là lượng dữ liệu chưa từng có. Ném thứ gì đó lớn như vậy vào git, và nó sẽ bị hỏng theo những cách không ngờ tới.

Ví dụ đầu tiên của chúng tôi là CVE-2022-23521, một lỗi ghi ngoài giới hạn do một int tràn về tiêu cực. MỘT .gitattributes tệp có thể được cam kết vào một kho lưu trữ với ứng dụng khách git đã được sửa đổi và sau đó kiểm tra kho lưu trữ đó sẽ gây ra num_attrs biến bị tràn. Đẩy mức tràn đến một số âm nhỏ và sau đó git sẽ phân bổ quá thấp bộ đệm thuộc tính và ghi tất cả dữ liệu đó vào cuối bộ đệm được phân bổ.

CVE-2022-41903 là một lỗi tràn số nguyên có dấu khác, lần này khi một định dạng in đẹp bị lạm dụng để làm điều gì đó không mong muốn. Hãy nhìn vào khối mã này:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

Định dạng khai thác sẽ trông giống như %>(2147483647)%a%>(2147483646)%x41, trong đó đoạn mã trên chạy cho mọi phiên bản đệm (The %>(#) khối) được tìm thấy ở định dạng. Lần đầu tiên thông qua mã này, thêm khoảng trắng (2^31)-1 vào phía trước chuỗi đầu ra. Con số đó chỉ là giá trị tối đa của số nguyên có dấu bốn byte. Nhưng khối mã ở trên sẽ được chạy vào lúc khác và một khi văn bản nữa được thêm vào bộ đệm, đẩy độ dài của nó lên trên giá trị số nguyên tối đa. Dòng đầu tiên của khối đó thực hiện chuyển đổi ngầm định từ size_t đến int, cài đặt sb_len thành giá trị âm.

Sau đó trong memcpy() gọi, sb->buf là một con trỏ tới điểm bắt đầu của bộ đệm, sb_len là số âm lớn bị tràn của chúng tôi và offset sẽ là giá trị do người dùng kiểm soát. Điều này có nghĩa là vị trí của điểm đích được gửi tới memcpy() có thể vô tình được đặt ở vị trí bộ nhớ thấp hơn vị trí bắt đầu của bộ đệm dự định. Kẻ tấn công kiểm soát việc viết. Tôi đã thêm một số câu lệnh printf() gỡ lỗi vào khối văn bản này và chạy một trường hợp thử nghiệm:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

Bộ tứ đầu ra đầu tiên là thiết lập, chuẩn bị dòng nhật ký với phần đệm có độ dài tối đa. Bộ tứ thứ hai là lỗi tràn bộ đệm, trong đó sb_len được đặt thành âm, sau đó được thêm vào phần bù để cung cấp cho chúng ta vị trí 56 byte ở bên trái điểm bắt đầu của bộ đệm. Nội dung được in đến vị trí đó nằm trong trường hợp này %s, được thay thế bằng dòng chủ đề của cam kết - dài 44 byte. Các tác giả gợi ý rằng điều này có thể được vũ khí hóa để chống lại “git forge”, AKA GitHub và GitLab, vì các bộ phần mềm đó chạy lệnh git archive, lệnh này có thể gọi ra một chuỗi đẹp do người dùng kiểm soát.

Các bản sửa lỗi đã được đẩy lên mã nguồn git vào ngày 8 tháng 2200, nhưng các bản phát hành mới chứa các bản sửa lỗi đó hiện đã có sẵn. Có khoảng XNUMX phiên bản thô int và những vấn đề đó sẽ mất một thời gian để giải quyết, ngay cả với một số thủ thuật thú vị như cast_size_t_to_int(), một hàm nội tuyến sẽ tắt chương trình nếu có dung lượng 2 GB+ size_t Được xử lý. Vì vậy, hãy cập nhật!

Mailchimp - Một lần nữa

Có vẻ như mọi người ở Mailchimp không thể nghỉ ngơi được, vì các công cụ quản trị nội bộ của họ đã bị kẻ tấn công truy cập một lần nữa, dẫn đến việc 133 tài khoản khách hàng bị lộ, bao gồm cả WooC Commerce. Đây là lần thứ ba Mailchimp rơi vào một cuộc tấn công lừa đảo hoặc kỹ thuật xã hội trong năm ngoái và mỗi lần đều dẫn đến các email lừa đảo trực tuyến được gửi đến người dùng cuối. Vì vậy, nếu bạn có tên trong bất kỳ danh sách gửi thư nào của Mailchimp, hãy ghi nhớ vi phạm này vào lần tới khi có email liên quan đến. (Lưu ý của biên tập viên: Hai bản tin của Hackaday sử dụng Mailchimp và chúng tôi không được thông báo nên chúng tôi tin rằng chúng tôi ổn.)

Phần mềm tống tiền Royal Mail

Trong một câu chuyện có thể gây ra một số hậu quả lớn, Royal Mail của Anh đã bị tấn công bằng ransomware trên hệ thống của họ để xử lý thư quốc tế. Cuộc tấn công sử dụng ransomware Lockbit, một nhóm bị nghi ngờ là băng nhóm ransomware nói tiếng Nga. Điều này có thể rất quan trọng vì một cuộc tấn công vào một cơ quan chính phủ thực tế sẽ nghiêm trọng hơn nhiều so với một cuộc tấn công vào một doanh nghiệp. Vì Lockbit chạy dưới dạng dịch vụ ransomware nên sẽ rất khó để xác định chính xác ai thực sự đã thực hiện cuộc tấn công. Hiện tại, khuyến nghị rất đơn giản: không gửi bất kỳ thư quốc tế nào. Ôi.

Quét bản ghi SPF

[Sebastian Salla] có một sở thích có thể coi là kỳ lạ, đó là hình thức quét các bản ghi SPF để tìm các cấu hình sai kỳ lạ. Trong cuộc phiêu lưu mới nhất của anh ấy, bản quét đó đã lọt vào top 3 triệu miền được truy cập nhiều nhất. Và cấu hình sai đã được tìm thấy.

Nhưng chờ đã, SPF là gì và tại sao chúng ta lại quan tâm? Khung chính sách người gửi là một bản ghi txt nằm trong bản ghi DNS của miền. Và nó chỉ định địa chỉ IP nào thực sự được phép gửi email cho tên miền đó. Vì vậy, nếu một email đến tuyên bố là đến từ một miền có bản ghi SPF hợp lệ và địa chỉ IP gửi không có trong bản ghi đó thì rõ ràng email đó không thực sự đến từ miền được xác nhận quyền sở hữu.

Và việc email trong miền của bạn bị từ chối do vấn đề về SPF là một trong những cách chắc chắn nhất để phát hiện lỗi. Vì vậy, thật hấp dẫn khi tạo bản ghi SPF nhiều hơn một chút… *tự do* hơn mức có lẽ nên làm. Và sự lặp lại cực đoan nhất của điều này là chỉ tát một cái +all trên bản ghi SPF của bạn và hoàn tất nó. Chắc chắn, nó cho cả thế giới biết rằng mọi kẻ gửi thư rác ở bất cứ đâu sử dụng tên miền của bạn đều thực sự đang gửi email thực, nhưng ít nhất nó cũng khiến các email gửi đi của ông chủ hoạt động trở lại. Với hơn một nghìn tên miền được đặt thành SPF +all, rõ ràng đó là một lỗi phổ biến hơn dự đoán.

Điều thực sự thú vị là ai là người trong số các miền bị định cấu hình sai đó, chẳng hạn như nhiều cơ quan chính phủ Hoa Kỳ, các miền chính phủ khác trên khắp thế giới và nhiều trường đại học. Điều thú vị nhất là Bộ Quốc phòng Ucraina, nơi bản ghi SPF được cắt ra từ một -all đến +all khoảng 4 tháng trước.

Bit và byte

Tailscale đã phát hiện ra một vấn đề nghiêm trọng tiềm ẩn, trong đó việc biết ID nút của máy khách khác sẽ cho phép kẻ tấn công thêm nút vào tailnet của chính họ. Điều này sẽ đặt kẻ tấn công vào bên trong VPN của bạn, chắc chắn là một tình huống xấu. Nhưng trước khi bạn nhận được các pitchfork của mình, mã dễ bị tấn công đã được triển khai chưa đầy bốn tháng trước khi được sửa. Nó đã được báo cáo riêng vào ngày 11 tháng này và được sửa vào ngày 12. Và để khởi động, cuộc tấn công để lại một chữ ký nhật ký mà Tailscale có thể quét và kết luận rằng nó đã bị cô lập trong quá trình thử nghiệm bằng chứng khái niệm. Bạn có thể kiểm tra bảng điều khiển của riêng mình để tìm bất kỳ nút nào được chia sẻ từ mạng tailnet của riêng chúng để xác nhận. Và mặc dù đây là một lỗ hổng nguy hiểm nhưng Tailscale rất tốt vì đã tiết lộ nó. Nhiều nhà cung cấp sẽ ngồi trên cái này và không bao giờ công khai nó.

Sản phẩm Nhân Linux bị tràn bộ đệm trong mã Netfilter của nó, trong đó lỗi tràn bộ đệm có thể dẫn đến rò rỉ dữ liệu và thực thi mã. Không có đường dẫn để khai thác từ xa, nhưng email được liên kết ở trên chứa PoC đầy đủ để leo thang đặc quyền cục bộ. Và nếu việc khai thác hạt nhân là sở thích của bạn thì Project Zero của Google có một bài viết mới về chủ đề này, tất cả về hội thảo null.

Và nếu bạn sử dụng ManagedEngine từ Zoho, thì hôm nay tóc của bạn có thể bị cháy nếu bạn chưa cập nhật lên bản phát hành sửa lỗi CVE-2022-47966. Các nhà nghiên cứu tại Horizon3 đã thiết kế ngược bản vá, và làm đổ đậu trên RCE này. Đó là một vấn đề trong cách triển khai đăng nhập một lần SAML, một phần là do thư viện cực kỳ cũ được đóng gói như một phần của sản phẩm. Đây là một cách khai thác khá dễ dàng để thực hiện, vì vậy đã đến lúc kiểm tra kỹ các lượt cài đặt đó!

Dấu thời gian:

Thêm từ Hack một ngày