Thursday, 11 May 2017

Assessment Methodologies Part 1: Pentesting IOS Applications


Over the next few weeks and months, we will be publishing our step by step guides for how we complete certain areas of Penetration Testing.

The guides include an overview document, usually simply called steps, which is a high-level explanation of the steps to follow and is aligned to a checklist. The checklist approach can be very useful in keeping track of specific tasks status when working in a team and divvying up the work, but it also helps you to focus as you work through an assessment in a methodological approach.

This approach is usually aligned to an industry-standard methodology, such as the OWASP Application or Mobile Application testing guide. Although they have been tailored in order to accommodate certain types of assessment, such as red-teaming, black box, grey box or white box testing etc.

Also, to align to a typical expectation of effort needed to complete an assessment, in order to provide consistency when scoping work and submitting costings for proposals.

Each methodology or assessment walkthrough also comes complete with a set of technical notes, which includes the actual syntax to use when performing certain tasks, such as command line, bash scripts, calling python scripts etc.

The entire folder structure is located via an online share, which will allow for the documents to be updated by us.

With regard to information sources included within the documents, they are essentially a mixture of content copied from the internet, other blog pages, tool setup and manual files and some of our own wording.

Due to this, we are not claiming to own or have copy write over any of the documents, as they are simply a structured collection of information that is usually either freely available on the internet or has been documented in some other format.

We also don't believe in the idea of keeping knowledge of the type of work we do to ourselves, some people in the Profession do still try to do this, which can be extremely frustrating and unhelpful for people entering the industry hoping to pick up skills in order to enhance their own skill set.

Therefore, these document can be freely copied, adapted and used by anyone who thinks they may be of use, without any cost. The idea that by sharing knowledge and information in this way, others can benefit from the know-how in order to apply this when advising clients on how to secure their environment.

Part 1: Pentesting IOS Applications

The first post in this series is a look at how to perform an IOS application assessment on an Apple Iphone, Ipad, Ipod device.

The theory behind the methodology we adopt is that you are looking for design and implementation weaknesses in the application in accordance with industry standard guidelines (OWASP Mobile Application Guidelines)

The security of the device itself is not included in this assessment, as this is a different area of testing (Mobile Device Testing) although, there is an assumption that the application and any data contained may be compromised if a device is stolen or accessed by an attacker.

Therefore, there is a strong emphasis on encryption and authentication, through an application users perspective. To complete an IOS application assessment, you really do need a jailbroken IOS device, there is no getting around it at present and there are no emulators that are up to the Job.

I would suggest a 64-bit iPhone 5s running at least IOS 10.2 - otherwise, you aren't going to be able to assess applications that make use of the more up to date hardware or IOS version.

With regard to prerequisites, you will also need a MAC operating system in order to run the binary analysis and decompilation / code tampering elements.

Do you need to be able to code in C or swift, it would be of huge benefit of course, but altering the code and repackaging the application is a very advanced area, although it's pretty straightforward to remove functionality or amend something, a termed called patching. This can sometimes allow you to bypass a jailbreak detection function or alter SSL cert pinning, all of this is relatively straight forward to do without really knowing much about the code.

The mitigation of this is to obfuscate the code so it can't be decompiled and understood. Realistically, if you have access to decompiled source code and you can recode it, essentially you can do anything you want with it.

The mitigation will be the same, no matter what you can do with the code, it will be to obfuscate it. You can see if the code is ciphered or not without knowing how to write code so you can make the recommendation without knowing how to code just the same as someone who has managed to recompile it.

You will still need to know how to analyse a binary and search through this using strings (looking for hardcoded credentials etc) and how to dump class headers, which may allow you to perform run-time analysis and method hooking to access data in memory or bypass certain features.

This is how certain tools work on a jailbroken device in order to perform jailbreak detection cloaking or cert pinning bypass, such as ssl kill, they hook common classes used by application developers, at runtime.

There is also a need to complete other elements of testing when completing a mobile application assessment if the mobile device interacts with a web service, which most will do.

Therefore elements of a light touch approach to testing the web-based API endpoint - usually via proxying your device through Burp Suite Pro. This is very similar to web application testing, albiet via JSON.

Also, the endpoint application server would need to be included from an infrastructure perspective, which is aligned to the configuration management phase of the OWASP web application testing guide.

These additional elements are usually included in order to provide adequate security assurance of both the mobile application on an end user's device and it's supporting web service and it's supporting infrastructure.

Overview / Checklist / Technical Notes

Saturday, 29 October 2016

Client-Side Technology Assessments

In our previous blog post’s, we have looked at modern attack vectors that are being employed by multiple types of threat actors. 

Phishing, Vishing and smishing attacks are becoming far more common that tradition network attacks aimed toward remote listening service ports, such as buffer overflows or default passwords. It is also true that attacks against web applications and API’s are also becoming less frequent. 

Why is this?
Well it’s quite simple, cybercrime has now become a highly lucrative money stream for organised crime syndicates and Professional hackers. The Professional hacker, who has learned multiple coding languages and is highly skilled in developing code and malware, is now being employed by these organised crime syndicates for the purpose of making the attacks more accessible. 

This can be achieved through the provision of multiple online services or marketplaces, similar to Amazon but usually only available through the dark networks (ToR). 

These market places are used to sell the usual black market goods, such as illegal drugs, weapons, pornography etc, but they also provide access to a new breed of narcotic – Malware as a Service (MaAS).  

The malware that has been developed by a skilled attacker can then be bought or rented via these online market places, by relatively unskilled and untechnical criminals and delivered via a Phishing, Vishing or smishing campaign. 

There could be many reasons why a criminal gang or organised crime syndicate would want to target and organisation with malware, although financial gain, extortion, blackmail, data or asset theft would be the main drivers. 

So how does tradition security testing help with this type of threat?.
Traditional penetration testing, whereby a client would provide a defined scope of systems to test through a more rigid, structured and controlled manner, usually mandated for compliance purposes, is by and large only as effective as the scope being provided. This includes PCI ASV scans. 

We are not talking about web application security assessments, Server build reviews, firewall rule base reviews etc here though, as this is considered more auditing and is still very important for risk management and security in depth system hardening.
We are discussing the more tradition penetration testing in the form of an unauthenticated network security assessment, through a defined scope or a provided set of IP addresses. 

Red team assessment’s and STAR type testing do provide a better insight into the low hanging fruit (LHF) and the immediate areas of weakness that need to be addressed.

This is why the Bank of England, which governs the UK’s financial and banking industry, had moved away from the traditional CESG or now NCSC CHECK type of assessment and developed the CBEST program in 2014. CBEST is essentially a STAR assessment, which is essentially a Red Team assessment but slightly more advanced and targeted. 

With STAR assessments, the idea is to gather information regarding the client as an entity, usually through a provider of threat intelligence and then target that entity using the intelligence gathered.
This intelligence could consist of an abundance of information, but most importantly for social engineering and Phishing attacks, it would include details of users that may be accessible or prone to be susceptible to social engineering attacks or a weakness in a specific system or control that could be exploited and therefore the most likely target for attack. 

So this is where the Phishing (we will include Vishing and Smishing under a generic term Phishing) attack vectors using malware as the payload come into focus. This malware would usually be customised to exploit the vulnerabilities exposed and discovered through the completion of threat intelligence.

A good security testing consultancy would be able to perform a Phishing assessment to effectively gauge user awareness toward multiple Phishing attack vectors, including the downloading or opening running of a potentially malicious file.

However, as discussed in the previous blog post’s, the Phishing assessment is really aimed toward user awareness testing and is unlikely to provide the full level of insight into the threats exposed by an end user running potent, malicious files and attachments. 

This is where an assessment of the Client-Side technology, through running a malware simulation test, provides a much more effective insight into any areas of weakness in the Client-Side technology that could expose low hanging fruit (LHF)  

So what is Client-Side Technology?
Client-Side technology is the security eco system of tools and settings applied on each client and within the environment to protect against an attack, either through malware or by an attacker performing the same steps manually. Or in fact these could be steps that are unintentionally being performed inadvertently by a trusted user. 

This Client-Side Technology or tools can include but are not limited to
  1. Anti-Virus, Anti-malware and Anti-spam
  2. IDS / IPS
  3. Host and Network based firewalls
  4. Web Content Filters
  5. Browser Security Settings
  6. Network Share Permissions
  7. Group Policy Settings
  8. User Lockdown Controls
  9. Security Incident and Event Monitoring Systems
Traditional security testing can encompass all of these technologies individually through various rigorous auditing type of assessments, including client security evaluations, server build reviews, firewall security assessments, active directory reviews etc. 

However, this level of assurance takes time and costs a lot of money, especially if an organisation requires to remain compliant or handles any Government data at official or above.

So this is where an automated low hanging fruit type of scan (Client-Side Technology Assessment) would benefit, as it would capture the most likely and obvious vulnerabilities that are going to be exposed and exploited through malware. 

It would be by no means a replacement for the traditional auditing methodologies, but if run on a regular basis as part of an ongoing risk management process, or as part of a change control procedure, this type of assessment would most certainly assist. 

The main questions answered by a Client-Side Technology assessment would include, but would not be limited to.
·                     Does your AV detect known Malware downloads?
·                     Is your SIEM able to trigger activities from this tool?
·                     Is Malware able to modify System Settings?
·                     Is Malware able to communicate to External servers?
·                     Can Malware access sensitive data on the local host or share drives?
·                     Browser and Browser Plugin Security?
·                     Is your system and data vulnerable to a “Ransomware” attack? 

The malware simulation tool could be delivered and run through a Phishing assessment as a rogue attachment or available through a rouge URL, although it would be more beneficial to only include a benign tracking file within a Phishing assessment, as this type of assessment is really only for user awareness testing.
It would be better to run a Client-Side Technology assessment independently across multiple client user builds under the guise of an authenticated and trusted user, as an audit or possibly as part of a Red team assessment, whereby the vulnerabilities highlighted by the tool, could then be exploited to allow a Consultant to gain further access or to escalate privilege. 


Essentially, the types of Penetration testing being offered by security consultancies is moving away from the traditional network security assessments and into a more pragmatic approach in order to keep up with the changing threat landscape.

Well the progressive Consultancies are anyway. If you are still seeing pages and pages of Nessus vulnerability type issues in your very expensive Penetration testing reports, you need to change your provider.  

The threat actors are growing in numbers, but they are not all the code savvy hackers of days gone by. Traditional criminals are looking for an easy quick form of revenue and are looking to utilise online services to exploit basic weaknesses with organisations through automated, remote tools and malware. 

Professional hackers who can code are being utilised to create a simplified attack platform for the lesser skilled criminal masses who use the basic techniques to attack the low hanging fruit within any unsuspecting organisation. 

Saturday, 22 October 2016

Phishing Assessments Part 2.

In the previous blog post, Phishing assessments Part 1, we looked at what an attacker is hoping to achieve through a phishing assessment, the types of attacks that can be performed, how an attacker goes about performing them and what the end result would be. We also looked at how a security testing consultancy can replicate this type of attack through an email based phishing assessment in order to gauge user awareness. 

In this blog post, we are going to look at what happens if an attacker’s emails are being effectively blocked by ant-spam filtering, or access to a malicious data capture of file download website is being blocked by web content filters. 

An attacker will soon be made aware that his emails are being filtered through tracking the emails and monitoring the responses, a 50* error will be returned if anti-spam filtering is in force.
If the emails are being received but no activity is taking place on the cloned website, then it is likely that an effective web content filter system in protecting end users from accessing the cloned website.
So what does an attacker do form here?

During the initial reconnaissance phase, the attacker would have scraped multiple open source repositories in order to gather the names and emails addressed of potential targets. The telephone direct dial numbers may also have been disclosed, if they haven’t, the front desk or main public contact number would have to be made available. 

Then it becomes a telephone campaign, titled “Vishing”, or if mobile numbers have been enumerated, the term can be called “Smishing” (whereby a malicious SMS is sent, with the same URL that would have been used in the email campaign, aimed toward the mobile device browser or a mobile exploit included)

In this blog post, we are going to concentrate on the various methods adopted by an attacker when completing a telephone or vishing campaign. 

The attacker could use one of multiple scenario’s for the telephone call’s, depending on certain environmental conditions, IE whether his emails are being blocked, whether he is attempting to harvest user credentials with single or multi-factor authentication, whether the end users have access to a cloned malicious website or not, whether he is looking to install some form of malware, usually ransomware, the list is endless. 

For each of the environmental scenarios, an attacker would need at least the following information to be able to perform an effective campaign. 

  1. A list of end user targets and telephone number (direct line or mainline transferable)
Optionally, an attacker would perform OSINT and harvest as much information as possible on the environment, it’s users, support staff, executive level users, technologies in place, third party suppliers etc. 

The following information would also allow an attacker to provide a more enhanced attack.
  1. A list of IT staff names, location and numbers
  2. A helpdesk or Support number
  3. Names of Executive level users and numbers
  4. Two Factor authentication methods used
  5. Third Party Supplier information (Cable provider, website hosting company etc)
So armed with a good level of information, the attacker can progress to calling up the various entities and attempting to coach the users into either providing information over the telephone, entering the information into his cloned data harvesting website or downloading and installing the malware.
We have developed a set of typical scripts that can be used during a telephoned based vishing assessment, that are similar to attacks adopted by attackers. You will probably recognise these tactics from calls you have taken in the past. 

It should be noted that these scenario’s and scripts have been developed by us for performing user awareness testing on behalf of our clients, with full authority from our clients to perform the assessment.
Scenario 1.   Two Factor Authentication – VPN Gateway
This scenario works better alongside a targeted email Spear Phishing campaign, requesting users to log into a spoofed VPN gateway using their corporate credentials (call 1.1). Although it can also be completed independently (call 1.2).  

The Environment.
The client hosts a corporate VPN gateway that uses two factor authentication (Username / Password + Secure ID). A spoofed versions of the Gateway has been cloned and a Phishing email has been sent to the end users, users may or may not have disclosed credentials. 

·         A target list of standard users (Names and phone numbers)
·         A list of IT staff (Names and phone numbers)
·         A cloned corporate VPN landing page.

1.1   User credentials have been harvested.
A standard user’s (user) username and password have been captured through the cloned VPN website, although they could not log on (as it required the two factor ID plus it was spoofed of course). The scene is a call back from the known IT staff member (Staff), stating they have been alerted to a failed logon attempt and they the secure ID token needs to be reset. 

“Hi (user), this is (Staff) from the IT department. We have been alerted that you attempted to logon to the new VPN service but couldn’t. We have investigated the issue and found that your secure ID token needed to be reset.
Do you have this token with you (if so ask if it can be done now – if not, arrange a call back)
OK, so the first thing we need is the current secure ID token code, and then we need the next code (this is actually how you rest the tokens) 

The idea is that you then log in, in real time to the real VPN, although as a proof of concept, just getting the user to give you the token would suffice. 

1.2   User credentials have not been harvested.
This is when you need to capture the user’s password from IT (via a password reset request) and the user’s secure ID token in real time from the user. 

Call 1 – User to Staff
“Hi, this is (User) from (Department) again…, I have called a few times about this last week and I am started to get a bit frustrated. You should be able to see from my call logs (these won’t be present but doesn’t matter) that my user account is being locked and I keep needing to reset my password. I am out of the office today and I can’t log into the VPN, although I have my secure ID with me.
Could you please reset my password for me so that I can log onto the VPN, I will then rest it. 

Call 2. Staff to User 
“Hi (user), this is (Staff) from the IT department. We have setup a new VPN service this week and have had some users reporting that they cannot log in using their credentials and secure ID. Therefore, we need to reset some users secure ID tokens so users can log in.
We have investigated the issues and have a list of problem tokens and found that your secure ID token needs to be reset.
Do you have this token with you (if so ask if it can be done now – if not, arrange a call back)
OK, so the first thing we need is the current secure ID token code, and then we need the next code (this is actually how you rest the tokens) 

If successful, you should have both the username and password for the user (or maybe just password) and a current secure ID token.

Scenario 2.   Webmail Credentials
This scenario works when there is no two factor authentication, just a simply corporate username and password needed to access a site, such as a corporate webmail system.  A cloned version of the website can also be adopted, although it is not essential. 

The Environment.
The client hosts a corporate webmail portal that uses single factor authentication (Username / Password). The idea here is for an attacker to spoof the user into disclosing credentials so that the attacker can access the corporate webmail system as the user.
This can be completed by sending a user the standard email, with a link to a cloned version of the webmail site, or by coaching the user to access the site and enter credentials over the phone. 

·         An Executive User (Spoof this users)
·         A list of standard users (Names and Phone Numbers)
·         A list of IT staff (Names and phone numbers, ideally a manager’s name also) 

2.1 Harvesting User Credentials – Executive User

This is when you need to capture the user’s password from IT (via a password reset request). 

Call 1 – Executive User to IT Staff
“Hi, this is (Executive), I have been speaking to (IT Managers name) regarding problems with my account, the password seems to keep locking. I am at an important conference and only have access to my laptop and need to access an email but cannot log onto the webmail system.
(IT Managers name) has said for me to call you guys to help by resetting my password for me, can you do this and let me know what it is, it’s really important that I get this email sent to a client as soon as possible.
Sorry but I don’t have much time as the conference is just about to start, can you please help me?

Call 2 – Standard User to IT Staff.
“Hi, this is (User) from (Department) again…, I have called a few times about this last week and I am started to get a bit frustrated. You should be able to see from my call logs (these won’t be present but doesn’t matter) that my user account is being locked. I am out of the office on annual leave today and I can’t log into the Webmail, although I have an important email sent from my manager that I need to reply to, I can’t believe I am being asked to work on my day off.
Could you please reset my password for me so that I can log on and reply to this email, it’s really important. 

2.2   Coaching user to enter Credentials (Spoofed site)

Only use this when the email campaign has failed to coax a user to enter their credentials (could be due to mails being blocked, web content filtering etc) or no email addresses are provided and it’s a Telephone only campaign. 

Call 1 – IT Staff to User.
“Hi (user), this is (Staff) from the IT department at (Client name).
We have recently setup a new Corporate web mail service this week and have had some users reporting that they cannot log in using their Corporate credentials.
We have investigated the issue and believe we have now fixed the problem, would it be possible for you to logon and confirm if you can see your emails?
If yes,
Please logon to (URL of Cloned site) with your corporate email address and usual password and you should see your emails? 

It won’t work and they will see an error stating unavailable, but the credentials will be logged.
OK no problem, we will continue to investigate the problem, we are very sorry, have a great day.

Scenario 3.   Change Password
This scenario works for capturing usernames and passwords through a spoofed corporate change password landing page has been setup. This would usually be run via an email campaign, although the email may have been blocked or could be a telephone only campaign. The spoofed site will be a clone of the corporate site and would be more effective that asking the user to provide you with their details directly over the phone.  

The Environment.
This is aimed at a client user who may be based remotely or not have the ability to rotate their passwords in the usual way. 

·         A list of standard users (Names and Phone Numbers)
·         A list of IT staff (Names and Location)
·         A data capture landing page (corporate clone) rotate password version

2.1 Harvesting User Credentials – standard user

Call 1 – IT Staff to User.  (Option1)
“Good morning / afternoon (user), this is (Staff) from the IT department at (Client name). As part of (Client name) commitment to your IT security and protection of sensitive information, (Client name) requires you to regularly change your password.
Our systems indicate that you have not changed your password recently, therefore, we would be grateful if you could update your credentials on the following page as soon as possible. 

Provide URL for landing page

Thank you for your assistance, have a great day.

Call 2 – IT Staff to User. (Option 2)
“Good morning / afternoon (user), this is (Staff) from the IT Security department at (Client name). We have had an alert raised regarding potential data breach on our systems, which may have disclosed your current account details.
We are currently still investigating whether we have a security issue, however, in the mean-time and in order to prevent any further problems
We would be grateful if you could update your credentials and change your password on the following page as soon as possible. 

Provide URL for landing page

Thank you for your assistance, we will update you once we have completed our investigation, have a great day.

Scenario 4. System Unstable
This scenario works when there is no cloned site, but there may be issues on the network with system stability – there probably isn’t, but a user wouldn’t know either way.  The idea is to gather some of the user’s password (for further brute force of a weak password) and their username. It kind of works as the user isn’t divulging their entire password, which is common when talking to a bank etc. 

The Environment.
The idea here is for an attacker to spoof the user into disclosing credentials so that the attacker can access a corporate system as the user. 

·         A list of standard users (Names and Phone Numbers)
·         A list of IT staff (Names and Location) 

4.1 Harvesting User Credentials.
Good Morning / Afternoon (User) my name is (IT Staff name) and I am calling from (Client name) Internal IT based in (Location). We have had a number of stability issues today with the operation of the IT network and are concerned that some of the staff, including yourself, may have lost some data.
We are obviously concerned so want to verify that your account data has not been corrupted, for security reasons, could you confirm your username and confirm the first four characters of your password?

Scenario 5.   Important Security Update
This scenario is based on a benign malicious file download and run. This is typical of the ransomware attacks that are common. The downloaded file can also be sent as an email attachment, or via a link included in the email to a website with the file available to download.
In this instance, either the email was blocked (most likely) or you do not have the users email address, or they failed to open / download the file included in the email. Or it could simply be a telephone only campaign. 

The Environment.
The client runs a corporate network that would usually be made up of a mixture of Windows systems and Linux. Windows systems are constantly being updated, it is not uncommon for a Windows system to need an important security update.  Clients must have internet access, the file type will be a benign trackable file, which should bypass client based AV. 

·         A list of standard users (Names and Phone Numbers)
·         A list of IT staff (Names and Location)
·         A File Type Scenario based landing page (AV friendly)
5.1 Malicious file download and run 

Call 1 – IT Staff to User
Good Morning / Afternoon (User) my name is (IT Staff name) and I am calling from (Client name) Internal IT based in (Location).
We have had a number of reports that certain systems have not received the really important security update from Microsoft, which was released last week.
Could you please confirm your system hostname so that I can check whether it has been updated?

Talk the user through right clicking my computer, to provide you with the name of the workstation, laptop etc.

OK, it looks as though this system hasn’t had the updated, we will need to do this right away. Could you please open your browser and enter the following into the address bar (URL of landing page)? 

Talk the user through downloading and running the file, the file will make a call back to the Phishing command and control server. 

Once the file has made the call back. 

Ok that seems to have been updated now, thank you for your assistance, have a great day. 


So how do you protect yourself against a vishing attack? 

There isn’t a great deal that you can do with regard to technical mitigation techniques, you cannot really implement any form of inbound call filtering to all staff, as with anti-spam for inbound email.
You could block calls originating from known rogue telephone numbers or withheld number sure, but then there is always a risk of blocking legitimate sales or support enquiries and an Attacker would always find a way to get around any block. 

Web content filtering would certainly prevent the users being tricked into accessing a malicious website, if set up correctly. However, an attacker could create a very legitimate website that would pass all web content filtering checks and then subtly change a minor piece of code specifically for the attack. 

At the end of the day, as with all forms of social engineering, it comes down to user awareness training, humans are always going to be the most commonly targeted entity by attackers.
Including both phishing, vishing and smishing assessments (be mail based and telephone / mobile) into your security testing programme is essentials. The security consultancy performing the assessments needs to remain up to date with modern social engineering attack techniques also, including where a client is using the latest client-side security technology, how to bypass them using custom malware. 

In the next blog post we are going to look in more depth at the client-side technology, aimed at preventing the exploitation of a phishing attack payload and how custom malware or poor configurations can be exploited by a skilled threat actor.