使用Yara规则挖掘软件漏洞

引言

在软件中寻找漏洞本身并非易事。在云规模下手动执行此操作非常具有挑战性，因此我们使用工具来帮助识别模式或漏洞签名。Yara就是其中之一。

Yara在蓝队、恶意软件研究人员中非常流行，原因充分。一旦识别出恶意模式，编写规则以在大量文件集合中检测它就相当容易。

在本文中，我们将讨论Yara的另一种使用方式，从AppSec/红队角度出发。我们将研究如何创建规则来匹配不同类型的软件漏洞。示例包括可导致任意代码执行的反序列化漏洞、命令注入漏洞，甚至可能被绕过并导致SSRF的松散正则表达式，仅举几例。这并非详尽列表。

示例

C#

Binary Formatter

假设遇到类似以下代码：

1
2
3
4
5
6
7
8
9

static string GetClientEmail()
{
    string json = GetData();
    BinaryFormatter formatter = new BinaryFormatter();
    FileStream fs = File.Open(@"client.txt", FileMode.Open);
    object obj = formatter.Deserialize(fs);
    Account acobj = (Account)obj;
    return acobj.Email;
}

任何使用BinaryFormatter处理任意/不可信数据（如上述示例）都是不安全的。无法使其安全，因为其Deserialize()方法将首先检查文件流中提供的类型，然后进行任何转换。精心构造的负载将利用此功能执行恶意代码。与其他格式化程序不同，这无法通过实现SerializationBinder来缓解。.NET认为此行为是按设计进行的，不会发布修改它的缓解措施。

NewtonSoft.Json

下一个漏洞针对使用Newtonsoft JSON库反序列化不可信JSON负载。当TypeNameHandling设置为“Objects”或“All”时，这允许JSON.NET库检查所提供数据中的对象类型：

1
2
3
4
5
6

private static JsonSerializerSettings jsonSerializerSettings = new JsonSerializerSettings 
{ 
    TypeNameHandling = TypeNameHandling.All;
    // 注意，如果使用Objects而不是All，这也有效。
    TypeNameHandling = TypeNameHandling.Objects;
};

如果攻击者能够修改序列化数据，则这可能允许添加恶意对象类型，用于执行任意命令。如果此设置设置为“None”，或根本未指定（在这种情况下将默认为“None”），则意味着下面示例中的DeserializeObject函数不检查作为输入提供的字符串类型（下面示例中的“json”），这确保没有作为用户输入提供的不安全类型被反序列化。

示例1：

1
2
3
4
5
6
7

static string GetClientEmail()
{
    string json = GetData();
    var acobj = JsonConvert.DeserializeObject<Object>(json, jsonSerializerSettings);
    Account account = (Account)acobj;
    return account.Email;
}

示例2：

1
2
3
4
5
6
7

static string GetClientEmail()
{
    string json = GetData();
    var acobj = (Account)JsonConvert.DeserializeObject<Object>(json, jsonSerializerSettings);
    Account account = (Account)acobj;
    return account.Email;
}

上述两个示例都尝试将对象转换为我们的自定义类型“Account”：然而，这不成功，因为恶意负载在此之前已经执行。这是因为每当我们有泛型类型如“var”或