Open Close

How MIT website got hacked despite having any vulnerability ?

By Bikash Barai in Penetration Testing · January 23, 2013 · No comments

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

MIT got hacked.  Anonymous defaced the MIT to protest against the case of “Aaron Swartz”.

Without getting into who really hacked or the “cause” behind the protest, I just wanted to dissect it as an interesting case of multi-stage attack which proves that just securing your application is not good enough.

 

 Anatomy of the MIT Hack

Step 1: MIT Network Operations Center (NOC) person is sent an email with a malicious link containing a browser exploit.

Step 2: Victim opens the email, clicks the link and gets compromised

Step 3: Attacker steals the “Educause” credentials of the NOC person

Step 4: Attacker creates a cloudflare account with DNS entries pointing to their own servers.  Attacker also adds MX records such that mails are forwarded to their own servers.

Step 5: Attacker logs into the Educause domain control panel and changed the nameserver to point to the cloudflare account created before. Also they change the password of the domain control panel-Tweet This Blog

 

Learning from the MIT hack

  • Just securing the applications is not enough
  • You need to look into complex possibilities of social engineering vectors
  • Have a robust Emergency Response process-Tweet This Blog

 

References:
http://gizmodo.com/5978039/hackers-incoherently-deface-entire-mit-website
http://news.cnet.com/8301-1023_3-57563752-93/anonymous-hacks-mit-after-aaron-swartzs-suicide/
http://www.zdnet.com/mit-website-hacked-over-aaron-swartz-a-second-time-7000010148/

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

Must Know Business Logic Vulnerabilities In Banking Applications

By jitendra.chauhan in Penetration Testing, Web Application Security · January 23, 2013 · No comments

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

Over the last few years, our On-Demand and Hybrid Penetration Testing platform has performed security testing of applications across various verticals and domains including Banking, e-commerce, Manufacturing, Enterprise Applications, Gaming and so on. On one side, SQL Injection, XSS and CSRF vulnerabilities are still the top classes of vulnerabilities found by our automated scanning system, on the other hand however, there are a lot of business logic vulnerabilities that are often found by our security experts powered by a comprehensive knowledge base.

A business logic vulnerability is defined as security weakness or bug in the functional or design aspect of the application. Because the security weakness or bug is in the function or design, it is often missed by all existing automated web application scanners.

In this blog we are sharing the top commonly found Business Logic Vulnerabilities in the Virtual Credit Creation (VCC) module of a Banking Application.

Consider the following scenario: A Banking Application provides web based functionality to users to pay Bills Online as well as to create and manage Virtual Credit Cards. Virtual Credit cards are used to shop online. A Virtual Credit Card creation use case involves the following steps:
1. User visits banking application.
2. User opts to create virtual credit card.
3. User fills up personal details, required amount, expiry date of VCC etc.
4. User chooses a payment gateway.
5. User fills up credit / debit card details.
6. Banking Application redirects user to a Payment Gateway.
7. Required amount + Service Charge are debited from user’s Debit / Credit card.
8. Payment Gateway redirects user to a Callback URL provided by the Banking Application.
9. Banking Application verifies the Payment Gateway confirmation.
10. Banking Application generates a CVV number.
11. Banking Application presents VCC details to the user.
12. Banking application performs SMS verification of the user.

A couple of security weaknesses that are found in the above scenario are as follows:

TAMPERING OF DATA COMMUNICATION BETWEEN PAYMENT GATEWAY AND BANKING APPLICATION:
Weaknesses: The Banking application does not verify whether the required amount is successfully paid at the Payment Gateway Side, or what amount is being paid at the Payment Gateway Side. As a result, a virtual card can be recharged with higher amount while paying a lower amount to the bank by modifying amount when the request is sent from payment gateway to the bank.

Mitigation: There should be sufficient validations between the Banking application and the payment gateway. The callback URL should not be allowed to be directly controlled by an attacker-Tweet This!.

NO VALIDATION ON BANKING APPLICATION’S CALLBACK URL
Weakness: There is lack of validation on the Banking Application Side when the Payment Gateway redirects a user to the Banking Application’s callback URL. As a result, a virtual credit card can be created without paying any service charges, by sending the request directly to the callback URL of Payment Gateway.

Mitigation: There should be enough validations on the callback URL including whether the URL is redirected by the Payment Gateway or directly called by an attacker-Tweet This!.

VIRTUAL CREDIT NUMBER IS PREDICTABLE
Weakness: Generated Virtual Credit card numbers are predictable or follow certain patterns. As a result, an attacker can predict what virtual credit card numbers are being used by other legitimate users.

Mitigation: Virtual Credit Card numbers should be sufficiently random-Tweet This!.

NO ANTI-AUTOMATION IN VIRTUAL CREDIT CARD DETAILS VERIFICATION
Weakness: There is no anti-automation (e.g. CAPTCHA) while verifying the Virtual Credit Card details such as CVV number and expiry date. The Credit Card number is sufficiently long however, the CVV number is generally a 3 digit number and expiry date is also a 2 digit number. As a result, it is possible to brute force the CVV number and expiry date, and shop online using a stolen virtual credit card number.

Mitigation: There should be sufficient anti-automation e.g. CAPTCHA while verifying the CVV numbers along with the Credit Card Number-Tweet This!.

NO ANTI-AUTOMATION IN CARD CREATION PROCESS
Weakness: There is no anti-automation while creating a virtual credit card. An attacker can use automated scripts to exhaust credit card numbers. As a result, Credit Card Numbers can be exhausted and be therefore made unavailable to users leading to a Denial of Service (DoS) attack. It can also lead to other attacks including Credit Card Number pattern prediction.

Mitigation: There should be sufficient anti-automation e.g. CAPTCHA while creating virtual credit card numbers-Tweet This!.

 

 

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

Web Application Vulnerability Statistics of 2012

By Bikash Barai in Penetration Testing, Web Application Security · January 15, 2013 · No comments

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

With years of experience and valuable insights from our cloud based application security testing, we thought of conducting a study to discover the prevailing website vulnerability trends. The study is based on our original research on more than 5000 tests covering 300+ customers distributed globally.

How was the study conducted?

The study was conducted on the vulnerability data of web applications tested by us in 2012. In total more than 5000 application vulnerability from 300+ customers has been considered as part of the sample data.

Our study comprised of 25% apps from Asia, 25% apps from Europe & 40% apps from USA.

Key Findings of our Study

  • 82% of web applications have at least 1 High/Critical Vulnerability-Tweet This Stat!
  • We observed very low correlation between Security and Compliance (Correlation Coefficient: 0.2). This once again proves that compliance and security is not synonymous.
  • There are 35 security vulnerabilities on an average in a single website. Tweet This Stat!
  • 30% of the hacked organizations knew the vulnerability (for which they got hacked) beforehand
  • The Customer Apps from US & Europe had lower Vulnerability density as compared to the customer apps from APAC
  • #1 Vulnerability: Cross site scripting (61%). You can access the graph and the distribution of other vulnerabilities here.
  • #1 Secure industry vertical: Banking. The vulnerability density in the application by industry vertical is available in the full report which can be downloaded for free.

We observed the business logic vulnerabilities as the most overlooked and with the highest business impact. Most of the organizations do not have the expertise/process to discover and eliminate business logic flaws.

  • Weak Password Recovery.
  • Abusing Discount logic or coupons.
  • Denial of service using Business Logic.
  • Price manipulation
  • OTP (One time Password) bypass

Note: We observed that the average Number of vulnerability per website as 35 which is significantly lower than other industry reports. One of the reasons could be that we remove all false positives (Zero False Positive Guarantee) which other tools don’t. Another possible reason is that we report vulnerability based on Root cause analysis and do not count the number of resulting manifestations due to single vulnerability. Hence the reported number is much lower compared to other reports.

 

 

 

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

iViZ Security recognized as a “Sample Vendor” in Analyst Firm Hype Cycle for Application Security.

By Bikash Barai in Penetration Testing, Web Application Security · December 12, 2012 · No comments

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

Bangalore/ 12/12/2012 – iViZ a leading provider of Cloud based Application Penetration Testing, today announced that it has been identified as a sample vendor in the Gartner “Hype Cycle for Application Security” report in the following two categories:

  • Application Security as a Service
  • Dynamic Application Security Testing

BikashBarai, CEO, iViZ Security – “At iViZ we are committed towards providing highest quality application security testing over the cloud. We believe, Gartner naming iViZ as a sample vendor reinforces our commitment towards our vision to serve our customers better”

Gartner provides “High” as benefit rating under the “Application Security as a Service” category and cites several advantages like reduction of upfront costs as well as augmentation of limited internal resources. The report also highlights other benefits like higher accuracy and speed of adoption.

iViZ Security, is a pioneer in cloud based Application Penetration Testing service for web applications. Unlike scanners which lack in quality and consultants who are expensive, iViZ delivers consultant grade quality testing in a SaaS based, cost effective subscription model. iViZ provides a “Zero False Positives guarantee” and advanced business logic testing with 100% WASC class coverage by leveraging its patent pending “hybrid approach” that integrates automation with manual testing by security experts.

Ethical hacking or formally, “Penetration Testing” is considered mandatory by government regulations, compliances like PCI, SOX, HIPAA, ISO-27001 etc.  However, “Consultant based Penetration Testing is not just costly, but also impossible to scale since there aren’t enough human on earth to test the 600 million online websites.  At iViZ, our vision is to help organizations stay one step ahead of hackers by making penetration testing scalable and affordable through technological innovations,” says BikashBarai, CEO, iViZ.

More than 300 customers worldwide use iViZ for greater quality, scalability and cost effectiveness including several marquee names like 2 of the top 3 telecommunications companies, 2 of the top 5 IT Service Providers, and 2 of the Top 10 banks. The solution has also won numerous recognitions from US Homeland Security, University of California –Berkeley, London Business School, Intel and Red Herring. For more visit: http://www.ivizsecurity.com

Gartner “Hype Cycle for Application Security, 2012” by Joseph Feiman. (20 July, 2012)

Disclaimer:

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Advertisement:

Checklist banner

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

Beyond Secure Software Development Life Cycle (SDLC) : Moving Towards Secure Dev-Ops

By Bikash Barai in Security Awareness, Web Application Security · November 26, 2012 · 4 comments

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare

We have heard a lot about secure SDLC (Software Development Life Cycle). So, what next? Everything transforms with time and now is the time for Secure SDLC to be transformed. Secure SDLC is probably going to get metamorphosed into Secure Dev-Ops.

What is Dev-Ops?
Dev-Ops is a software development methodology which focuses on the communication, communication and integration of Developers and IT managers. In short it is an integration between Development and Operations. Historically Development and Operations worked in separate silos. Now with the advent of Agile and focus on releasing new versions in just days the collaboration/integration of development and operations has become an unavoidable truth.

Why is Secure SDLC not enough?
Let’s face the fact: Secure SDLC is not enough. That’s why the industry has adopted Dev-Ops. In order to achieve faster releases,Agile methodologies are the practice of the day. SDLC is gradually getting transformed in Dev-Ops. So it is quite obvious that the need of the day is Secure Dev-Ops and not just Secure SDLC.

What is Secure Dev-ops?
Just like the industry has adopted (or is adopting) secure SDLC, we need to do the same with Secure Dev-Ops. In Dev-Ops the communication, Collaboration and integration of Software Developers and IT Operations is the key. Hence this has created new processes to roll out faster releases.

As a part of the secure Dev-Ops program we need to ensure that entire thread of development to release follows the right kind of security practices.

How do you implement Secure Dev-ops?
Secure Dev-Ops would not demand substantially new principles in security. However, it would demand process changes and coordination, understanding between the Development and Operations folks/processes. Some of the basic elements of Secure Dev-Ops would be:

• Nimble security Testing
• Secure Coding + Secure Operations+ Secure Collaboration
• Faster communication between Development and Operations on Vulnerability Information
• Faster patching/closure of vulnerabilities
• Defining a process of collaboration between Development and Operation
• Single manager/management system for security during the release cycle

I haven’t seen much publicly available guidelines on Secure Dev-Ops. My belief is that it is yet to emerge.

Advertisement:

FacebookGoogle+LinkedInDeliciousDiggEmailRedditStumbleUponSquidooPinterestShare
1 2 3 4 5 … 10