Quartz 🪬

Report 19-05-2023

4 min read

Done ✅

Reading

Solidity

  • Basics
  • Compilation and deployment (Truffle)
  • Advanced concepts
  • Utilities contract
  • Web3.js (front-end library)
  • Read some existing smart contract source code (OpenZeppelin, SeaPort)

Semgrep

  • Basic
  • Composition and advanced concepts
  • Practice with existing rules (language: Java, source code: WebGoat) of some common weaknesses.
  • Practice with SWC (language: Solidity). Problem 😥: Solidity in Semgrep is experimental. Sử dụng thêm thư viện libsast.

To Do 📋

Reading

Slither - A Static Analysis Framework for Smart Contracts

Solidity

Testing smart contract

Semgrep

Practice more with SWC

Main Goal 🎯

Apply Semgrep to Solidity smart contracts for extracting DFD artifacts.

  • Designing rules: depends on a mapping table between artifacts and components of smart contract.
  • Smart contracts scope is too small, consider to examining a bigger thing, like dApp.
  • Finding a sample project for applying the techniques (Seaport seems promising).

Questions 🤔

Mình sử dụng static analysis là để nhận diện các artifacts chứ không phải là để tìm lỗ hổng đúng không?

Đúng

Em thấy static analysis có rất nhiều kỹ thuật, chẳng hạn như taint analysis, symbolic execution, etc. Em có cần phải tìm hiểu hết thì mới có thể nghiên cứu không?

Chỉ cần pattern matching là dc, làm tới đâu học tới đó (làm sẽ phát hiện). Cần độ chính xác hơn thì cần học thêm.

Giả sử em tìm được các artifacts và vẽ được DFD rồi thì làm sao mình biết cái DFD của mình là đúng?

Mình code ứng dụng nên mình biết sẽ bị lỗi ở đâu, và chạy threat modeling để compare.

Tìm tất cả các attack surface của dApp và tìm tất cả các vulnerability thông qua một tool khác, nếu tất cả vulnerability thuộc các attack surface tìm được thì là đúng.

Trong trường hợp sau nhiều tuần cố gắng mà mình không thể tìm được các artifact hoặc chỉ tìm được một vài artifact thôi thì mình có cần: đổi sang một domain khác chẳng hạn như Android không?

Có thể (thời gian khoảng 1 tháng)

Trong quá trình xây dựng DFD, không nhất thiết phải sử dụng static analysis đúng không? Chẳng hạn như trong quá trình em viết rules mà em tìm ra được luôn artifact ấy ạ (vấn đề về bias)

Làm cho các ứng dụng khác hoặc sử dụng tool static analysis khác để test và đối chiếu. Các tool static analysis sẽ tìm bug, nhưng bug thì lại thuộc về attack surface, nên do đó ta có thể sử dụng để đối chiếu.

Làm sao đánh giá được một cái project nào là có architecture phức tạp?

Chưa cần đến mức sử dụng một project phức tạp.

Metting Notes ✍️

Literature review:

  • Đọc nhiều paper và thống kê để có cái nhìn tổng quan cũng như là xem hướng mình đang làm có bị trùng hay không.
  • Khi đọc không cần hiểu hết paper: paper làm gì method là gì, kết quả ra sao.
  • Cần phải lựa các paper tốt để đọc.

Roadmap:

  • Hiện tại chưa cần DFD. Thay vào đó là tìm các attack surface (entry points hoặc exit points). Vì thế, cần phải xác định dApp có attack surface gì (cần phải hiểu thêm về kiến trúc của dApp).
  • Fuzzing (cho Android): có thể làm đồng thời.
  • Giai đoạn đầu có thể tập trung vào một ứng dụng cụ thể. Sau đó thì tổng quát hóa nếu có thể.
  • Aim: thời gian 3 tháng có thể tạo ra một prototype (chưa cần phải là tool) để trích xuất entry/exit points của một dApp bất kỳ.

Giải quyết các vấn đề trước đó:

  • Smart contract nhỏ không đủ quy mô: nên cân nhắc dùng dApp.
  • Cần mapping table: checked (đọc báo để hiểu về kiến trúc).

Semgrep: là kỹ thuật pattern matching, không nhất thiết là để tìm vulnerability.

Cách kiểm tra xem paper có xịn hay không:

  • Trên 100 citation: rất ổn.
  • Citation dưới 2 chữ số: chưa ổn (trừ mới nhất).
  • Xem các paper trong 5 năm đổ lại.
  • Nếu là journal paper: copy vào Scimajor, kiểm tra nếu là Q1, Q2 thì ok.
  • Nếu là conference paper thì ưu tiên hơn (journal thì thường bị out-dated), xem rank ở Conference Portal: A*, A hoặc B thì ok.
  • Kiểm tra các hình ảnh có bị bể hay không.
  • Ngoài Google Scholar thì có thể search trên IEEE, Springer.
  • Những trang web kể trên đều có trong before you work.