General security

Phishy Basic Authentication prompts

Daniel Tomescu3 Comments

confused-idea-lightbulbIn one of our previous posts, we noted that a popular tool – Responder – uses Basic Authentication prompts to harvest user credentials when they accidentally enter invalid domains in web browsers.

Responder’s approach is pretty good and it does some “magic” to catch and respond to DNS requests for in-existing domais,  however I think that there is way more potential in using Basic Authentication for phishing purposes.

What I like (or dislike) most about basic authentication is that it is NEVER clear who is asking for your credentials and where they will end up. This type of confusion often tricks users into falling for simple phishing tricks, allowing attackers to easily gather user credentials.

Continue reading →

Practical JSONP Injection

Petre Popescu18 Comments

JSONP injection is a lesser known but quite widespread and dangerous vulnerability and it surfaced in the last years due to the high rate of adoption of JSON, web APIs and the urging need for cross-domain communications.

What is JSONP?

Assuming everybody knows what JSON is, let’s talk a little about JSONP. JSONP comes from JSON with Padding and it was created in order to bypass common restrictions such as Same-origin Policy which is enforced for XMLHttpRequest (AJAX requests).

Let’s take an example. Our online banking application, http://verysecurebank.ro, has implemented an API call that returns the current user’s transactions.

An HTTP request to the http://verysecurebank.ro/getAccountTransactions endpoint presents us with the transactions, JSON formatted:

json-transactions

If our reports application, accessible at http://reports.verysecurebank.ro wants to get the transaction details, an AJAX call to the page won’t be possible, due to Same-origin Policy being in effect (different host).

sop-json

To get around this problem, JSONP came into play. Since Cross-domain script inclusion (mostly used to externally load JavaScript libraries such as jQuery, AngularJS etc.) is allowed, but not recommended, a smart trick apparently solved the entire equation: prepending the response with a callback.

Note: even if it might be obvious, it’s worth mentioning that when including a script cross-domain, it will run in the context of the including application, not in the source’s context.

Adding a callback to the API response, wrapped around the JSON formatted data, allows us to load the API response between script tags and get its content by defining our own callback function to handle it.

Continue reading →

Penetration Testing in IT/ Security Assurance Projects

Mihai Gabriel TanaseLeave a comment

There are various cases when during an IT/ security assurance projects there are specific requirements to rely on penetration testing projects/ reports completed by a third party.

However, not always, the IT security auditors have the necessary information to assess the quality of the penetration testing projects (focusing on planning, projects delivery and reporting).

And I address here the IT security assurance projects having in scope IT systems and finalizing with an Independent Auditor Report (IT Audit Opinion) and not audits focused on processes (like ISO audits) or on specific IT controls relevant for specific objectives (like ISAE 3402 IT/ Security assurance projects).

IT/ Security auditing standards

In order to have a consistent and objective assessment of third party reports, an IT security auditor must refer to the auditing standards he is using for performing his engagement.

And if we consider the IT audit standards available on the it-audit-activitymarket, we must look at ISACA framework. There are also other standards applicable to various industries or specific objectives, focused on management systems, like ISO standards, but ISACA’s are the only ones of general nature which can be used cross-platforms, industries, etc. And as support for this, I performed some quick Internet searches and found mostly the same views.

For example, in one of its papers, NIST recognizes the entities enumerated below as addressing the IT auditing within their standards, further states that all of them taken essentially the same position concerning audits involving information systems and continues focusing on ISACA’s CobIT.

  • The American Institute of Certified Public Accountants (AICPA) in several Statements on Auditing Standards (SASs);
  • Institute of Internal Auditors Association (IIA) in its Standards for the Professional Practice of Internal Auditing;
  • Information Systems Audit and Control Association (ISACA) in its “ITAF™: A Professional Practices Framework for IS Audit/Assurance”
  • S. General Accounting Office (GAO) in its Government Auditing Standards and Title 2, Accounting.

Continue reading →

Penetration Testing or Vulnerability Assessment – Which one should I choose?

Adrian FurtunaLeave a comment

penetration testing or vulnerability assessmentIn this post we will take a quick look at the differences between vulnerability assessment (VA) and penetration testing (PT). Furthermore, we’ll give a set of questions that should help you decide which service is the best choice for your particular case.

So let’s say you want to improve the security of your internal network infrastructure and you have to choose between VA and PT – offered by your favorite consultancy firm. First of all, let’s see what they are.

Vulnerability Assessment – is the process of identifying and prioritizing technical vulnerabilities which affect a target system or network. It is mainly done automatically using a vulnerability scanner and it’s usually aimed at a wide area of machines. The purpose of a VA is to find as many vulnerabilities as possible in the given time frame. Optionally, manual validation may be included for the critical findings but this is not usually done when a high number of vulnerabilities are involved.

Penetration Testing – is a goal-based simulation of a real attack. The pentesters will search for a chain of vulnerabilities in the target system/network and exploit them to reach their target (e.g. gain access to a client database, obtain sensitive information, gain Domain Admin, etc). The pentest report will contain only the vulnerabilities encountered during the attack against the target and no additional checks are being made. However, the reported vulnerabilities are 100% validated and their risk for the business is accurate.

Neither VA, nor PT should be confused with the security audit which is a totally different service.

Continue reading →

When Cryptographic API Design Goes Wrong

Ionuț AmbrosieLeave a comment

keys with no locksWhether we like to admit it or not, failing to account for human factors and usability issues when designing secure systems can have unwanted consequences. And while Security Usability is a broad field, today I’d like to focus on what I like to call the [lack of] usability of [some] cryptographic APIs.

A paper on SSL Certificate Validation

To get my point across, I’d like to bring forth a paper written in 2012 by Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov, called The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.

In this paper, the authors claim and empirically confirm that SSL certificate validation is completely broken in many security-critical applications and libraries, meaning that any SSL connection initiated from any of these applications and libraries is insecure against a man-in-the-middle attack.

They credit these vulnerabilities to badly designed APIs of SSL implementations and data-transport libraries, which present developers with a confusing array of settings and options.

Continue reading →