Two men charged with hacking CIA director and other high-ranking officials


Federal authorities have arrested two men on charges they were part of a group that broke into the private e-mail accounts of high-ranking US government officials and a Justice Department computer system.

Andrew Otto Boggs, 22, of North Wilkesboro, North Carolina, and Justin Gray Liverman, 24, of Morehead City, North Carolina, were part of a group calling itself "Crackas with Attitude," federal prosecutors alleged. Although an FBI affidavit filed in the case didn't identify the targeted government officials by name, The Washington Post and other news organizations, citing unnamed people familiar with the matter, said they included CIA Director John Brennan, then-Deputy FBI Director Mark Giuliano, National Intelligence Director James R. Clapper, and other high-ranking officials. The group also used its unauthorized access to a Justice Department management system to obtain and later publish the names, phone numbers, and other personal details of more than 29,000 FBI and Department of Homeland Security officials.

According to the affidavit, the group didn't rely on computer hacking to break into restricted accounts. Instead, they used social engineering, in which they impersonated their targets and various IT support personnel purporting to help the victims. On October 11, 2015, one of the suspects allegedly accessed the account of one target, identified by the WaPo as Brennan, by posing as a technician from Verizon. The suspect then tricked another Verizon employee into resetting the password for Brennan's Internet service. Prosecutors said the suspects went on to take over a Brennan AOL account.

Read 4 remaining paragraphs | Comments

How to: Testing Android Application Security, Part 3

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the third in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications.In this chapter, we’ll look at reviewing Android’s manifest file.

Every Android binary is packaged with the file Andoridmanifest.xml, which provides the system with necessary information such as permissions, intents, activities, services, broadcasts, etc. It also functions as a basic configuration file.


You can obtain the manifest file by changing the Android binary extension from .apk to .zip. However, this change does not create a readable format. To convert manifest into readable format you can use Apktool to disassemble the Android binary. Once the binary is disassembled, the manifest file is readable. You can also use Manifest Explorer to view the manifest file.


Apktool d binarypathbinaryname


Here we see the manifest file for the test application Sieve:


You should review several elements in the manifest file.

  1. Package name: The package name is the unique name of the application, with the application data generally present in the folder /data/data/packagename in the Android directory. While reviewing Packagename it is useful to identify and examine the application directory for any sensitive data.
  2. Permissions: An application should not request unnecessary permissions. Only the permissions required by the application should be assigned. For example, if an application does not need access to GPS or the camera, then these permissions should not be requested.

android:protectionLevel defines the risks associated with permissions. If a permission is marked as dangerous, you should review this permission because it may grant control to the device or user data. Some permissions categorized as dangerous:

  • Calendar
  • Camera
  • Contacts
  • Location
  • Microphone
  • Phone
  • Sensors
  • SMS
  • Storage

For detailed information on permissions refer to this link.

  1. Exported components: This element provides the components of an application (provider, activity, service, or receiver) to be invoked by other application components.

If this value is set to true, other components can access this application’s components.

For example, if in a banking application a “view account statement activity” has exported a value set to true, a malicious application could invoke it. Thus this value should be set to false.


An example of the fourgoats application with the exported value set to true.


  1. Android flags (debuggable, backup): The manifest file contains information about Android flags.

Android backup: Allows the application to participate in backup. This is not desirable in cases where the application has sensitive data and user data is at risk due to the backup.

Android debuggable: This flag indicates whether the Android application can be debugged. Once the application moves from test to production, the debug flag should be set to false. If this flag is set to true, any entity with access to the device can execute code under the application’s permissions, and can also obtain sensitive data from the application.

During the security review these flags should be set to false:


  1. API level

The attribute android:minSdkVersion defines the minimum API level required by the application to run on an emulator or device. If the device version is earlier than the minsdkversion, the application may not run on the device. No application should support obsolete versions. The latest API level is 24.

The post How to: Testing Android Application Security, Part 3 appeared first on McAfee.