2010-09-18 36 views
8

Chúng tôi có ứng dụng .NET 3.5 có phần mở rộng đã đăng ký. Làm thế nào chúng ta có thể bảo vệ nó chống lại các cuộc tấn công DLL Hijacking?Làm thế nào tôi có thể proctect ứng dụng .NET của tôi chống lại DLL Hijacking?

Vì di sản & vấn đề thiết kế đặt tên mạnh/ký không phải là một lựa chọn ngay bây giờ

Thông tin thêm nếu bạn không biết những gì DLL Hijacking là:

+17

* Do thiết kế/ký tên mạnh mẽ không phải là một tùy chọn * - sau đó thiết kế của bạn làm cho các hội đồng dễ bị tấn công DLL. –

+2

Loại thiết kế nào có thể được, không cho phép các hội đồng được ký tên hoặc được đặt tên mạnh? –

+2

Jim nó là một thiết kế xấu, lý do di sản, vấn đề hệ thống plugin vv Giống như một triệu ứng dụng thực tế khác ra khỏi đó. –

Trả lời

0

Xem qua là thread .... nó có thể giúp bạn và cung cấp cho bạn cái nhìn sâu sắc .... một điều khác, bạn chắc chắn có thể kiểm tra EasyHook và chặn API createRemoteThread và tìm hiểu xem DLL có phải là một trong những trái phép .... có xem tại đây thread giải thích cách chặn chống lại dll injection

-1

Nếu bạn có thư mục riêng tư/truy cập dữ liệu, bạn có thể viết mã để chủ động đi và tìm trong cùng một địa điểm Windows tìm kiếm .DLL trước khi gọi .DLL (hoặc tìm kiếm toàn bộ ổ đĩa), và bạn có thể tính toán kiểm tra CRC cho DLL hợp pháp của bạn, hoặc khớp mẫu khác để so sánh tệp legit.DLL của bạn trên các tệp DLL phù hợp, và đảm bảo không có ai khác chiếm đoạt bạn (đặt một tệp ở một vị trí sẽ được tìm kiếm trước vị trí của bạn - hoặc thậm chí là bất kỳ vị trí nào). Điều này có thể mất một số nghiên cứu về phương pháp theo các phiên bản Windows khác nhau cho các đơn đặt hàng khác nhau của tìm kiếm. Sau đó, nếu bạn tìm thấy một nỗ lực tấn công, bạn có thể thực hiện một số hành động, tùy thuộc vào cách bạn chắc chắn rằng ai đó đang cố gắng chiếm đoạt DLL của bạn ... Đổi tên faker.DLL, xóa nó, thông báo cho người dùng, thông báo cho admin, don ' t gọi dll của bạn, vv

+1

CRC không được thiết kế với sự bảo mật, nó không phải là công cụ thích hợp cho công việc. Một cái gì đó giống như SHA sẽ tốt hơn nhiều. – svick

4

Tôi đã gặp vấn đề tương tự, tôi đã kết thúc bằng văn bản logic của riêng tôi để xác minh dll. Đối với tôi, tôi chỉ sử dụng dll đó trong thời trang LGPL (tôi không thể sửa đổi dll), nhưng muốn chắc chắn rằng ứng dụng của tôi sử dụng dll chính hãng (không phải là một trong những hi-jacked).

Giải pháp đơn giản:

  • Trong khi phát triển ứng dụng tạo MD5 Checksum của dll và hardcode băm trong việc áp dụng
  • Mỗi lần bạn khởi động ứng dụng sử dụng cùng một logic để tạo ra MD5 Checksum của dll và so sánh nó với mã được mã hóa.
  • Bạn có thể đã biết nhưng ở đây là làm thế nào để tạo ra hiệu quả Checksum của một tập tin (xem câu trả lời: https://stackoverflow.com/a/1177744/392850) giải pháp

tốt hơn:

  • Tạo băm của dll, với Băm mạnh thuật toán và muối
  • Tạo cặp giá trị khóa RSA (khóa riêng và khóa công khai)
  • Mã hóa băm của dll bằng khóa riêng của bạn
  • Nhúng khóa công khai, "băm được mã hóa" và muối trong ứng dụng của bạn
  • Khi bắt đầu ứng dụng, giải mã "băm được mã hóa" bằng khóa công khai của bạn
  • Tạo lại Hash trong thời gian chạy với cùng một muối và so sánh với mã băm được giải mã bằng khóa công khai

Nếu bạn có chứng chỉ từ CA đáng tin cậy như verisign, bạn có thể sử dụng chứng chỉ thay vì sử dụng cặp giá trị khóa RSA.

Bằng cách này, ngay cả khi ai đó thay thế dll của bạn bằng dll bị bẻ khóa, hàm băm sẽ không khớp và ứng dụng của bạn sẽ biết được nỗ lực Hijacking.

Cách tiếp cận này có thể được tốt hơn so với chỉ cho dll một tên mạnh mẽ bởi vì, có thể xác minh tên mạnh có thể bị vô hiệu hóa bằng cách chạy

SN -Vr HijackedAssembly 

Hy vọng điều này sẽ giúp bạn, hay bất kì ai muốn hiểu điều chữ ký bao kỹ thuật số làm việc nội bộ.

+0

Kỹ thuật này thực sự chống lại bản chất của LGPL. LGPL yêu cầu bất kỳ dll nào được nạp phải được người dùng thay thế bằng phiên bản dll riêng của họ, ngoại lệ là nếu toàn bộ dự án nằm dưới (L) GPL. – mlehmk

+0

Điểm tốt @mlehmk, bạn nói đúng, theo phần LGPL v3 4.d.1, thư viện LGPL nên được người dùng thay thế. Nhưng theo cùng một phần, theo như chúng tôi cung cấp cơ chế cho người dùng thay thế thư viện LGPL, chúng tôi sẽ ổn. Câu hỏi này là về DLL Hijacking vì vậy tôi đã không đi vào giấy phép phức tạp. – Vishalgiri

0

Bạn không thể bao gồm dll làm tài nguyên và ghi nó ra nơi bạn muốn trong thời gian chạy sau đó tải dll vào lắp ráp? Tôi đã làm điều này một lần bởi vì chúng tôi muốn phân phối như một .exe nhưng tôi nghĩ rằng nó cũng sẽ giải quyết vấn đề này, phải không?

0

Robert,

Công bằng cho câu hỏi của Jim về "kiểu thiết kế đó". Bằng cách trả lời, thay vì chỉ nói "nó là cái gì" bạn có thể cho chúng ta cái nhìn sâu sắc về những ràng buộc mà các đề xuất/giải pháp của chúng ta phải nằm trong đó.

Đặt một cách khác, mà không biết lý do mã di sản ngăn bạn làm điều đó "đúng cách" thật khó để cung cấp giải pháp lý tưởng cho sự cố của bạn.

Trừ khi kiến ​​trúc của bạn ngăn chặn ý tưởng tổng kiểm tra MD5 được đề xuất bởi Vishalgiri, tôi khuyên bạn nên dùng lời khuyên của mình. Một lần nữa, mặc dù không biết ứng dụng nào gọi các tệp DLL này và tại sao chúng không thể được ký, thật khó để biết điều này có hiệu quả với bạn hay không.

Ý tưởng của tôi có thể đơn giản hơn nhiều, nhưng bạn không thể điều chỉnh ứng dụng của mình để tải trước DLL từ vị trí được xác định trước? Ví dụ, chỉ cho phép nó tải từ thư mục BIN của ứng dụng chính của bạn, và thất bại - không bao giờ thử lại?

Xem liên kết này về cách tải từ một con đường riêng biệt: http://www.chilkatsoft.com/p/p_502.asp

Đây có thể là nhanh hơn so với văn bản tất cả các mã MD5 checksum. Mặc dù tôi cũng thích ý tưởng đó.

Các vấn đề liên quan