Foundation Sec 8B Chinese Chat

🚀 🛡️ Foundation-Sec-8B-Chinese-Chat

8B 網絡安全語言模型，通過 Mergekit 合併而成，基於 Foundation-Sec-8B 的網絡安全大模型，融合了網絡安全知識與多語言能力。

🚀 快速開始

使用示例

import torch
import transformers
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "sds-ai/Foundation-Sec-8B-Chinese-Chat"
dtype = torch.bfloat16

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
        model_id,
        device_map="cuda",
        torch_dtype=dtype,
)

chat = [
    {
      "role": "user",
      "content": "介紹一下CVE-2021-44228，編寫python利用腳本"
    }
]

input_ids = tokenizer.apply_chat_template(
            chat, tokenize=True, add_generation_prompt=True, return_tensors="pt"
            ).to(model.device)

outputs = model.generate(
            input_ids,
            max_new_tokens=1024,
            temperature=0.6,
            top_p=0.9,
)
response = outputs[0][input_ids.shape[-1] :]
print(tokenizer.decode(response, skip_special_tokens=True))

✨ 主要特性

• 🔒 網絡安全專業能力：繼承 Foundation-Sec-8B 的網絡安全分析能力。
• 🧠 對抗推理能力：通過惡意推理模型增強威脅建模能力。
• 🌏 多語言支持：具備強大的中文處理能力。
• ⚙️ 高效性能：採用 FP16 精度配合 INT8 掩碼優化性能。

📚 詳細文檔

合併詳情

本模型採用 DARE-TIES 算法（動態正則化權重合並）進行融合，以 fdtn-ai/Foundation-Sec-8B 為基礎架構。

合併模型

整合了以下專業模型：

• fdtn-ai/Foundation-Sec-8B：網絡安全基礎模型
• DavidAU/L3.1-Evil-Reasoning-Dark-Planet-Hermes-R1-Uncensored-8B（權重: 0.5, 密度: 0.53）：強化攻擊者思維模擬能力
• shenzhi-wang/Llama3.1-8B-Chinese-Chat（權重: 0.3, 密度: 0.53）：中文理解和對話能力

配置

base_model: fdtn-ai/Foundation-Sec-8B
chat_template: auto
dtype: float16
merge_method: dare_ties
models:
  - model: fdtn-ai/Foundation-Sec-8B
  - model: DavidAU/L3.1-Evil-Reasoning-Dark-Planet-Hermes-R1-Uncensored-8B
    parameters:
      density: 0.53
      weight: 0.5
  - model: shenzhi-wang/Llama3.1-8B-Chinese-Chat
    parameters:
      density: 0.53
      weight: 0.3
parameters:
  int8_mask: true
  normalize: true
tokenizer_source: union

使用示例

max_new_tokens=1024, temperature=0.6, top_p=0.9

示例 1

用戶：PHP 的 GPC 是什麼？開啟了怎麼繞過？ 回答：GPC 是 PHP 中一個縮寫，代表"Get"和"Post/ Cookies"。在 PHP web 開發中，GPC 是指獲取和處理 HTTP 請求中的數據，包括 GET 請求和 POST 請求數據，以及處理 Cookie。

在 PHP 中，GPC 是指內置的內建變量，它允許你訪問 HTTP 請求中的數據。GPC 是 PHP 的內建功能，它可以讓你訪問 $_GET、$_POST 和 $_COOKIE 變量，這些變量包含了 HTTP 請求中的數據。

要在 PHP 中開啟 GPC 功能，你需要確保你的 PHP 腳本是通過 HTTP 請求來訪問的。通常，這是通過 Web 服務器（如 Apache 或 Nginx）來訪問的。

如果你想在 PHP 腳本中開啟 GPC 功能，你可以使用以下代碼：

<?php
// 開啟 GPC 功能
$_GET、$_POST、$_COOKIE;
?>

這段代碼會開啟 GPC 功能，允許你訪問 HTTP 請求中的數據。

要繞過 GPC 功能，你可以使用以下方法：

1. 使用 HTTPS 請求：如果你使用 HTTPS 請求，GPC 功能將被阻止，因為 HTTPS 請求不發送數據到服務器。
2. 使用 POST 請求：如果你使用 POST 請求，並且設置了請求頭中的 Content-Type 為 application/json 或者其他類型，GPC 功能將被阻止。
3. 使用 JSONP 請求：如果你使用 JSONP 請求，GPC 功能將被阻止，因為 JSONP 請求不發送數據到服務器。
4. 使用 CURL：你可以使用 PHP 的 CURL 擴展來發送 HTTP 請求，而不是依賴 GPC 功能。

繞過 GPC 功能的目的是為了保護敏感數據或防止跨站腳本攻擊（CSRF）等安全問題。

示例 2

用戶：SpringBoot 常見的接口路由洩漏有哪些？ 回答：在 Spring Boot 中，接口路由洩漏通常指的是在應用程序中定義了多個路由規則，但這些規則之間存在重疊或衝突，從而導致路由系統無法正確地處理請求。這可能會導致應用程序出現異常、錯誤或性能問題。

以下是一些常見的接口路由洩漏情況：

1. 重複定義路由：在配置文件中重複定義了相同的路由規則，這可能導致路由系統無法確定哪個規則應該應用。
2. 路由規則不匹配：定義了路由規則時，沒有考慮到請求的 HTTP 方法、請求參數、請求頭等因素，這可能導致路由系統無法正確匹配請求。
3. 路由規則優先級問題：在配置路由規則時，沒有明確指定優先級，導致某些規則被覆蓋或忽略。
4. 路由規則過於寬泛：定義了路由規則過於寬泛，導致多個路由規則之間存在重疊，從而導致路由系統無法正確地處理請求。
5. 使用了非標準的路由參數：在路由規則中使用了非標準的參數，例如使用了特殊字符或大小寫不正確的參數名，這可能導致路由系統無法正確解析請求。
6. 忽略了路由規則的前綴：在定義路由規則時，沒有考慮到請求的前綴，這可能導致路由系統無法正確匹配請求。
7. 使用了路由規則的正則表達式錯誤：在路由規則中使用了正則表達式時，沒有正確地定義正則表達式模式，這可能導致路由系統無法正確匹配請求。

為了避免這些問題，可以採取以下措施：

1. 使用路由規則的唯一標識符：確保每個路由規則有一個唯一的標識符，以便於區分和管理。
2. 使用路由規則的優先級：明確指定每個路由規則的優先級，以確保正確的規則被應用。
3. 驗證路由規則：在部署之前，驗證路由規則是否正確無誤，避免重複定義或衝突的規則。
4. 使用路由規則的正則表達式：確保在路由規則中使用正確的正則表達式模式，以便路由系統能夠正確匹配請求。
5. 使用路由規則的前綴：確保在路由規則中考慮到請求的前綴，以便路由系統能夠正確匹配請求。

通過採取這些措施，可以有效避免接口路由洩漏問題，從而提高應用程序的穩定性和性能。

示例 3

用戶：介紹一下 CVE-2021-44228，編寫 python 利用腳本？ 回答：CVE-2021-44228 是一個嚴重的漏洞，影響了由 Apache Log4j 版本 2.327 及更早版本的軟件。它是一個遠程代碼執行（RCE）漏洞，這意味著攻擊者可以利用該漏洞執行任意代碼。

CVE-2021-44228 是由 Apache Log4j 版本 2.327 及更早版本中的一個漏洞，稱為"Log4j Remote Code Execution Vulnerability"。該漏洞存在於 Log4j 的 JNDI 功能中，特別是在它處理 JNDI 環境變量時。

要利用這個漏洞，攻擊者需要將惡意的 JNDI 環境變量注入到 Log4j 處理的日誌記錄中。

以下是一個 Python 腳本，用於演示如何利用 CVE-2021-44228：

import socket

# 創建一個 socket 對象
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 設置一個偽造的 JNDI 環境變量
env = {
    "java.util.Logger": {
        "Logger": {
            "log4j-remote": {
                "port": "12345"
            }
        }
    }
}

# 發送惡意 JNDI 環境變量到目標服務器
sock.connect(("192.168.1.1", 12345))
sock.sendall(bytes("JNDI: java.util.Logger", encoding="utf-8"))

# 接收回顯信息
response = sock.recv(1024)
print(response)

# 關閉 socket 連接
sock.close()

示例 4

用戶：分析一個 android 應用的 apk 文件以尋找硬編碼的 API 密鑰或者不安全的網絡請求，你會用哪些工具組合？各自的作用是什麼？ 回答：為了分析 Android 應用的 APK 文件以尋找硬編碼的 API 密鑰或者不安全的網絡請求，你可以使用以下工具組合：

1. APKTool：
   • APKTool 是一個開源的工具，用於反編譯和分析 Android 應用的 APK 文件。
   • 它可以幫助你解析 APK 文件的結構，包括類、方法、資源等。
   • 作用：反編譯 APK 文件，分析應用的代碼和資源。
2. Dex2Jar：
   • Dex2Jar 是一個工具，用於將 Android 應用的.dex 文件轉換為可執行的 Java 字節碼。
   • 它可以幫助你分析應用的代碼，包括類、方法和變量。
   • 作用：將.dex 文件轉換為可執行的 Java 字節碼。
3. JD-GrepTools：
   • JD-GrepTools 是一個插件，用於在 JD (Java Decompiler) 中添加搜索功能。
   • 它可以幫助你快速定位到特定的代碼行或字符串。
   • 作用：在 JD 中搜索特定的代碼或字符串。
4. Burp Suite：
   • Burp Suite 是一個網絡安全工具套件，用於分析網絡流量和檢測潛在的安全漏洞。
   • 它可以幫助你分析應用的網絡請求，包括請求頭、響應體和數據傳輸。
   • 作用：分析網絡流量，檢測潛在的安全漏洞。
5. Wireshark：
   • Wireshark 是一個網絡協議分析工具，用於捕獲和分析網絡流量。
   • 它可以幫助你分析應用的網絡請求，包括協議、數據包和內容。
   • 作用：捕獲和分析網絡流量。
6. Malware Traffic Analysis (MTA)：
   • MTA 是一個網絡流量分析工具，用於分析惡意軟件的網絡行為。
   • 它可以幫助你識別不安全的網絡請求和行為。
   • 作用：分析惡意軟件的網絡行為。
7. Static Application Security Testing (SAST) 工具：
   • SAST 工具用於靜態代碼分析，識別潛在的安全漏洞。
   • 它可以幫助你檢查應用的代碼，識別硬編碼的 API 密鑰或不安全的網絡請求。
   • 作用：識別潛在的安全漏洞。

通過組合使用這些工具，你可以深入分析 Android 應用的 APK 文件，識別硬編碼的 API 密鑰或者不安全的網絡請求，從而提高應用的安全性。

示例 5

用戶：分析以下 CVE 描述並映射到對應的 CWE：提供簡要的選擇依據。 CVE 描述：Tenda AX1803 v1.0.0.1 在 getIptvInfo 函數中通過 iptv.city.vlan 參數存在棧溢出漏洞。 回答：

• CWE 映射：CWE-121 - Uncontrolled Stack Buffer Overflow
• 選擇依據：
  1. 棧溢出漏洞：CVE 描述明確指出存在棧溢出漏洞。
  2. 攻擊者可控參數：攻擊者可以通過 iptv.city.vlan 參數觸發棧溢出。
  3. 棧緩衝區溢出：漏洞涉及棧緩衝區溢出，攻擊者可以利用此漏洞進行攻擊。
  4. CWE-121：該漏洞屬於 CWE-121 類別，專門針對基於棧的緩衝區邊界操作不當導致的漏洞。

因此，CVE 描述中的漏洞應映射到 CWE-121 - Uncontrolled Stack Buffer Overflow。

📄 許可證

本模型使用 llama3.1 許可證。

⚠️ 重要提示

需注意的是，由於未經過監督微調（SFT）和強化學習（RL）訓練，模型在實際應用中可能存在一定侷限性。