Man-in-the-browser (MITB) attack, a form of Internet threat related to man-in-the-middle (MITM) attack. It is a proxy Trojan horse that infects a web browser by taking advantage of vulnerabilities in browser security to modify web pages. It modifies transaction content or insert additional transactions, all in a completely covert fashion invisible to both the user and host web application.
A MITB attack will be successful irrespective of whether security mechanisms such as SSL/PKI and/or two or three-factor Authentication solutions are in place. A MITB attack may be countered by utilizing out-of-band transaction verification, although SMS verification can be defeated by man-in-the-mobile (MITMO) malware infection on the mobile phone.
Trojans may be detected and removed by antivirus software with a 23% success rate against Zeus in 2009, and still low rates in 2011. The 2011 report concluded that additional measures on top of antivirus were needed. A related, more simple attack is the boy-in-the-browser (BITB) attack. The majority of financial service professionals in a survey considered MITB to be the greatest threat to online banking.
In a nutshell example exchange between user and host, e.g. an Internet banking transaction such as a funds transfer, the customer will always be shown, via confirmation screens, the exact payment information as keyed into the browser. The bank, however, will receive a transaction with materially altered instructions, i.e. a different destination account number and possibly amount. The use of strong authentication tools simply creates an increased level of misplaced confidence on the part of both customer and bank that the transaction is secure. Authentication, by definition, is concerned with the validation of identity credentials. This should not be confused with transaction verification.
Protect against malicious access to the browser:
Organizations need to control all access to browser interfaces (Add-on’s, API and DOM) to prevent data theft and end user social engineering. This ensures sensitive HTML information is not captured and page content is not tampered with. The ability to detect, analyze and block unauthorized attempts to override browser functions can help prevent fraud through compromised endpoints until the threat is fully removed.
Prevent and Remove Malware Infections:
MITB attacks are carried out by malware residing on the end users machine. Organizations need to ensure endpoints are not compromised by malware by disabling exploit code used in drive-by-download infection attempts, and blocking malware downloaders and installers. If a device is already infected, automated malware removal cleans up the endpoints quickly and cheaply.
We all enjoy keeping up with friends and family on social media, but we have to be mindful of our privacy and security when we do. Here are some suggestions to help keep your personal information private:
1. Understand what information the site needs for your account and how they use it in the first place.
Never give more information than is necessary to operate an account. Usually this includes:
- an email: Never use a work email address; consider creating a separate one for social media sites
- If your birthday is required, consider using a nonsense date like January 1st 1904: Your real birth date is tied to important IDs, like your driver’s license, social security number, or passport
2. Make sure that your posts are not indexed into search engines.
- Each social media site handles this in a different way. For example, you can use your Facebook settings to block search engine indexing, or on Twitter you can make your posts visible to people who follow you only
3. Remember to set all your posts private on Instagram so only friends can see them and, of course, be cautious of what you post on any social media site.
- Just because you can post it doesn’t mean that you should
4. Make sure that mobile apps for social media sites are not using personal data or sharing additional private information.
- You should also use caution when linking together different apps like Facebook and Twitter or news apps like Flipboard and Facebook
This easy-to-use application allows you to review and set all your social network privacy preferences from a single screen.
Using these four tips can help insure your privacy online and make social media a safer place.
Digital certificates are the backbone of the Public Key Infrastructure (PKI), which is the basis of trust online. Digital certificates are often compared to signatures; we can trust a document because it has a signature, or certificate authority (CA) by someone we trust. Simply put, digital certificates are a reproduction of a simple model which occurs in the real world.
Incidents involving digital certificates have been in the news recently. Issues surrounding digital certificates and CAs are not always clear or noticeable to end users. However, IT managers, software developers, and other security professionals need to understand these problems so that the risks can be properly managed.
So who or what can we trust online?
Every computer connected to the Internet contains a list of trusted root CAs. These root CAs issue certificates, which can be used to either sign certificates for other CAs or to servers. There needs to be a “chain of trust” from any certificate that the system sees to any of the root certificates that it trusts.
What does “trusted” mean?
If a secure connection or signed file is “trusted”, this generally equates to an absence of warnings. Digital certificates are used to secure websites using SSL/TLS, identify and validate executable files using code signing, and secure email via Secure/Multipurpose Internet Mail Extensions (S/MIME). If a browser accesses an HTTPS server with an untrusted server certificate, it will generate a warning. If an unsigned or untrusted executable file is run, a warning message may be generated. A user may see these messages and avoid potentially risky behavior.
HTTPS is widely used as a way to assure users that connections to sites are authentic. Many users view the “green bars” that browsers use to mark HTTPS addresses as a sign that their connections are safe.
This trust is based on two things:
- CAs are not supposed to issue certificates to inappropriate users.
- Users (e.g. PC, browsers or mobile devices) should not add any inappropriate CA to the list of trusted CAs.
Unfortunately, the basis of this trust is now being challenged. Institutions and organizations that may not necessarily be trustworthy are widely thought of as such.
Here are several cases that highlight the problems, in today’s trust-based CA system.
Trust lost: CAs issuing certificates to inappropriate users
CAs need to have a good track record when it comes to securing their own systems to ensure they don’t issue improper certificates. However, they have been incidents where their own security and processes were targeted.
In 2011, an attacker calling himself the ComodoHacker was able to penetrate the systems of Diginotar, a Dutch CA. The attacker issued multiple fraudulent certificates. The loss of confidence in Diginotar’s security led to major operating system vendors removing them from their lists of trusted CAs. This eventually led to Diginotar shutting down as a business.
While Diginotar was a relatively minor player in the CA market, the attacker also claimed to have access to the networks of Comodo, which was a far larger CA.
More recent cases are just as troubling. In March 2015, Comodo issued a certificate for the live.fi domain to an unauthorized party. This domain was the Finnish domain of the live.com online services, which is a part of Microsoft. How was this the case?
Comodo issued what are known as Domain Validation certificates to Microsoft. These types of CA require the site owner to verify that he does control the domain he wants a CA for. The most common method is to send an email from that domain with one of several possible email addresses, namely:
The live.fi domain is used by Microsoft to provide free email… and a clever Finnish man found that the address firstname.lastname@example.org was available. He was able to acquire this address and use it to obtain certificates for live.fi that would have been trusted by any browser, but was not under the control of Microsoft. In interviews, the Finnish man stated he had already reported the problem to Microsoft and Finnish authorities in January of 2015.
The certificate could have been used to mount man-in-the-middle (MITM) attacks with a certificate that would have been verified by any browser in use. This would have fooled many users into giving up their credentials. Comodo cancelled the certificate, and Microsoft released a separate update for Windows as well.
Fortunately, there was a silver lining. Only one fraudulent certificate was created, and it could not be used for other purposes. This is because the allowed uses are defined in the certificate (Extended Key Usage). Certificates for SSL servers can only be used for server verification; code signing certificates are limited to that specific purpose as well.
Later in the month, Google had their own certificate snafu. They discovered that an Egyptian ISP (MCS Holdings) held a digital certificate that could be used for MITM attacks via a proxy. Generally, these proxies require that a certificate be installed in devices to be transparent. However, in this case, the MCS Holdings certificate was signed by the China Internet Network Information Center (CNNIC), which was included in root stores. This means that any certificates issued with the MCS Holdings certificate would be seen as valid by systems, even if they had no “right” to issue that certificate (i.e., for domains they did not own).
As in the case of Diginotar, this incident has resulted in serious consequences for the CAs involved. The certificate issued by MCS Holdings has been blacklisted by Google, Microsoft, and Mozilla. In addition, CNNIC itself has been targeted for action as well.
Both Google and Mozilla have indicated that moving forward, certificates issued by CNNIC would no longer be trusted. This means that while organizations that currently rely on CNNIC-derived certificates can still use them, once these certificates expire, new certificates (with a different CA) will need to be acquired.
These cases highlight the inherent risk in a CA-based model: attacks targeting CAs can occur, and if these certificates fall into the hands of attackers with strong motives to intercept communications, user information could be put at risk. For the CAs themselves, any lapse in the process of how certificates are issued can result in a swift blacklisting, instantly ruining what can be a profitable business for the CA.
Mistrust added: inappropriate CAs among trusted CA lists
The most recent case of a CA being added to user systems was Superfish, where adware capable of monitoring HTTPS traffic was preinstalled on Lenovo PCs. Due to the (poor) way it was implemented, in a nutshell, anyone could issue any certificates.
This means on any PCs with Superfish installed, the trust placed in HTTPS might well be misplaced: phishing by making a malicious sites appear to be secure, intercepting communications using MITM attacks, signing malware so that users would run it, making users believe that signed mail was legitimate.
It is difficult, if not impossible, to use the Internet if there is an underlying current of distrust. If we can’t tell if our visits to Gmail, Facebook, Twitter or online banking sites are safe, we can’t even browse websites. If we can’t tell if the program we’re try to run is real or not, even opening what we think is Notepad entails a risk.
What should users and CAs do?
CAs need to ensure that their own systems are secure to minimize the possibility of fraudulent certificate issuance. They should also be careful about issuing certificates to widely recognized and popular domains, especially since the effects if such a wrongly issued certificate becomes public may be significant. A system based on trusting institutions (such as CAs) only functions well if the said institutions are actually trustworthy.
CAs should consider verifying via other means of communication (such as the phone) requests for certificates from domains, as this is a step cybercriminals may have difficulty meeting. Recipients of certificates with more privileges (such as the one issued to MCS) should be subject to tighter controls to prevent potential abuse.
Site owners who want to ensure that fraudulent certificates are not issued in their name should consider pre-registering the email addresses frequently used for website verification, to ensure they stay under the control of the site administrator. Alternately, those addresses should be set aside and not registered at all.
The current CA-based system of trust is not perfect, and relies on both certificate authorities and users to exercise good judgment and prudence. It is far from perfect, but it is what we have now. Additional safeguards can improve the security of SSL certificates. As more and more sites become HTTPS-only, this issue will become more prominent in the coming years.
Palo Alto Networks discovered a widespread vulnerability in Google’s Android OS. The vulnerability mentioned in a blog post released Tuesday, more than a year after initially discovering the bug and alerting Google and other Android manufacturers of its existence. Any attacks leveraging the bug rely on the fact that Android packages (APKs) downloaded through Google Play are installed to a protected space, whereas apps downloaded through a third-party store are saved to unprotected local storage.
To fall victim to an attack, a malicious application must be installed on a device. This app can come from either a legitimate or third-party app store and can function perfectly. However, written into the app is a code that allows it to detect when the compromised user is installing a new app, according to the post.
The malicious app will check whether the new app is being installed through a third-party store or Google Play, or, more simply, if it's being saved to a protected space or unprotected local storage, the post says.
If the app is going to be saved in an unprotected space, the malicious app begins taking action. At this point, it will overwrite the legitimate app with malware while a user views a permission page. More permissions could be provided than detailed in the permissions page, and the device becomes officially compromised.
The vulnerability affects Android 2.3, 4.0.3-4.0.4, 4.1.X, and 4.2.x. Android Open Source Project issued patches for Android 4.3 and later, dropping the vulnerability rate to 50 percent, Ryan Olson, Unit 42 intelligence director, Palo Alto Networks, said in an interview with SCMagazine.com.
No exploits had been spotted in the wild previous to this blog posting, Olson said, but he recommended that users only download from legitimate app stores.
“Generally, our guidance to any enterprise deploying Android is to keep it as locked down as possible,” he said. “Don't allow sources other than Google Play to install apps on the phone.”
The company also released a vulnerability scanner app through Google Play that can determine whether a device is vulnerable.