当EFBFBD来敲门 – 对Java中字符串与byte数组转换对一个观察及相关的安全隐患

我（指原作者，下文同）正在进行一个激动人心的Android应用安全审计，发现了如此多的漏洞以至于我觉得对于开发来说全部推倒重写都比修掉发现的这么多漏洞省事。正在我洋洋得意的时候，忽然发现在hook的输出中有如下有些奇怪的加密key，喜悦和兴奋变成了疑惑和好奇:

Entryption Key:

EFBFBDEFBFBDEFBFBD603466EFBFBD7BEFBFBD6C24E2B2AA576AEFBFBDEFBFBDEFBFBD0C6BEFBFBDEFBFBDEFBFBDEFBFBD76EFBFBDEFBFBDEFBFBDEFBFBDEFBFBD

为什么这个加密密钥有如此多重复的’EFBFBD’字符串模式？难道是subustrate hook代码写错了，还是开发者在生成key的时候犯了错误，还是说这压根是打印错了并不是应用真正用来加密的密钥？

从源代码寻找原因

虽然我并没有这个应用的源代码，但不是可以反编译的嘛。通过包括动态hook和静态阅读混淆过的源代码在内的一系列方法和手段，我们能确认说hook代码并没有错，输出也就是我们想要的加密key. 那么下一步就是需要分析这个奇怪的key的生成方式，隐患也就在这里隐藏着。

出于简便起见，我们编写了一个简单的样例应用来复现这个问题。代码如下：

public static String genKey(){
PBEKeySpec localPBEKeySpec = new PBEKeySpec(
    getPassword().toCharArray(), getSalt(), 20000, 256);
try {
    byte[] theKey =
        SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1")
            .generateSecret(localPBEKeySpec).getEncoded();
    return new String(theKey);
} catch (InvalidKeySpecException e) {
    e.printStackTrace();
} catch (NoSuchAlgorithmException e) {
    e.printStackTrace();
}
return null;
}

你发现问题在哪里了吗？没有的话也不要担心，我们下面会来具体进行分析。

大体上来说，这个函数使用用户的密码派生出一个加密密钥。这个加密密钥用来加密保护所有保存在设备中的该应用私有信息资源。首先这个应用将用户的密码，盐值，迭代次数（这里是20000轮）和想要得到的密钥长度（256bits)一起作为参数创建PBEKeySpec密钥生成器，随后用它生成一个加密密钥并存储到byte数组中。到这里来说一切都还是正常的，但是下一句看似无辜的将byte array转换成String的语句就是真正的罪魁祸首。

我们来在这段代码中插入bytesToHex这样十六进制输出语句，以获得key十六进制的输出并进行前后对比

public static String genKey(){
PBEKeySpec localPBEKeySpec = new PBEKeySpec(
    getPassword().toCharArray(), getSalt(), 20000, 256);
try {
    byte[] theKey =
        SecretKeyFactory.getInstance(“PBKDF2WithHmacSHA1”)
            .generateSecret(localPBEKeySpec).getEncoded();
    Log.i(_TAG, “Key (Before Casting): ” +
        bytesToHex( theKey ) );
    return new String(theKey);
}
..snip..
}
public static void test() {
String theKey = genKey();
Log.i(_TAG, “Key (After Casting): ” +
    bytesToHex(theKey.getBytes()));
}

得到的输出是：转换前

B7B0F88D603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3

转换后

EFBFBDEFBFBDEFBFBD603466EFBFBD7BEFBFBD6C24E2B2AA576AEFBFBDEFBFBDEFBFBD0C6BEFBFBDEFBFBDEFBFBDEFBFBD76EFBFBDEFBFBDEFBFBDEFBFBDEFBFBD

Android中byte数组到字符串的转换

目前来说我们已经能够确定，这个奇怪的EFBFBD是因为bytearray到string的转换引入的，那EFBFBD究竟是个什么意思？（译者注：其实就是�符号）

根据Android文档，”Android平台默认的编码是UTF-8（注意这和一些旧的编码基于用户地区的系统相反).” 在UTF-8中，’EFBFBD’这个十六进制字符串代表替换字符(replacement character).简单来说，一个替换字符的作用是代替一个未知或无法表示的传入字符（译者注：Unicode字符单字节是0x00-0x7F的范围）。这意味着转换后的String中，每一个EFBFBD序列都对应着原始字符串中的一个无法表示的byte（或者说两个hex position)。为了证实这个想法，我们将转换后的字符串中的EFBFBD做一个替换：

B7B0F88D603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3
!!******603466**7B**6C24E2B2AA576A******0C6B********76**********

（注：”!!”是Android在转换时没有包括第一个byte，为了对齐而加上） 这个对比直观地展示了非法的Unicode byte都被星号所代替，也就是EFBFBD的位置。

其他系统中byte数组到字符串的转换

在观察了Android系统中这个并不寻常的行为之后，我们来看看其他平台上的行为。首先看看Windows。

这里要注意的是我们加了一句获取charset的代码，因为根据Java文档：”Java程序中默认字符集在JVM启动的时候设置，一般由操作系统的区域和字符集决定”。

public static String genKey(){
PBEKeySpec localPBEKeySpec = new PBEKeySpec(
    getPassword().toCharArray(), getSalt(), 20000, 256);
try {
    byte[] theKey =
        SecretKeyFactory.getInstance(“PBKDF2WithHmacSHA1”)
            .generateSecret(localPBEKeySpec).getEncoded();
    System.out.println(“Key (Before Casting): ” +
    bytesToHex( theKey ) );
    return new String(theKey);
 }
 ..snip..
 }
 return null;
 }
public static void main(String[] args) {
System.out.println(“Default Charset: ” +
    Charset.defaultCharset().name());
String theKey = genKey();
System.out.println(“Key (After Casting): ” +
bytesToHex(theKey.getBytes()));
}

在Eclipse, Windows 8.1(x64)上运行之后，我们得到了如下的输出：

`\ Default Charset:

windows-1252

Key (Before Casting):

B7B0F88D603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3

Key (After Casting):

B7B0F83F603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3 `\

虽然转换前后key看起来基本相同，第四个字节却略有区别。原始字符串中是8D，转换之后变成了3F。这是因为在这次测试中，目标操作系统的字符集是Windows-1252/CP-1252，根据MSDN文档，0x81, 0x8D, 0x8F, 0x90和0x9D是未定义并被Windows保留的。因此String转换发生之后，8D字符就被替换为了3F字符，也就是’?’——问号

其他操作系统结果列举

转换前的key（这个对于每个平台当然都是相同的）

B7B0F88D603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3

Android 4.3 Key (转换后):

EFBFBDEFBFBDEFBFBD603466EFBFBD7BEFBFBD6C24E2B2AA576AEFBFBDEFBFBDEFBFBD0C6BEFBFBDEFBFBDEFBFBDEFBFBD76EFBFBDEFBFBDEFBFBDEFBFBDEFBFBD

Windows 8.1 (转换后):

B7B0F83F603466CF7BF26C24E2B2AA576AAFC5E90C6BD4EECCC576B9D7F1E9C3

Ubuntu 12.04 (转换后):

EFBFBDEFBFBDEFBFBDEFBFBD603466EFBFBD7BEFBFBD6C24E2B2AA576AEFBFBDEFBFBDEFBFBD0C6BEFBFBDEFBFBDEFBFBDEFBFBD76EFBFBDEFBFBDEFBFBDEFBFBDEFBFBD

Mac OS X 10.10 (转换后):

EFBFBDEFBFBDEFBFBDEFBFBD603466EFBFBD7BEFBFBD6C24E2B2AA576AEFBFBDEFBFBDEFBFBD0C6BEFBFBDEFBFBDEFBFBDEFBFBD76EFBFBDEFBFBDEFBFBDEFBFBDEFBFBD

总结

本文分析了加密代码使用中常出现的一种错误转换问题，并指出了这种安全隐患的危害：会导致生成的密钥中出现大量的重复内容，增加了被爆破的风险。譬如说本文中提到的这个测试应用，它使用用户的密码生成一个加密密钥，但因为这个漏洞导致了密钥出现重复单元，降低了信息熵，也就是被爆破的难度。

参考

原文： http://blog.gdssecurity.com/labs/2015/2/18/when-efbfbd-and-friends-come-knocking-observations-of-byte-a.html

• http://developer.android.com/reference/java/nio/charset/Charset.html
• http://www.fileformat.info/info/unicode/char/0fffd/index.htm
• http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html#defaultCharset()
• http://en.wikipedia.org/wiki/Windows-1252
• http://msdn.microsoft.com/en-us/goglobal/cc305145.aspx
• http://en.wikipedia.org/wiki/UTF-8