{
	"id": "e3b13a0f-4bfd-40c7-9fc7-f557132f80c8",
	"created_at": "2026-04-06T00:22:16.8509Z",
	"updated_at": "2026-04-10T13:11:46.021107Z",
	"deleted_at": null,
	"sha1_hash": "b7094f8e73038f685b976deac1b9179bfae33d6b",
	"title": "Man-in-the-Disk: A New Attack Surface for Android Apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 47078,
	"plain_text": "Man-in-the-Disk: A New Attack Surface for Android Apps\r\nBy bferrite\r\nPublished: 2018-08-12 · Archived: 2026-04-05 15:33:37 UTC\r\nRecently, our researchers came across a shortcoming in the way Android apps use storage resources. Careless use\r\nof External Storage by applications may open the door to an attack resulting in any number of undesired\r\noutcomes, such as silent installation of unrequested, potentially malicious, apps to the user’s phone, denial of\r\nservice for legitimate apps, and even cause applications to crash, opening the door to possible code injection that\r\nwould then run in the privileged context of the attacked application.\r\nThese Man-in-the-Disk attacks are made possible when applications are careless about their use of External\r\nStorage, a resource that is shared across all applications and does not enjoy Android’s built-in Sandbox protection.\r\nFailing to employ security precautions on their own leaves applications vulnerable to the risks of malicious data\r\nmanipulation.\r\nWhat is External Storage?\r\nIn order to explain the security deficiency in Android’s design, we need to understand a little about the storage\r\nresources on an Android device.\r\nWithin the Android OS there are two types of storage: Internal Storage, which each application uses separately\r\nand is segregated by the Android Sandbox, and External Storage, often over an SD card or a logical partition\r\nwithin the device’s storage, which is shared by all applications. Indeed, the External Storage is primarily used to\r\nshare files between applications or with a PC. For example, in order for a messaging app to share a photo from the\r\nphone’s gallery, the application needs to have access to media files held in the External Storage.\r\nThere are, however, other reasons why an app developer would choose to use External Storage rather than the\r\nsandboxed Internal one. Such reasons range from a lack of sufficient capacity in the internal storage, backwards\r\ncompatibility considerations with older devices, not wanting the app to appear to use too much space, or even just\r\nmere laziness on the developer’s part.\r\nWhatever the reason may be, when using the External Storage, certain precautions are necessary.\r\nAccording to Google’s Android documentation, application developers are advised on how they should use the\r\nExternal Storage in their apps. These guidelines include:\r\n“Perform input validation when handling data from external storage”\r\n“Do not store executables or class files on External Storage”\r\n“External Storage files should be signed and cryptographically verified prior to dynamic loading”\r\nHowever, we have seen a few examples where Android apps, including apps from known OEM and even Google,\r\ndo not follow these guidelines. And herein lays the Man-in-the-Disk attack surface, offering an opportunity to\r\nattack any app that carelessly holds data in the External Storage.\r\nhttps://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/\r\nPage 1 of 4\n\nThe Man-in-the-Disk Attack\r\nThe new attack surface found by Check Point researchers, dubbed ‘Man-in-the-Disk’, allows an attacker to enter\r\nand meddle with data stored on the External Storage.\r\nThrough our research analysis we have witnessed cases where an app was downloaded, updated or received data\r\nfrom the app provider’s server, which passed through the External Storage before being sent on to the app itself –\r\nas seen in the diagram on the left. Such practice offers an opportunity for an adversary to manipulate the data held\r\nin the External Storage before the app reads it again.\r\nMeddling with the data occurs using a seemingly innocent application, e.g. a fake flashlight app, within which\r\nholds the attacker’s exploit script. The user is persuaded by the attacker to download this innocent looking app,\r\nwhich in turn asks for the user’s permission to access the External Storage, something which is perfectly normal\r\nfor apps to request, and is unlikely to raise suspicion on the user’s behalf. From that point on, the attacker is able\r\nto monitor data transferred between any other app on the user’s device and the External Storage, and overwrite it\r\nwith his own data in a timely manner, leading to the unwelcome behavior of the attacked application.\r\nIn this way, the attacker has his ‘Man-in-the-Disk’ looking out for ways in which he can intercept traffic and\r\ninformation required by the user’s other existing apps, and offer a carefully crafted derivative of the data that\r\nwould lead to harmful results.\r\nThe results of the attacks can vary, depending on the attacker’s desire and expertise. Our research demonstrated\r\nthe ability to install an undesired application in the background, without the user’s permission. We have also\r\ndemonstrated the ability to crash the attacked application, causing it a denial of service. Once crashed and with the\r\napp’s defenses down, the attacker could then potentially carry out a code injection to hijack the permissions\r\ngranted to the attacked application and escalate his own privileges in order to access other parts of the user’s\r\ndevice, such as the camera, the microphone, contacts list and so forth.\r\nApplications Where the Man-in-the-Disk Lives\r\nAmong the applications which were tested for this new attack surface were Google Translate, Yandex Translate,\r\nGoogle Voice Typing, Google Text-to-Speech, Xiaomi Browser and various additional applications. After referring\r\nto the advice given within Google’s guidelines, our team proceeded to compare the advice to what is actually the\r\ncase.\r\nIn the case of Google Translate, Yandex Translate and Google Voice Typing, we found that the developers failed to\r\nvalidate the integrity of data read from the External Storage. As such, our team was able to compromise certain\r\nfiles required by these apps, resulting in the crash of each of these applications.\r\nApplication Crash Example: Google Translate is caused to crash by\r\ncompromising certain files required by the app.\r\nXiaomi Browser was found to be using the External Storage as a staging resource for application updates. As a\r\nresult, our team was able to carry out an attack by which the application’s update code was replaced, resulting in\r\nthe installation of an alternative, undesired application instead of the legitimate update.\r\nhttps://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/\r\nPage 2 of 4\n\nMan-in-the-Disk Attack Example: Xioami Browser’s update code is replaced,\r\nresulting in the installation of an undesired and malicious app.\r\nUpon discovery of these application vulnerabilities, we contacted Google, Xiaomi and vendors of other vulnerable\r\napplications to update them and request their response. A fix to the applications of Google was released shortly\r\nafter, additional vulnerable applications are being updated and will be disclosed once the patch is made available\r\nto their users, while Xiaomi chose not to address it at this time.\r\nOf course, it should be noted that our research only examined a small sample of applications. The prevalence of\r\nthese vulnerabilities among our sample set leads us to believe that many other apps use the External Storage\r\nresource carelessly, and may therefore be susceptible to similar attacks.\r\nFurthermore, the greater the number of privileges an application has access to, the more an attacker has to gain.\r\nIndeed, code injection to a privileged application would gain access to all of its privileges. Worryingly, though,\r\nsome of the apps we found to be vulnerable to the Man-in-the-Disk are actually already pre-installed from the\r\nmanufacturers, along with pre-granted permissions that the user had not even actively agreed to, and are therefore\r\navailable as a window of opportunity for an attacker on every single device of this manufacturer.\r\nCause and Effect\r\nAs the details of this attack may seem complex, let us recap the general outline and ramifications of these\r\nshortcomings of Android:\r\nAn Android device’s External Storage is a public area which can be observed or modified by any other\r\napplication on the same device.\r\nAndroid does not provide built-in protections for the data held in the External Storage. It only offers\r\ndevelopers guidelines on proper use of this resource.\r\nDevelopers anywhere are not always versed in the need for security and the potential risks, nor do they\r\nalways follow guidelines.\r\nSome of the pre-installed and popularly used apps ignore the Android guidelines and hold sensitive data in\r\nthe unprotected External Storage.\r\nThis can lead to a Man-in-the-Disk attack, resulting in the manipulation and/or abuse of unprotected\r\nsensitive data.\r\nModification to the data can lead to unwelcome results on the user’s device.\r\nProtecting Against ‘The Man’\r\nWhile it is clear that these design shortcomings leave Android users potentially vulnerable to cyber threats, what is\r\nless clear is who is really at fault and where the responsibility lies in fixing them. On the one hand, although\r\nAndroid’s developers have created guidelines to app developers on how to ensure their apps are safe, they must\r\nalso be aware that it is well known for developers to not build their applications with security front of mind. On\r\nthe other hand, and being aware of this foresaid knowledge, is there more Android could be doing to protect their\r\noperating system and the devices that use it?\r\nOne could equate what we are seeing here in the world of mobile operating systems to the naïve design of old\r\noperating systems, which used to allow for buffer overflows to run amok. While the buffer overflow\r\nhttps://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/\r\nPage 3 of 4\n\nvulnerabilities were generated by careless developers everywhere, it wasn’t until OS and CPU makers took a stand\r\nagainst this, introducing DEP and ASLR protections, that the problem was averted. In the heart of this was the\r\nrealization that developers cannot always be trusted to follow security guidelines.\r\nFrom experience then, it would seem that mere guidelines are not enough for OS vendors to exonerate themselves\r\nof all responsibility for what is designed by app developers. Instead, securing the underlying OS is the only long\r\nterm solution to protecting against this new attack surface uncovered by our research.\r\nFor full technical details on this research, please visit Check Point Research.\r\nSource: https://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/\r\nhttps://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.checkpoint.com/security/man-in-the-disk-a-new-attack-surface-for-android-apps/"
	],
	"report_names": [
		"man-in-the-disk-a-new-attack-surface-for-android-apps"
	],
	"threat_actors": [],
	"ts_created_at": 1775434936,
	"ts_updated_at": 1775826706,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b7094f8e73038f685b976deac1b9179bfae33d6b.pdf",
		"text": "https://archive.orkl.eu/b7094f8e73038f685b976deac1b9179bfae33d6b.txt",
		"img": "https://archive.orkl.eu/b7094f8e73038f685b976deac1b9179bfae33d6b.jpg"
	}
}