Nomadic Honeypots : A Novel Concept for Smartphone Honeypots
Nomadic Honeypots : A Novel Concept for Smartphone Honeypots
复制标题
游牧蜜罐：智能手机蜜罐的新颖概念
DOI：
--
复制
发表时间：
2013
期刊：
影响因子：
--
通讯作者：
Collin Mulliner
中科院分区：
文献类型：
--
作者：
Steffen Liebergeld;Matthias Lange;Collin Mulliner
关于移动威胁的情报是一笔宝贵的财富。蜜罐为获取其他领域的威胁情报提供了良好的资源。不幸的是，目前的恶意软件主要依靠社交工程来感染智能手机。最近，针对智能手机的攻击已经转向了本地通信接口。这些趋势使得传统的蜜罐概念不再适用。我们提出了一个名为“游牧蜜罐”的新概念，它提供了一个基础设施，使移动网络运营商能够直接在智能手机上收集威胁情报。我们提出了一种实用的设计，将移动操作系统限制在虚拟机中。通过虚拟化，可以监控所有通信接口。实际的监视由运行在同一设备上的第二个虚拟机执行。这台机器装有传感器，并为操作员提供了一个安全的反向通道。我们的游牧蜜罐是供人们使用的。因此，它有能力捕获通过应用商店分发的恶意软件，以及使用NFC，蓝牙和QR码等本地通信攻击智能手机的未来威胁。我们实现了一个在现成智能手机上运行的原型。关键词：智能手机，蜜罐，恶意软件，蠕虫，威胁情报，系统虚拟化随着智能手机的日益普及，恶意软件对智能手机的吸引力也越来越大。事实上，智能手机的安全性——或者说安全性的缺乏——已经达到了一定程度的宣传，消费者对此非常关注。随着安全成为一个卖点，能够警告和保护客户成为蜂窝运营商的宝贵资产。Zhou等人发现93%的恶意软件样本使用C&C通道，这使它们成为机器人。这种僵尸网络对核心蜂窝网络[11]非常有害。因此，为了能够制定对抗措施，了解这种威胁符合操作者的利益。在IP网络中，蜜罐已经被成功地用于收集威胁信息。然而，经典的基于被动ip的蜜罐并不适合智能手机上的感染载体。如今，大多数恶意软件都是由用户自己安装的，例如，当他从黑市安装受感染的应用程序时。我们还通过恶意QR码[1]观察到第一批感染。我们观察到，智能手机和它的用户形成了一个“非常高的互动”蜜罐。关键的观点是，用户是蜜罐的一部分。当用户安装恶意软件，扫描恶意QR码，并与恶意NFC设备和RFID标签交互时，用户不自觉地增加了蜜罐的可见性。基于这一见解，我们认为收集当前移动威胁情报的最佳地点是设备本身。为此，我们引入游牧蜜罐的概念。今天，大约37%的Android恶意软件包含root漏洞来提升其权限。如果成功，操作系统的所有安全措施都将失效。因此，我们不能在移动操作系统本身中托管我们的解决方案。相反，我们将设备分为两个逻辑分区。我们将整个移动操作系统移到它自己的分区中，并移除它对设备通信硬件的直接访问。在第二个分区中，我们托管游牧蜜罐基础设施。它有四个职责：第一，它控制通信接口并协调移动操作系统的所有通信。其次，它拥有广泛的传感器来收集和过滤通信接口上的事件。第三，实现了手机操作系统的快照和日志记录功能。第四，它建立了一个安全的反向通道与运营商通信。为了展示如何在实践中构建游牧蜜罐，我们提出了一个基于现代微内核的设计。我们用虚拟机（vm）实现分区。我们实现了一个在现成的三星Galaxy S2智能手机上运行的原型。•游牧蜜罐的概念我们引入游牧蜜罐作为直接在移动设备上收集威胁信息的基础设施。•实用设计我们展示了我们游牧式蜜罐的实用设计。我们使用虚拟化来限制移动操作系统，并消除其对通信硬件的直接访问。我们在一个单独的VM中调解所有通信，在那里我们部署收集信息的传感器和一个安全的反向通道。本文的结构如下。我们在第一节中介绍了游牧蜜罐的概念，然后在第二节中展示了如何在实践中构建游牧蜜罐。我们在第三节展示了我们的原型，并在第四节提出了传感器的想法。第五节和第六节讨论了游牧蜜罐的伦理含义以及运营商如何部署它们。我们在第七节结束。游牧式蜜罐的概念游牧式蜜罐直接部署在智能手机上。在我们的概念中，用户扮演着关键角色，因为他负责蜜罐的可见性：他将蜜罐移动到有趣的区域，扫描恶意QR码并安装恶意应用程序。理想情况下，游牧蜜罐是用户每天使用的主要智能手机。我们在第六节中讨论了运营商如何使人们使用游牧蜜罐的想法。从概念上讲，游牧蜜罐要求智能手机在逻辑上分为两个孤立的分区。主分区承载移动操作系统，但不能直接访问设备的通信硬件。恶意软件通常包括检查它是否在不寻常的环境（如模拟器）中运行，并关闭其恶意负载以逃避检测。因此，尽可能少地修改移动操作系统至关重要。第二个分区承载了我们的游牧蜜罐的基础设施。它有四项职责：首先，它协调移动操作系统的所有通信。其次，它承载数据收集的基础设施（传感器）。第三，它实现了快照和日志记录功能。第四，为运营商提供了安全的反向通道。调解所有通信有两个目的。首先，它允许强大的传感器直接监控数据流，没有任何通信被忽视。其次，它允许我们限制恶意软件并阻止其传播。分区之间的严格隔离确保了即使是被破坏的移动操作系统也无法篡改移动蜜罐的基础设施。因此，操作人员可以信任由移动蜜罐收集的信息。建立反向通道所需的加密密钥仍然是保密的，攻击者不能使用它们连接到操作员。运营商可以使用收集到的数据来获取移动威胁的情报。他可以请求手机操作系统文件系统的快照，以便对攻击进行离线取证分析。因此，他可以深入了解威胁的性质，并利用他的发现来保护他的客户。图1给出了一个游牧蜜罐的实例。二世。在本节中，我们将展示如何为当今的智能手机硬件构建一个游牧蜜罐。最突出的问题是如何对设备进行分区。ARM TrustZone[10]实现硬件分区。我们希望能够将我们的“游牧蜜罐”部署到所有智能手机上。因此，TrustZone不是一个选项，因为它不是在所有智能手机中实现的。即使实现了它，它通常也是不可用的，因为OEM已经部署了一个无法替换的安全监视器。相反，我们选择在微内核上进行虚拟化。正如Lange等人所表明的那样，即使在运营商恶意WiFI通知形式下，Android等移动操作系统的虚拟化也是可能的
Intelligence on mobile threats is a valuable asset. Honeypots showed to provide a good resource to gain threat intelligence in other areas. Unfortunately, current malware largely relies on social engineering to infect smartphones. Recently, attacks against smartphones have shifted towards local communication interfaces. These trends make traditional honeypot concepts unsuitable. We propose a novel concept called nomadic honeypot that provides an infrastructure to enable mobile network operators to collect threat intelligence directly on smartphones. We present a practical design that confines the mobile operating system in a virtual machine. Through virtualization all communication interfaces can be monitored. The actual monitoring is carried out by a second virtual machine running on the same device. This machine hosts sensors and provides a secure backchannel for the operator. Our nomadic honeypot is meant to be used by people. Thus it has the capability to catch malware that is distributed through app stores as well as future threats that attack the smartphone using local communication such as NFC, Bluetooth, and QR codes. We implemented a prototype that runs on an off the shelf smartphone. Keywords-smartphone, honeypot, malware, worms, threat intelligence, system virtualization With rising popularity, smartphones become increasingly attractive for malware. In fact, smartphone security–or the lack thereof–has reached a level of publicity, where customers are very conscious about it. With security becoming a selling argument, being able to warn and protect customers becomes a valuable asset for cellular operators. Zhou et al. [12] found 93% of malware samples to employ C&C channels, which makes them bots. Such botnets can be very harmful to the core cellular network [11]. Therefore it is in the interest of the operators to know about such threats in order to be able to enact countermeasures. In IP networks Honeypots have been successfully used to collect threat information. However, the classical passive IPbased Honeypot does not fit the infection vectors on smartphones. Most malware today is being installed by the user himself, for example when he installs an infected App from a black market. We also observed the first infections through malicious Quick Response (QR) codes [1]. We observe that the smartphone and its user form a ”very high interaction” honeypot. The key insight is that the user is a part of the honeypot. The user involuntarily increases the honeypot’s visibility, when he installs malware, scans malicious QR codes, and interacts with malicious NFC devices and RFID tags. With this insight, we determined that the best place to collect intelligence on current mobile threats is the device itself. To this end, we introduce the concept of nomadic honeypots. Today about 37% [12] of Android malware contains root exploits to elevate its privileges. If it succeeds all security measures of the operating system (OS) become useless. Thus we cannot host our solution in the mobile OS itself. Instead we divide the device into two logical partitions. We move the entire mobile OS into its own partition and remove its direct access to the device’s communication hardware. In a second partition we host the nomadic honeypot infrastructure. It has four obligations: First it controls the communication interfaces and mediates all communication of the mobile OS. Second it hosts a wide range of sensors to collect and filter events on the communication interfaces. Third it implements facilities for snapshots and logging of the mobile OS. Fourth it establishes a secure backchannel to communicate with the operator. To show how nomadic honeypots can be constructed in practice, we present a design that is based on a modern microkernel. We implement the partitions with virtual machines (VMs). We implemented a prototype that runs on an off the shelf Samsung Galaxy S2 smartphone. Our contributions are: • Concept of nomadic honeypots We introduce nomadic honeypots as an infrastructure to collect information on threats directly on mobile devices. • Practical design We present a practical design of our nomadic honeypot. We employ virtualization to confine the mobile OS and remove its direct access to communication hardware. We mediate all communication in a separate VM, where we deploy sensors which collect information, and a secure backchannel. This paper is structured as follows. We introduce the concept of nomadic honeypots in Section I. Then we show how a nomadic honeypot can be constructed in practice in Section II. We show our prototype in Section III, and present ideas for sensors in Section IV. Sections V and VI discuss the ethical implications of nomadic honeypots and how operators can deploy them. We conclude in Section VII. I. CONCEPT OF A NOMADIC HONEYPOT The nomadic honeypot is deployed directly on a smartphone. In our concept the user plays a key role, as he is responsible for the visibility of our honeypot: He moves the honeypot into interesting areas, scans malicious QR codes and installs malicious applications. Ideally the nomadic honeypot is the primary smartphone of the user that he uses on a daily basis. We discuss an idea on how operators can make people use nomadic honeypots in Section VI. Conceptually the nomadic honeypot requires that the smartphone is logically divided into two isolated partitions. The main partition hosts the mobile OS, but has no direct access to the device’s communication hardware. Malware often includes checks if it is being run in an unusual environment such as an emulator, and turns off its malicious payload to escape detection. Therefore it is vital that the mobile OS is modified as little as possible. The second partition hosts the infrastructure for our nomadic honeypot. It has four obligations: First, it mediates all communication of the mobile OS. Second, it hosts infrastructure for data collection (sensors). Third, it implements facilities for snapshots and logging. And fourth, it provides a secure backchannel for the operator. Mediating all communication serves two purposes. First, it allows for powerful sensors that can monitor the data stream directly and no communication goes unnoticed. Second, it allows us to confine malware and stop it from spreading. Strict isolation between the partitions ensures that even a subverted mobile OS cannot tamper with the nomadic honeypot’s infrastructure. Therefore the operator can trust in the information that is being collected by the nomadic honeypot. Cryptographic keys that are needed to establish the backchannel remain confidential, and an attacker cannot use them to connect to the operator. The operator can use the collected data to gain intelligence on mobile threats. He can request snapshots of the mobile OS’s file system to do an offline forensic analysis of attacks. Thereby he can gain thorough insight on the nature of the threats and use his findings to protect his customers. An illustration of nomadic honeypots in action is given in Figure 1. II. DESIGN OF A PRACTICAL NOMADIC HONEYPOT In this section we show how a nomadic honeypot can be constructed for today’s smartphone hardware. The most prominent question is how to partition the device. ARM TrustZone [10] implements partitioning in hardware. We want to be able to deploy our nomadic honeypot to all smartphones. Therefore TrustZone is not an option because it is not implemented in all smartphones. Even if it is implemented, it is usually not available because the OEM already deployed a secure monitor that cannot be replaced. Instead we opt to do virtualization on a microkernel. As shown by Lange et al. [7] virtualization of mobile OSes like Android is possible even on Operator Malicious WiFI Inform In fo rm