Search This Blog

Tuesday 27 September 2016

6 steps to protect yourself from the Yahoo email breach!




Last Thursday (09'22'16), Yahoo admitted to the largest email provider breach in history. The breach, which happened in 2014,  consisted of the account information of at least 500 million users and included names, email addresses, encrypted password and even security questions.   


 According to reports, as many as 2.1 million Rogers Communications customers could be affected, as Rogers uses Yahoo as their underlying email provider.


 
Even though the breach itself happened in 2014, We urge you to take the time to protect yourself from this event.  Since 2013, 360million MySpace accounts, 167 million LinkedIn accounts, And 145 million eBayaccounts have also been compromised.  




Human nature has us using the same or similar passwords across all of our various online sites, whether they be social media, retail, email, or banking.  Much as this is convenient, it opens us up to fraud and theft by these hackers. 


 


Take these six simple steps to protect yourself now:


 Change your online passwords now! 
  • Remember that length and complexity are the easiest protection.  Use at least 8 characters, and mix numbers and letters.
Use different passwords for your banking, email, and social media sites.
  • Hackers use automated tools to see if your stolen credentials work in thousands of other sites.
Enable 2-step verification.
  • Most online email, banking, and social media sites provide 2-step verification.  Ie: when you log onto a new device or from a new location, they will send you an SMS text message with a validation code before you can enter.  This protects you from having others logging in pretending to be you.
Enable transaction notification on your banking!
  • Online Banking sites have the option of sending you a text or email every time a transaction passes through your account. Turn this on!
Beware phishing attacks related to this breach.
  • Do not respond to, click on, or open emails and attachments that say they are going to help you with this breach.  A number of malicious attacks have already begun to lure innocent people into providing credentials based on the fear and uncertainty around this breach.   Your banks and email providers will NOT be sending messages related to this.
Finally, use a password management app to protect your online credentials.
  • Whether your preferred device is Windows, Mac, Linux, iOS, or Android, there are free apps out there that can help you organize and protect your online passwords.
  • Lastpass, 1password, and keepass are the most popular and cover a range of devices. 


 


References:


http://www.pcmag.com/article2/0,2817,2475964,00.asp
http://www.cnbc.com/2016/09/22/yahoo-data-breach-is-among-the-biggest-in-history.html
https://www.thestar.com/business/2016/09/23/rogers-email-users-warned-in-massive-yahoo-data-hack.html
http://www.computerworld.com/article/3077478/security/linkedin-s-disturbing-breach-notice.html
https://techcrunch.com/2016/05/31/recently-confirmed-myspace-hack-could-be-the-largest-yet/http://www.forbes.com/sites/gordonkelly/2014/05/21/ebay-suffers-massive-security-breach-all-users-must-their-change-passwords/#5d0270b13c15





Tuesday 12 July 2016

Turmoil in the CASB market - 2016 the year of Big Business Acceptance

In April of last year, I wrote a technical comparison of the various players in the CASB (Cloud Access Security Broker) space, and had such incredible response and discussion, that I felt I had to provide an update this year. Should be easy, right?  WRONG!

(Read the above article if you are new to CASB and want an understanding of the space)


The CASB market has seen a lot of turmoil over the past year, in the form of mergers and acquisitions.  Early on we all thought Cisco was going to acquire Elastica as they had become quite cozy, but in a screeching left turn, BlueCoat came from the sidelines, and snapped Elastica up. The surprise here is that earlier in June of 2015, BlueCoat had just acquired CASB player Perspecsys.  Fast forward to June of this year, when BlueCoat announced their intent to IPO, then only days later agrees to be acquired by Symantec for $4.65B.  Whew...

In a similar roller coaster,  Adallom cozies up with HP in April 2015, only to get bought by Microsoft in September.  Then just last week, Cisco, not to be left out of the CASB market announced their intent to acquire Cloudlock for $293Million.

Also in recent news, Skyhigh Networks obtained a patent to use reverse proxies for cloud access security broker services, and Netskope obtains a patent for routing client traffic securely to Cloud Services. I'm not sure how this is going to change how the others model their business.





So to recap...


Last year, in the CASB space, we had: 
Adallom, BitGlass, Ciphercloud, Cloudlock, Elastica, Imperva, Netskope, Perspecsys, and SkyHigh

This year, the landscape looks to be:
Bitglass, Symantec/BlueCoat, Cisco/CloudlockCiphercloudImperva, Microsoft/Adallom, Netskope, and SkyHigh.






I closed last year's report with the statement:
"Although the CASB market space is still in it's infancy, the main players have done a good job defining - and meeting - most of the requirements of an off-premise security service. I'm interested to see what happens to this space over the next three years.   My money is on convergence of CASB, SSO, and Mobile Security providers."
I still hold to this: Cloud SSO is what gives CASB the ability to understand context, and Mobile Security (Device Security, Application Security, Data Security)  is required to manage endpoints outside of the corporate perimeter.  Yet I'm not seeing those acquisitions as yet.


I think it's going to be an interesting challenge to to update last year's report. Stay tuned. 

NOTE: 

I am currently in the process of evaluating the technical controls published by the current players in this space and will be re-publishing this report in the near future. 

If you are a current CASB provider that I have missed here, and want to be included in the upcoming report, please comment below or email me at  unix_guru at hotmail dot com, and I will contact you for validation.



CASB References:

Gartner: The Growing Importance of Cloud Access Security Brokers
http://www.computerweekly.com/news/2240223323/Cloud-access-brokers-top-security-technology-says-Gartner
Gartner: Emerging Technology Analysis: Cloud Access Security Brokers
http://www.ciphercloud.com/2014/09/30/public-cloud-security-demands-cloud-access-security-broker-casb/
https://www.netskope.com
https://www.elastica.net/
Bitglass: The Definitive Guide to Cloud Access Security Brokers
CipherCloud looks to stay at the head of the cloud security class 
Ciphercloud: 10 Minute Guide to Cloud Encryption Gateways
Ciphercloud: Cloud Adoption & Risk Report in North America & Europe – 2014 Trends

NetworkWorld: How the cloud is changing the security game
Adallom: The Case For A Cloud Access Security Broker
Adallom: Cloud Risk Report Nov 2014
Check Point Capsule and Adallom Integration 
HP - Adallom: Proven Cloud Access Security Protection Platform 
Adallom : to Offer Comprehensive Cloud Security Solution for Businesses With HP 
PingOne - Skyhigh: PingOne & Skyhigh Cloud Security Manager
ManagedMethods: Role of Enterprise Cloud Access Security Broker
Standing at the Crossroads: Employee Use of Cloud Storage. 
Cloud Computing: Security Threats and Tools 
SC Magazine: Most cloud applications in use are not sanctioned  

http://www.businesscloudnews.com/2015/04/22/cisco-elastica-join-forces-on-cloud-security-monitoring/
https://www.elastica.net/2015/04/cisco-to-offer-elastica-shadow-it-and-casb-solution-to-enterprises/
Elastica And Cisco Move To Product Integration Of Cloud Web Security And Elastica CloudSOC
Blue Coat Acquires Perspecsys to Effectively Make Public Cloud Applications Private
Blue Coat acquires Elastica in $280 million CASB deal
Fortune: Bain Wants To Take Cybersecurity Firm Public Despite Weak IPO Market
Fortune: Blue Coat Abandons IPO Plans, Sells To Symantec for $4.65 Billion

Cloud security vendor Adallom secures $30m from HP, Rembrandt Venture Partners
Hewlett Packard Ventures and Adallom: Partnering to Protect the Enterprise Cloud
Microsoft acquires Adallom to advance identity and security in the cloud

Cisco Announces Intent to Acquire CloudLock for $293M

Stratokey: Cloud Access Security Broker (CASB)

Netskope awarded patent for cloud visibility, governance

Big Tech’s Entry into the CASB Market Is Evolutionary
Microsoft acquires Adallom to advance identity and security in the cloud

http://searchcloudsecurity.techtarget.com/news/4500253289/CASB-roundup-Microsoft-confirms-Adallom-buy-Netskope-raises-75M
https://www.skyhighnetworks.com/cloud-security-blog/what-the-adallom-acquisition-means-for-the-casb-market/

http://searchcloudsecurity.techtarget.com/answer/How-can-a-reverse-proxy-mode-improve-cloud-security

Gartner: Market Guide for Cloud Access Security Brokers
Gartner: How to Evaluate and Operate a Cloud Access Security Broker


Tuesday 21 June 2016

Threat Modeling a Mobile Application

The purpose of this article is to provide security guidance in the development of mobile applications.  The following application threat-model (ATM) is an example, created to help developers identify potential threats that a malicious attacker could use to exploit a custom developed Mobile Application.

This threat model
 example is based on Industry Best Practices and observations across the Mobile Application Development space, and is not based upon any one particular mobile application.  The scenario presented here assumes an application in the Banking and Finance space, but could be any industry.


From a Security and Privacy perspective, a mobile application must:

  • Prevent the un-authorized use of web service API associated to the related application
  • Prevent the accessibility of information or operational control of a user’s account
  • Prevent the ability for a third party to gain identification and authentication details
  • Reduce the opportunity or intention of a malicious user from accessing confidential information

Threat Profile:

A "Threat Profile" is the concept of identifying the complete set of security threats that could be used to compromise a given application or system.

The following Business Criteria and assumptions were used when assessing the threat profile for this example Mobile Application:
  • Industry Categorization                        Financial Institution 
  • Organizational Audience                       Business Users 
  • Level of Potential Threat to Audience   Moderate-threat Audience 
  • Degree of Confidential Data                  Moderate 
  • Likelihood of Exploitation                     Low to Moderate 
  • Delivery Platform                                 Mobile devices with Secured Sandboxes 
  • Level of User Interaction                      Minimal 
SANS: Threat Profiling


Threat Agents:

A threat agent categorizes the types of intentional and unintentional users associated to the system. This can include, but does not require, the intended roles of the application.




Stolen Device User: A user who obtained unauthorized access to the device aiming to get hold of the memory related sensitive information belonging to the owner of the device.
  • Access to account information to perform unauthorized transactions 
  • Access to account information to perform transactions from a different account 
  • Attempt to garner information about the banks overall security structure 
  • Denial of service attack against back-end systems based on gathered information

Owner of the Device: A user who has unwittingly installed a malicious application on their phone which gains access to the device application memory.

  • Capturing of credentials associated to the account for use by third party

Common WiFi Network User: This agent is aimed at any adversary intentionally or unintentionally sniffing the WiFi network used by a victim. This agent stumbles upon all the data transmitted by the victim device and may re-use it to launch further attacks.

  • Capturing of credentials associated to the account for use by third party 
  • Ability to perform unauthorized transactions

Key Scenarios:


The following scenarios or activities have been identified as key to the success of the application's security profile:

User Authentication - to gain access to post-sign-on functionality and content on the Mobile application.

Get Portfolio and Rates, and Execute Trades 
- User being presented with the list of transactions associated with specific Rates (Wire Payments, Cross-currency Account Transfers). The User could retrieve, view and accept the rate presented for selected payment. The User could view Beneficiary Details and the Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.


Payment Approvals - User being presented with the list of payments (Wires, Account Transfers, EFT, Bill Payments) that qualify to be approved/released by the user. The User could view payment details and approve/reject selected payment. The User must be re-authenticated as a part of each payment approval operation. The User could view Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.


Accounts Module - User being presented with the list of accounts he is entitled to. The User could add/delete/change order of Favourites Accounts in the list. The User could query and view account balances and transaction history information.


Mobile Application Architectural Elements:

The following items are associated to the application architecture specific to mobile devices. This listing mechanism is intended to provide additional input and consideration into the overall threat model.



1.Carrier Elements
  1. Data
  2. SMS
5.Device
  1. iOS
  2. Android
  3. Blackberry
2. Web Services using RESTFUL agents over SOAP 6.Common applicable hardware components
  1. Wireless Interfaces
  2. USB Ports
3. App Store
  1. Apple App Store
  2. Android Play Store
  3. Blackberry World 
7. Authentication
  1. Token Based
  2. Certificate Based
  3. Keyboard Based
  4. Touchscreen Based
  5. Biometric Based
4.Wireless Interfaces
  1. 802.11
  2. Bluetooth
  3. NFC






























Planned Application Security Mechanisms:

Planned application security mechanisms are technologies and threat-management measures that are included in part of application architecture and design. The model ignores these when defining the potential threats associated to the system but references them as solutions to identified problems.


The following application security mechanisms have been identified as part of application security design:
  • HTTPS secure transportation protocol using TLS 1.2 or above 
  • Two-phase authentication 
  • Input and data validation 
  • Exception handling 
  • Auditing and logging 
  • Minimization of operations

Trust Boundaries:




An organization and its application define a series of perimeter that define different levels of security-oriented trust. The following information defines the trust boundaries associated with systems, sub-systems, and identities.



App Container Boundary
within secure devices including iPhone and BlackBerry
Internet Trust Boundary is the connector between the device and internal banking systems
DMZ Trust Boundary including perimeter firewall where core services are located
Data Center Trust Boundary in which direct hosted systems and services are located.
Data Flows:

Data flow diagrams help document the flow of information across trust boundaries.

Understanding how data is communicated across boundaries help identify potential issues within communication protocols and mechanisms.

The following diagram represents the data flow of the application under investigation



Entry and Exit Points:

Entry Points

Entry points define the positions in your application where a user, cross-component communication or external application supply data and call operations associated to the back-end systems.
  • Mobile Application access to back-end API through JSON services.
  • Unintentional direct access to back-end API through JSON services. 

Exit Points

Exit points are relationships to entry points and define the positions in which data is sent to the client. Exit points are prioritized to identify where information is transmitted in a trusted manner but the source is untrusted.

Potential Attack Tree:

An attack tree is a hierarchal diagram (or outline) that represents the attacks a malicious individual might perform against the application. This information is based on the development of an attack profile organized around the industry and type of threats associated to your application and end users


Gain authentication information to be used in other applications, systems or services 
  • Authentication and access control attacks to determine applied security measure 
  • Determine the depth of breach and fraud preventive controls 
  • Access account to be used on other systems

Monitoring of transactions to record communication patterns

  • Obtain confidential information about the system 
  • Gain details on how transactions are processed in the system 
  • Discovery of weaknesses associated to the back-end system

General financial fraud

  • Perform unauthorized financial transactions to correct associated bank accounts 
  • Determine clients and size of transactions for social engineering attempts

Data Collection by running application in a non-trusted environment (jail-broken)

  • Ability to access the application in a jail-broken device or development platform 
  • Ability to apply memory forensics on the application at runtime to gain confidential information 
  • Ability to apply memory forensics on the application to determine run-time details

Unmanaged JSON attacks over encrypted or unencrypted channels

  • Ability to perform data theft through cross-site references 
  • Ability to perform a denial of service attack using cross-site references

Threat Tree:

A Threat Tree describes specific threats that can be applied to the application. Information in this section is defined in a threat-based tree for reference and specific descriptive afterwards. Please note that a single threat can be related to one or more common or uncommon vulnerabilities.  
  • Authentication / Authorization 
  • Input and Data Validation 
  • Relying exclusively on client-side validation 
  • Writing data you did not validate out to trusted source 
  • Using input you did not validate to generate SQL queries 
  • Configuration Management 
  • Sensitive Data 
  • Basic Man-in-the-Middle Attack 
  • Request Forgery 
  • Session Management / Cryptography 
  • Parameter Manipulation 
  • Failing to validate all input parameters. 
  • Exception Management 
  • Failing to validate all input parameters 
  • Audit and Logging 
  • Missing Security Auditing Features 
  • Unsecured Audit Logs 
  • Mobile Specific Threats 
  • Method aimed to read the local application memory 
  • Malware on the device 
  • Transactions performed from non-localized location


Rating Potential Threats:

Relying Exclusively on Client Side Validation:

Threat Description By relying on client-side validation the system allows for exposure of the back-end services through compromised client systems as well as communication protocols. This issue includes common assaults results including “Writing data you did not validate out to trusted source” and “Using input you did not validate to generate SQL queries”
Category Input and Data Validation
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Ability to perform unauthorized transactions.
  3. Denial of service attack against back-end systems
  4. Attempt to garner information about the banks overall security structure
  5. Access to account information to perform unauthorized transactions
Risk High
Attack Techniques A malicious attacker compromises the mobile application by installing it on a jail-broken device or reviews data communication though a proxy service. Unintended information (pre or post authentication) is sent through the communication protocol to the back end server containing injection data or unintentional information.
Countermeasures
  1. Use of SSL with trusted certificates to encrypt communication.
  2. Validation of data at all trust boundaries to manage tampered data.



Basic Man-In-The-Middle Attack:

Threat Description User is able to monitor the data being communicated from the mobile application to the associated server in order to determine the URL, formats and identity of back-end services for direct access to the service.
Category Sensitive Data
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Attempt to garner information about the banks overall security structure
  3. Access to account information to perform unauthorized transactions
Risk Medium
Attack Techniques Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server.
Countermeasures
  1. Use of SSL with trusted certificates to encrypt communication.
  2. Validation of data at all trust boundaries to manage tampered data.
  3. Source checking of communication using CSRF-token based concepts



Request Forgery:

Threat Description An unauthenticated user sends requests through HTTP protocols in an attempt to (1)subvert authentication mechanisms, (2) perform destructive activities against a system, (3) gain information around exception handling mechanisms, or to (4) garner information about the system and its transactions
Category Sensitive Data
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Ability to perform unauthorized transactions.
Risk Medium
Attack Techniques Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server.
Countermeasures
Use of a secure token (similar to a CSRF token) to acknowledge authorized transactions to the system and to take appropriate measures including alerts and logging when un-authorized transactions are performed. The same mechanism used in a CSRF token can be used in this circumstance.

Missing Security Audit Features:

Threat Description Attacks by an unauthorized user is not properly documented by the system reducing the opportunity for breach attempts to be discovered, hindered or prevented. From a security practice audits and logs should be applied across application layers and servers.
Category Auditing and Logging
Threat Target
  1. Denial of service attack against back-end systems
  2. Ability to perform unauthorized transactions
  3. Anti-forensic measures
Risk Low
Attack Techniques This threat does not have a direct attack; it represents an inability to detect and manage the assault in the case of a breach.
Countermeasures
  1. Log all security oriented transactions to a “security log file”
  2. Recognize unusual number of requests to any series of accounts
  3. Critical transaction attempts are logged for fraud controls

Unsecured Audit Logs:

Threat Description Once a breach has occurred, a malicious attack will attempt to alter or remove log files that demonstrate their attempts. This is a common step for an attacker in a breach to reduce the chance of success for a forensic investigation.
Category Auditing and Logging
Threat Target
  1. Denial of service attack against back-end systems
  2. Ability to perform unauthorized transactions
  3. Anti-forensic measures
Risk Low
Attack Techniques Upon a system breach the attacker will modify or delete the associated log files so evidence of their activities are removed.
Countermeasures
  1. Audit files are located in a protected directory for with access controls
  2. Modification, viewing and back-up of log files have specific user controls
  3. Use of frequent back-ups for security files to single-direction systems

Method to Read Local Application Memory:

Threat DescriptionIn this attack methodology, the data targeted is application specific memory and the method used is memory based analysis. The attacker steals sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Capturing of credentials associated to the account for use by third party
RiskMedium
Attack TechniquesThrough development or forensic tools on the device or using a developer workstation, the system and application memory is reviewed while the application is running to determine how information is stored, communicated and its residual nature.
Countermeasures
  1. General memory management techniques for the individual platform 
  2. Nullifying variables with confidential data as soon as they are used 
  3. Minimal storage of confidential data while in memory 
  4. The storage of confidential data in memory in an encrypted format

Malware on the Device:

Threat DescriptionAny program / mobile application which performs suspicious or unauthorized activity. It can be an application, which is copying real-time data from the user’s device and transmitting it to any server. This type of program executes parallel to all the processes running in the background and stays alive performing malicious activity all the time. E.g. Olympics App which stole text messages and browsing history. On a Jail-broken phone this can include access to the applications memory, buffer overflow threats
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Capturing of credentials associated to the account for use by third party
RiskLow
Attack TechniquesOften malware is installed on a device through unintentional means where the malware itself is a Trojan or worm that is embedded in a useful application. Once installed the application slowly consumes and analyzes other applications in the device. Malware is most often found on Jail-broken phones in which non-App store related applications have been installed. Malware is often not a targeted attack but attack by drawing.
Countermeasures
  1. The use of managed devices with a white-listed applications
  2. Encrypt Data at Rest on the device
  3. Encrypt Data in Transit 

Transaction Performed from Non-Localized Location:

Threat DescriptionAn unauthorized user attempts to perform a transaction from a distributed location with the goal of applying a fraudulent action. This may include a single or multiple financial transactions
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Denial of service attack against back-end systems
RiskHigh
Attack TechniquesAn individual using a stolen device or perform a transaction from a distributed location (uncharacteristic of the user) is able to perform multiple transactions
Countermeasures
  1. Use of geo-location to monitor the location of transactions for a user 
  2. The mapping of geo-location to potential fraudulent locations 
  3. The validation of transactions when listed geo-locations are not used

Threat Risk Rating:

Threats are rated into three categories (Low, Medium and High) based on their DREAD rating. The individual elements associated to this rating are as follows:
  • Damage potential: How great is the damage if the vulnerability is exploited?
  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How easy is it to launch an attack?
  • Affected users: As a rough percentage, how many users are affected?
  • Discoverability: How easy is it to find the vulnerability?

Threat
D
R
E
A
D
Total
Rating
Basic Man-in-the-Middle Attack
2
3
3
1
2
11
Medium
Request Forgery
2
3
3
1
2
11
Medium
Relying exclusively on client-side validation
3
3
3
1
3
13
High
Missing Security Audit Function
1
1
1
1
1
5
Low
Unsecured Audit Log
1
1
1
1
1
5
Low
Method aimed to read the local memory
2
1
2
1
2
8
Medium
Malware on the Device
1
1
1
1
1
5
Low
Malicious App
1
1
1
1
1
5
Low
Transactions from non-localized location
3
3
3
1
2
12
High
Threat
D
R
E
A
D
Total
Rating

References: