Push Notifications on DrupalGap Mobile Application.

In the past few days I was busy developing my DrupalGap Android Mobile Application. Although most of the features of DrupalGap are well-documented but there isn't too much clear information available on setting up push notifications on DrupalGap Mobile Application.
Here is a short write-up on how I set up the push notifications on my DrupalGap Android Mobile Application.
Hope this is helpful to the community.

The Prerequisites:

A Functioning Drupal Website and DrupalGap Mobile App 

Setting up the Platform:

We would first have to create Android API Key to send notifications from our Drupal Website to the Android device.In order to do this, follow the below mentioned steps:-

• Login to https://console.cloud.google.com with your google credentials . 
• On the dashboard, select the option to create a new project and name it.
• After creating a new project, a project number will be assigned to it. Make a note of the Project Number. This number will be the SENDER id.
• Now click on the Enable and Manage API's, an API Manager window will open up. Now click the Enable API option and than click on the Google Cloud Messaging option and enable it.
• After enabling the GCM option, it will tell you to create credentials. Click on "Go to Credentials" link. The First option (What kind of credentials are you using?) will be auto-populated as GCM. The Second option (Where you will be calling the API from?) should be selected as the Web Server.
• Next proceed to click on the link "What Credentials do i need?". Enter a name of your web-server over here (you may use your package name over here).
• Then select the option to "Create API Key". Make a note of this API Key since we will be using it in the next step.

Optional Step:(Restrict Usage only to Android apps)

• We can add the SHA1 certificate finger print to the the API Key in order to restrict the usage of notifications to the Android apps only.
• To do this, navigate to the root of your cordova project and run this command:  "keytool -genkey -v -keystore example.keystore -alias example -keyalg RSA -keysize 2048 -validity 10000"
• Follow all the prompts and make a note of the password you enter and then run this command: "keytool -exportcert -alias example -keystore example.keystore -list -v"
• Copy the SHA1 Finger Print.
• Now go to the GCM Project which we created in the earlier step and click on the Credentials tab. Click on the "Add Package Name and Finger Print" button and paste the SHA1 finger print. The Package name will the package name of your Android Application. This can be found in the AndroidManifest.xml file. 

Push Notifications Module Installation in Drupal Website:

After setting up GCM, we will now install the Push Notification module and set it up on on our Drupal Website

• Install the DrupalGap Module "Push Notifications" on your Drupal Website. The Module can be found at this link https://www.drupal.org/project/push_notifications. 
• Enable the necessary permissions from the Drupal Website for the Push Notifications module.
• Now on your Drupal website. Go to Configuration > Web services > Push Notification > Configure and paste the API Key generated from the previous step in the "Google Cloud Messaging API Key" field and save the configuration.
• Then we will go the Structure > Services Field. Here we should have the Drupalgap option. Click the "Edit Resources" button in the Drupalgap option  and select the Push Notification options along with the CRUD Operations of create resources and delete resources. Make sure to save the changes.
• At this point, flush all of Drupal's caches.( Click on  Home icon near the dashboard > Flush all caches)

Push Notifications Module Installation on DrupalGap:

Our next step will be to install the Push Notifications module on our DrupalGap Mobile Application and set it up accordingly.

• Install the Push notifications on your DrupalGap Mobile Application. The Module can be found at this link: https://github.com/signalpoint/push_notifications/archive/7.x-1.x.zip. 
• Ensure that after installation the Push Notification module resides in the app/modules/pushnotifications directory. Also enable the module by adding the line:  "Drupal.modules.contrib['push_notifications'] = {};" to your settings.js file in DrupalGap.
• Navigate to the app/modules/pushnotification directory and edit the push_notifications.js file. Add the Project Number (Sender id) to the push variable at the top of the file.Save the settings accordingly.

Handling the Push Notifications from the Website on the Device:

Now we have set up our Drupal Website to send out notifications to the DrupalGap Mobile App. The Next step will be to configure our DrupalGap Mobile Application to handle these incoming notifications.

• First, we have to create a hook to handle these incoming notifications. To create the hook go to the DrupalGap Web directory and browse to app/modules/custom folder.
• Create a new folder by the name of notifications and add a new file in it with the name as notifications.js. Add this code to the notifications.js file:

The Code for Notification.js file:

/**
 * Implements hook_push_notifications_receive().
 **/
function my_module_push_notifications_receive(data) {

  // data.message
  // data.title
  // data.count
  // data.sound
  // data.image
  // data.additionalData

  // Display the push notification.
  drupalgap_alert(data.message, {
    title: drupalgap.settings.title,
    buttonName: 'OK'
  });

}
#The Code can be customised to handle the incoming push notifications

• Make sure there are no syntax errors. Don't forget to enable this module from the settings.js file by adding the following line: Drupal.modules.custom['my_registration'] = {};"
• Now the mobile app should be able to handle the incoming notifications easily. Whenever there is an incoming notification an alert message would pop up on the android device.

Usage:

A quick walk-through of how to use the push notifications:

• Install the DrupalGap Mobile Application on the Android Device
• Login to the Drupal website and go to Configuration > Web services > Push Notification > Tokens
• You should see the Token for your Android device listed.
• Go to the Send Push tab and compose your message and send it to the appropriate device.
• The Notification should be visible on your mobile app in form of an alert box.

References: http://drupalgap.org/project/push_notifications

Overview of Black-Box Penetration Testing

Introduction:

A Black-box penetration testing means that an ethical hacker has no knowledge of the target network. The idea is to simulate an attack which a hacker might undertake to exploit the weaknesses in target network and breach it. Furthermore he explores the internal network and identifies further vulnerabilities within the internal network which would give him access to the critical assets of the organization.

Objective:

In this article, we would be assuming the role of the ethical hacker who has zero knowledge about the target network. The objective would be to breach the target network, own the entire domain and compromise critical assets of the target network. So let’s get started.

Limitations:

Before beginning the assessment, it was clear that we would have zero information about the target network and would only be given physical access to guest area of the target network.

Attack Narrative:

We begin the process by assessing possible network connection that were available to us. There were no hard-wired ports available for us to connect so we shifted our attention to the wireless connections.

To perform the wireless network reconnaissance we will use the aircrack-ng suite of tools available in Kali Linux Distro and the Alfa Wireless card USB adapter. We set up the environment and view the wireless connections that are available.

The wireless enumeration reveals a hidden SSID “Corporate WLAN” which is accessible from the guest area. Moreover this SSID is using the WPA2-PSK authentication mechanism which could possibly be brute-forced and this could give us access to the Corporate Network.

We went ahead and captured the handshake of the “Corporate WLAN” SSID successfully.

Than we managed to crack the handshake and got the password for the “Corporate WLAN” SSID.

Now we have access to the Internal Corporate Network of the Target; we proceed to further enumerate the network and find ways to get a foothold into this network.

In the attempt to identify potential attack surface, we examine the IP Address, Domain and Mail Servers of the target network. Since, DHCP was running we already had an IP Address. A simple “nslookup” command revealed the name-server of the target domain which was helpful for further enumeration.

We then started to perform basic network-discovery scanning and enumeration on the identified name server’s network range. (ie *.*.40.1-254) .For this we will use the netscan tool. The netscan is very helpful tool to perform network reconnaissance. It has very simple interface, checks for common open ports, supports credentialed login and give the results in very user-friendly format. 

We were able to see multiple target systems within this network-range. These systems consist of Web Servers, Databases, and Application Servers etc. Most of these systems also had the RDP Port 3389 open which would be very helpful to remote into the systems should we manage to break any of them.

At the same time it was also important to note IP Addresses of any potential high value targets which could be useful in our post-exploitation phase.

Vulnerability Assessment:

Now with so many targets in hand, it was important that we carefully analyze the weaker targets and attack them.

At this stage, we start the vulnerability assessment on these systems to evaluate potential vulnerabilities which are exploited. We perform the vulnerability assessment using well-known tools like Nessus and Open Vas. During the vulnerability assessment we also noticed that many of these systems were running outdated third party software’s and operating systems which   could become easy victims of targeted attacks. The process could be time consuming since many of the vulnerabilities that automated scanner’s give out are false positives. Hence, it is imperative that we carefully evaluate the vulnerabilities to break in the system.

The Vulnerability assessment will reveal a lot of potential vulnerabilities; one of them being the MS09-050 Vulnerability. We will go ahead and try to exploit this vulnerability.

Exploitation:

We will be using the well-known Windows exploit (MS09-050 Vulnerabilities in SMBv2 could allow remote code execution) available at https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/14674.zip link. This machine was apparently running a legacy application and hence was left unpatched in the environment.

After multiple attempts we managed to exploit the vulnerability successfully and luckily got a command shell with Local Administrator privileges.

To ensure that we have persistent access to the exploited system, we create a backdoor user and add him to the Local Administrator’s Group.

We can now login to the exploited system with our backdoor user and further enumerate this system

Post-Exploitation:

Now that we have broken into a domain system and added a backdoor user, let’s do post-exploitation on this system. Our aim will be to get the local administrator password of this system and then check if we can login to other domain systems with these credentials.

Mimikatz is well-known tool which can dump out clear-text passwords through LSASS. However the target system is running an Anti-virus which blocks Mimikatz. Moreover the Anti-virus is password protected which means we cannot disable it or whitelist mimikatz.

So we decide to use the meterpreter shell to dump out the password hashes. In order to get a meterpreter shell, we will create a malicious meterpreter payload and set up the handler on our attacking system. We now host this malicious meterpreter payload on our attacking system’s webserver and call the file via the browser of the exploited system.

Now we have the meterpreter shell on the exploited system. We can then proceed to dump out the hashes.

After dumping out the administrator hash we managed to crack this hash successfully.

Escalating our Privileges:

Now we have the Local Administrator Credentials of a Domain system. Our next step would be to see if we have access to numerous other systems with these credentials. Again we use the netscan tool to look up logged-on users with the Local Administrator Credentials.

As we can see, there are numerous other systems on the domain which are using the same username and password. This effectively means that we have succeeded in compromising multiple systems in the domain.

We then login to these systems with the Local Administrator credentials and dump out the clear-text passwords from these systems using the Mimikatz tool. The Local Administrator password was useful to unlock the Antivirus and disable it for the time-being. The Screenshot below shows the output of the Mimikatz command. In this way, we managed to collect multiple domain user credentials from these affected systems.

Escalation to Domain Administrator:

Our final step is to escalate the privileges of our backdoor user to become the Domain Administrator and own the entire the domain.

In the previous step, we had managed to dump out numerous domain user credentials from different systems. One of these credentials turned out to be the Domain Administrator. We the logged-in to the domain controller system using this credential and proceeded to add our backdoor user to the Domain and then escalate his privileges making him the Domain Administrator.

We can confirm that our backdoor user is the Domain Administrator by logging to the Active Directory and viewing his access rights.

Accessing High-Value Targets:

Now that we have become the Domain Administrator, we proceed to access high value targets of the network to expose the gravity of the attack.From the information gathering phase we identified the mail servers of the target network. MS-Exchange 2013 was used to manage the mail-servers. This means that the exchange admin center was accessible from the following link: http://webmailip/ecpWe login to the exchange admin center using the Domain Administrator credentials. We can now add ourselves as a delegate to any of the user mailboxes and get complete access to their mailbox. This means that we can access mails of all Top-Level executives of the Target Network.

Conclusion:

In this article we have looked at a complete penetration test cycle wherein we start with zero knowledge about the organization than we managed to breach the corporate network, proceeded to compromise the domain system; got the administrator hash and after cracking the hash we were able to get compromise multiple systems and finally the domain controller. In order to maintain access we also created a backdoor user and made him the Domain Administrator. Also to prove the seriousness of the attack we took complete control of the user mailboxes.