Security Testing | Security 4 No0bs - Saying 'Yay' to BYOA

How could BYOA (bring your own application) play a part in security?

Source - Ministry of Testing - 30 Days of Security Testing Challenge (2017)

Dear reader, I'd like to take a few minutes to present my take on this whole idea of personal apps on personal devices whiles on company time. Seems like the issue of BYOA is ever-increasing as more and more business adopt cloud-based solutions for things like data storage, design, collaboration, and the like. Using the metaphor of a box as security, every user with a personal device using their own apps is poking holes in the box. It's not hyperbole to regard each app (non-Company Approved)as a potential attack proxy.

With that said, the following is a list of things off the top of my head that I see as issues resulting from BYOA. Its a simple list and I'm sure more can be added as IoT evolves:

What is BYOA?

As it is defined in most places, BYOA (Bring your own application) is the practice of using third-party applications. This can be anything cloud-based, external-facing, or otherwise remotely accessible.

The problem inherent in this practice stems from individuals, with personal devices, introducing apps that can utilize the same resources as other applications in the system, in essence making them "friendly".

What harm can it do?

1. Cloud-storage Apps

Locally, users may be able to store and retrieve data from a centralized system. Monitors are put in place to track the flow of data, and roles-based access determines who gets what.

The challenge is how to control this stream of data in the cloud.
Authentication credentials may provide some form of control, but the likelihood of a data breach, social engineering attack, or other means of accessing the server is high.

2. Collaboration Apps

On the surface, collaboration apps appear harmless, but if an application not approved by Network Administrators is used, there is the potential for exposure to attacks not limited to trojan horses or packet sniffing.
Network Admins may have a tough task of regulating what is / is not admissable on the network.

3. Social Network Apps

Another potential attack vector, social network apps present the opportunity of introducing malware into the system by way of interacting with the wifi, blue-tooth connection, and distinct device settings.
All one has to do to introduce such an attack is simply click on a link, post, or image and **BOOM** an attack has begun.

What should I do?

Granted there are more scenarios that illustrate the point I'm trying to make about BYOA, but the solutions to ensuring the chance that a security incident never occurs is to be mindful of the apps in use.

While at work, be to use apps approved for work use only, and be cognizant that any communication using company resources will be monitored. Any suspicious activity will be flagged.

What should I NOT do?

The answer to this is simple:

1. Don't use "your" apps for work

As an employee (end-user), one should strive to avoid using any unapproved applications.

2. Don't use "your" social apps during work hours

Avoid sharing anything, clicking anything, streaming anything, or downloading anything not work related.

3. Don't store anything in the cloud

Storing copies of any company information remotely. This may be construed as a security policy violation with dire consequences.

Conclusion

As a user ...

Keep a close eye on the apps that you ARE using, especially ones approved for work, and keep any non-work related activity for when you are off the clock.

As innocuous as it may be, the idea of BYOA is novel but perilous. The transmission of information - Inbound / Outbound - is a security risk no organization can afford.

Security Testing | Security 4 No0bs - Web vs Mobile Security Testing

Web vs Mobile Security Testing: A No0b's Observation

Dearest Reader, As I am moving along in my journey towards learning more about information security and testing, I've come to understand how the pieces fit.

While my testing experience began with mobile, a lot of the testing principles carried themselves to the web. Browser nuances aside, I've noticed distinct similarities in how applications work, and some obvious differences.

The same can be said with regards to security testing.

How Web & Mobile are the similar

Some of the similarities I've encountered with regards to Mobile versus Web Application Security Testing include:

1. Browser behavior
So the first thing I've come to realize is just how similar web and mobile behave. As it relates to presentation, the UI interactions are identical. A mobile-friendly site can elicit the same response as a native app. This presents the ideal playground for hackers to take action. A user can view a site or install an app from a "trusted" source and unknowingly introduce trojan horses in their system. Its been reported just how rampant the spread of malware is from trusted app stores.
2. SQL / JS Attacks
In my testing experience, I've come across both web and app forms that fail to follow certain design patterns. The first of these patterns being max field length constraints. All-too-easy to enter verbose text and cause a crash or other negative behavior.
Another common situation involves the lack of proper input restrictions. While easier to mitigate on web, more often than not the likelihood of injecting malicious code into a form is evident when the controls to prevent special characters from being entered are not found.
Imagine being able to trigger a "DROP TABLE" command from a form that isn't preventing the system keyboard from entering special characters where none are expected. Not good!
3. Data Manipulation - MITM
While this required a little more effort, the means by which submitted data could be manipulated occurred the same way both on web and mobile devices. Some time ago, I was tasked with testing an app that required user input in order to trigger an SMS operation.
With the help of a proxy tool, I was able to manipulate the payload and transmit gibberish where a legible message was expected. I've successfully done this on web sites as well.
4. Session Hijacking Attacks
Because web and mobile apps rely on cookies for state-transitions and navigation, the means by which sessions can be hijacked are identical. With the help of proxy tools, session tokens can be intercepted and manipulated, wreaking all kinds of havoc.

How Web & Mobile are completely different

In my opinion, not a lot separates web from mobile aside from the obvious differences in resource and hardware. There may be more to this list than I can possibly mention, but I shall endeavor to keep it short and sweet.

1. Native SDKs
So the first thing to mention is the SDKs. In this category, iOS (Apple) has the clear advantage with regards to how it manages its application universe. With the way they handle release management and policies regarding application submission, Apple ensures its operating system remains tamper-proof. But recent exploits have shown nothing is unbreakable.
Security testing apps involves using a lot of proprietary tools and the biggest challenge is overcoming the iOS restrictions.

Android, written in JAVA, presents an implicitly easier way of testing apps from a security stand-point. The biggest challenge however, is the device ecosystem. While testing may prove stout in many of the devices, lower-tiered devices using a legacy-version of the Android OS may prove likely targets as their code-base might be not patched.

2. Tools To Use
In my experience, working with native apps and web sites, the tooling for security testing is diverse. That being said, the one tool I found working the best way was BurpSuite.
Where the differences lie are in how you proxy the device to interact with the framework. On a website, one just sets the IP address to be detected by the proxy tool and VOILA! you are being detected.
With mobile devices, one has to create a Certificate with the proxy credentials. Then the certificate must be installed onto the device. Lastly, the device wifi and proxy suite must reside on the same network.
Another key difference was applying OWASP Top-10 test cases. The test cases for web did not translate 100% to mobile, and vice-versa (ie., there were subtle nuances to account for).
3. Attack Vectors
As stated before, while the device ecosystem is stout for iOS, this is the complete opposite for Android.
There are a plethora of devices, OS versions, and other fractious iterations in the wild, not to mention rooted devices, that testing and securing platforms proves an enormous endeavor.

Conclusion

This list is in its infancy and may evolve over time, but for now .. this is what I got!

• OWASP_Testing_Project
• source.android.com/security/
• iOS_Security_Guide.pdf