Kinh nghiệm khi tìm lỗi bảo mật

Xuất phát từ một câu hỏi trên ask.fm/ManhLuat/. Câu hỏi này đã được lặp lại vài lần. Nên coi như đây là 1 cái note tổng hợp lại từ đầu đến cuối.
Câu này được hỏi đúng vào lúc mình đang phải research và bug hunting trên một target mới, nên chi bằng ngồi nhớ lại thì trong quá trình làm mình sẽ note lại những thứ rút ra được


Tìm bug được chia ra 2 phương thức chính:

  1. Manual Review / Auditing
  2. Fuzzing

Trong bài này mình sẽ không đề cập về fuzzing nữa, vì mình đã nói về nó ở: libFuzzer — Phương pháp kiểm thử lỗi sản phẩm dành cho developer và BẮT ĐẦU HỌC AN TOÀN THÔNG TIN NHƯ THẾ NÀO?

Với từng đấy mình nghĩ bạn đã có thể bắt đầu học về fuzzing và nghiên cứu sâu thêm, vì phần lớn thời gian của mình hiện tại không còn làm về fuzzing nhiều nữa, nên mình không muốn đi quá sâu.

Sau bao năm làm và quan sát, mình tin rằng thứ quan trọng nhất là niềm đam mê, tập luyện và sự kiên trì. Khi đã có những thứ này thì việc ra kết quả chỉ là vấn đề thời gian.

Và bài này sẽ không nặng về tính kĩ thuật, vì đã có rất rất nhiều bài viết kĩ thuật trên mạng được các bug hunter khác chia sẻ, mỗi target là một quá trình, nguyên lý, cách thức tìm khác nhau. Phần mình, cũng đã chia sẻ khá nhiều trên các kênh khác: youtube và ask.fm. Trong tương lai có thể mình sẽ nói/viết những bài về kĩ thuật thêm (nếu thoát lười)

Các bạn cứ coi đây là kim chỉ nam khi lâm vào bế tắc hoặc chưa biết bắt đầu từ đâu …

 

 

Phase 1: Khi bắt đầu ta nên…

Tìm hiểu chức năng cơ bản của ứng dụng/đối tượng đó, dò xem có các chức năng nào đặc biệt không, note lại, authen như thế nào, dùng platform/framework gì (nếu có), etc.

Đặt mình vào vị trí developer, tưởng tượng xem nếu bạn muốn code một chức năng gì đó thì sẽ làm thế nào. bởi vậy mình thấy có nhiều anh bug hunter xuất thân từ developer với tư duy security làm việc rất hiệu quả.

Tìm hiểu những loại lỗi và tricks thường xảy ra với ngôn ngữ của target đó (vd: php thì hay bị sqli, $_GET có thể truyền vào là array, blah blah . ruby thì regexp sida. java thì java-deserialization, etc.) Cái này cần sự thu thập kiến thức và tìm hiểu trong một thời gian dài. Vì đôi khi dev code có thể ko lỗi nhưng lỗi lại nằm ở ngôn ngữ cấu thành và các tricks xung quanh nó.

Debug khi cảm thấy không hiểu. Sẽ có những đoạn code khá lắc léo, khó hiểu, nếu được thì hãy bật debugger lên và breakpoint tại các điểm mấu chốt.

Research đối tượng bằng nhiều cách nhưtìm write-up, report, analysis, commit/patch,  blog post liên quan về nó. Mà ở đây là bạn phải thật sự hiểu các bugs đó nhé, reproduce luôn nếu có thể (tìm version cũ hoặc patch để setup môi trường).
Vì trong quá trình làm như vậy, bạn sẽ dần hình dung ra điểm yếu của target và cả cái người code nó (ví dụ như javascript engine thì rất hay bị side-effect, fallback trap, JIT-optimization, etc.)

Cũng như vừa đọc document và vừa audit, để mình hình dung ra bức tranh tổng thể đoạn code mình đang coi, có thể sẽ tiết kiệm được rất nhiều thời gian.

Phase 2: Khi đã quen dần với việc tìm bug thì nên…

Hãy cố gắng nhìn xa ra, đừng có đọc 1 cái report của 1 cái bug rồi chỉ chăm chăm tìm ra một cái khác y chang hoàn toàn, vậy thì bạn chỉ lụm đc low-hanging fruit thôi. Cố gắng tập suy nghĩ như cái người tìm ra nó, cố gắng giả lập lại quá trình suy nghĩ của họ, ờ có thể họ thấy điểm này lạ và thú vị nên đào sâu vô, sau đó tới bước này thì họ thấy cái này , blah blah. Phải hiểu hoàn toàn cái bug đó, vì rất có thể cùng một đích đến nhưng bạn có thể đi một con đường khác để tìm ra một biến thể (variant) khác. Lụm tiền $$$. Đống bug pdfium của mình là minh chứng.

Cố gắng nắm bắt suy nghĩ flow của những người đi trước và “não to”, zoom-out ra, cố gắng nhìn thấy cách họ suy nghĩ, cách họ giải quyết vấn đề, tại sao họ lại làm như thế ? tại sao họ lại có thể tìm ra cái đó ?

Ngồi ngẫm lại và suy nghĩ mình đã miss những gì, những điểm yếu cần khắc phục trong quá trình học hỏi người khác

Sử dụng các report như một kim chỉ nam lúc ban đầu, đến một lúc nào đó thì bạn phải mở rộng phạm vi audit ra, tìm hiểu code ở những vùng khác.

Nếu stuck quá lâu với một thứ thì nên tìm cái khác để làm trong quãng thời ngắn, refresh lại bản thân.

Đầu tư thời gian vào những chỗ ít người để mắt đến. Có thể vì nó phức tạp nên những người khác không muốn chạm tới, hoặc vì nó cần thêm những kiến thức khác (mà có thể bạn có mà người thác thì không) thì hãy khai thác lợi thế đó. Hoặc cũng có thể nó là một chức năng gì đó mà ít hunter chạm tới (mình nhớ 1 case Dropbox, mình đã tạo account premium trial để test các chức năng trong đó, thế là có được bug, bug rất đơn giản, lí do mình đã tìm được là nhìn vào chỗ mà người khác ít để mắt tới) , đoạn này mình vừa update vào 26/07/2019.

Lời kết /

Đôi khi bạn phải hi sinh thời gian research/audit những đoạn code mà bản thân không biết nó sẽ đi về đâu, có kết quả không ?

Nhưng…hãy chấp nhận vậy đi, research là vậy, nếu không đi con đường khó, con đường mới thì sẽ khó mà gặt hái được điều gì đáng kể.

Tuy nhiên, trong quá trình đó, bạn sẽ thu thập được kiến thức xung quanh target đó, hiểu thêm về nguyên lý hoạt động của các software/protocol/etc. các thứ mà trước đây mình không hề biết nó là như thế, xem đó là một thú vui, cũng như rèn luyện được nhiều kĩ năng khác nhau, suy nghĩ tích cực vậy đi!

Peace.

 

 

 

manhluat Written by:

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *