Android Trojan puts Two-Factor at Risk

As recently reported by Russian anti-virus organization Doctor Web, a new trojan malware is on the loose propagating through Android based devices that, among other things, is capable of intercepting the SMS text messages frequently used to facilitate two-factor authentication.  The trojan, which is a form of an already known family of malware called the ‘Android.Pincer’ family, manages to fool unsuspecting users into installing it by posing as a security certificate that prompts that it needs to be installed.

Once the user allows its installation, it then shows another faux message stating the “Certificate installed successfully! Your device is protected now.”  Meanwhile, the malicious app begins to collect personal data from the phone to then forward to remote servers. What’s more is that once the data is sent, the app enters a ‘wait for instructions’ mode during which it can receive commands from attackers, allowing them to begin sending SMS messages from specified numbers, terminate and execute applications on the phone, and intercept incoming messages.

By intercepting incoming messages, this malware is a first of its kind, capable of reading OTPs (One-time passwords) intended for two-factor authentication, hence negating the enhanced security the mechanism provides.

An age where we must be equally as wary of catching viruses on our phones as we are on our PCs is rapidly approaching.  Please ensure that when you hit that ‘allow’ or ‘install’ button, that you’re perfectly aware of whatever or whomever it is you’re allowing access to your data!

State College Tightens Security

Among the plethora of other organizations we blog about strengthening their cybersecurity, Colleges are too under attack, and are so taking action to ensure their networks are properly protected.  Last month, USA Today reported that Greg Eller, the chief information officer at Northwest Florida State College is doing just that.  Following a data breach in which a hacker took advantage of mistakes made during a server upgrade last year, Eller’s now interested in upgrading their environment in order to protect the personal information stored on their systems.  Among the personal information compromised in the attack were phone numbers, addresses, and even social security numbers of a large number of students.

Following the incident, NWF State College had hired the expertise of Digital Defense Inc, which now performs regular safety checks on the school’s systems, as well as provides education on network vulnerabilities.  Speaking from experience, Eller now suggests other school administrators educate themselves on network defense.  “There are bad guys out there trying to get in,” he says, “The best thing we can do is train ourselves and educate ourselves about them.”

Other schools are already well aware of the importance of this type of education.  The Polytechnic University of New York has offered a masters degree in cybersecurity for around 10 years, intended to cover these exact sorts of situations.  In addition, they also hold a “Cyber Security Awareness Week Capture the Flag: Application Security Challenge” competition in which entrants manage to uncover vulnerabilities in a network system.  Along with Polytech, Penn State, and University of Maryland also offer programs of this kind.

The theme continues to ring true with these organizations: Awareness is key when it comes to protecting our virtual data.

Read More

 Education Link Banner

The Shortcomings of Two-Factor

As more and more organizations are adding two-factor authentication systems to their web applications, the reactions are in.  Among those with  appreciation for the stronger authentication mechanisms are also various criticisms of the approach, ranging from resistance due to holding-up workflow, to reminding us that even the most hardened of locks can still be picked.  Whereas the two-factor trend continues to expand, as we’ve continually reported on this blog staggering numbers of organizations continue to ignore the solution, and these accounts may shed some light on the reasons for their resistance.

MedAllie’s A. John Blair MD is one such fellow that has expressed disinterest over implementing two-factor within EHR (Electronic Health Records) security at the Health IT Policy Committee in January.  Citing concerns over productivity, Blair states that he sees the additional factors of security as a workflow obstacle, stating that clinical workflow should be the topmost priority when evaluating the system’s security:

“If the provider honestly believes these enhancements will improve care and efficiency–and particularly if they are indirectly tied to increased reimbursements for improved health care value–interoperability will advance rapidly. If the providers do not believe this, nothing else we do here will make much of a difference in the long run.”

Blair’s point is a certainly a valid one, though prioritizing accessibility to patient sensitive data over ensuring its security is surely a matter of conflict of interests, and so one whose right or wrong answers are purely situational.  In this case, as in many, the need for security might not be apparent until data becomes compromised.

In another article, Mark Risher, CEO and co-founder of Impermium, a vendor of digital fingerprinting software lays out his reasons why the two-factor authentication system is not the be-all end-all measure for securing data that it’s being made out to be.  He feels as though “service providers need to take on more of the responsibility for securing a consumer’s information online, utilizing similar proactive monitoring and not expecting [two-factor] perimeter defenses to suffice”.  Stating that while multi-factor approaches to security certainly enhance it, that more still must be done to guard against hack attacks.

Risher’s suggestion is a sort of ‘virtual police’, in the form of learning algorithms that, much like actual policemen, can track and intelligently identify suspicious behavior.  His description largely resembles contextual authentication, which may prove to be the heightened level of security over two-factor that some are looking for.

Read More – Physician sees two-factor authentication as efficiency barrier

Read More – Why two-factor authentication isn’t a cure-all

Cross-Site Request Forgery

What is Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is defined as an application on a web server being left vulnerable to background requests from otherwise unauthorized users.  Simply put, a well-meaning user unknowingly executes a malicious request from one web site, while logged into the other web site.  The site they are logged into is the location of the cyber-crime and the other web site is the malicious site that presents the harmful request.

To further understand how CSRF can affect you, we will take a look at a common online bank account example.

Let’s say you have an online account at your favorite bank and you have logged into the bank’s web site because you want to check your account balances before you leave for your Winter vacation.  Before you get a chance to check your balances and logout of the bank’s web site, you notice an email from your travel agent and you leave your browser (still logged into the bank web site).  After you read the travel agent email, you decide to check other emails.  One email rather catches your eye and you want to learn more about the content, so you click on the link in the email that takes you to the site.  Well, as good as the site looks, in the background it has been hard coded to send a fund transfer request that moves money from your account to the account of a Cyber Bad Person within the bank that you just happened to be logged into.  Because you are logged in, the fund transfer request is not challenged and the swindler has managed to transfer your money to their account without you knowing that you did it.

How to Exploit a CSRF Vulnerability

A bank web-site is configured to accept requests that are sent to a specific URL with parameters to supply the data for the requested transaction.  For example, a request sent to the onlinetransfer URL with parameter values for Account, Routing and Amount will perform a fund transfer from the Account to the Routing account for the specified Amount.  In addition to the request, a session identifier stored in a cookie is also sent with the request to identify the request as coming from an authenticated bank user.  A would be “Bad Person” learns about this request syntax and wonders if there is a way to get a bank customer to execute this transfer fund request to move money from the unsuspecting victim’s account to their own account.  They would create their own web page that executes the transfer request when their page is loaded.  Of course the event would only take place if the user was also authenticated to the bank’s web site.  The attacker sends out intriguing emails to 100s of thousands of people in the hopes that some of them would be curious enough to accept the invitation to visit the site.  When already logged in user does access the “bad” site and cause the malicious request to be sent, the session cookie verifying the authenticity of the user is also sent so the bank doesn’t challenge the request and makes the transfer.  To summarize, there are three items that need to be in place for a CSRF attack to take place:

  1. Victim must be logged into the target site to be attacked
  2. The target site does not perform re-authentication before each sensitive transaction
  3. User opens the malicious web-site to allow the link to be sent to the bank

How to protect against CSRF

Begin by searching the web application for functionality that could lead to an unwanted malicious action.  Next determine all of the parameters needed for the action to succeed and decide if an attacker can easily determine or guess that proper values.  If so, this is a CSRF vulnerability.

The easiest solution that will take care of most attack attempts is to require and sensitive transactions to be initiated through a POST request as opposed to a GET request.  The POST method is much more difficult (but not impossible) to breach with a CSRF attack.  Also make it as difficult as possible for an attacker to learn what the request is supposed to look like.

In addition:

  • Require re-authentication before any sensitive transaction is completed
  • Require out-of-band confirmation – user has to respond to a cell phone text message to authorize the transaction
  • User transaction specific nonces

How nonces help – when a user wants to make a money transfer they click on a link, prior to rendering this page, the web app generates a cryptographically random number (nonce) and stores it in the server side session as well as in the form being used to transfer money as a hidden field.  The user then fills out the routing number, account and transfer amount and when the transfer request is submitted to the server, the nonce from the hidden field is also submitted.  Prior to completing the money transfer, the server application will compare the delivered nonce to the one stored in the user’s server side session.  If they match, the transaction is allowed.  Before the use of the nonce, the attacker was easily able to populate the parameters of the transfer request being sent.  Considering that the nonce is only created after the login and before the transfer request, it would be extremely difficult for an attacker to acquire the nonce.  Particularly if the attack scripting has been setup to automatically run when the user clicks the link and the attacker is not involved.

Cloud Security an Afterthought


The cloud is growing fast, very fast.  As more organizations consider joining the trend of offering cloud services, some 90 percent, according to a survey by Symantec Corp, perhaps the biggest challenge for them is ensuring all the data on that cloud is secure.  Hosting your data online so that it may be accessible to you on any device where ever you are comes with substantial risks, begging the question of how you truly, confidently prevent others from doing the same.

The question has been thus far largely unanswered, but that isn’t hindering those organizations excitement, and certainly isn’t hindering the cloud’s continuing expansion.  Despite those 90 percent, the same Symantec survey found that 77 percent of organizations know of unsecured cloud deployments, of which 40 percent knew of information breaches, and 25 percent of hijack accounts on cloud services.

What’s being identified to be the greatest obstacle in the way of a reliably secure cloud is the Bring You Own Device BYOD trend, whose aim is for IT to allow users to implement their own PCs, tablet and smartphone devices at their organizations.  In a survey conducted at the RSA conference in San Francisco, of 176 IT security professionals,  44 percent cited BYOD as their most significant roadblock – however just 18 percent expressed they were dissatisfied with the current security situation, 41% had no opinion of it, and a little over half (51 percent) were happy with it.

It would appear that, with all the excitement surrounding the cloud and offering next generation services, that the lack of attention paid to securing these services is simply due to a lack of awareness of their current state of fragility.  It’s no secret that cloud providers are under constant siege – but in many cases having your data compromised is the only true motivator to give it a closer look.

Read More

Social Networkers Invite Cyber Attacks via Convenience Options

Online security means many things, and is ultimately the responsibility of not only Web App service providers, but their users as well to ensure they’re following safe security practices.  Online security is a two-way street, and for the same reason you don’t go around handing out your password to people, awareness of secure practice when using websites is key to properly leveraging the (hopefully) robust authentication mechanisms they have put in place.

In a worldwide survey conducted by ‘IObit’ and taken by more than 10,000 people last month, it was shown that nearly a third of those participants lack that very awareness – routinely compromising their accounts by abusing convenience features like the “Keep me Logged in” check box found on so many login forms.  The feature is not only dangerous when used in the wrong place, such as a public kiosk, where, after you’ve left witting hackers can later access your account on the same machine.  Even when used on private machines is a margin of risk introduced, provided the cookies the “Keep me Logged in” feature uses are intercept-able , to be later used to forge your identity to the same site.  Which begs the question as to whether such features should be available in the first place; they appear to cause more harm than good.

The same survey also revealed that almost half of those people only change their password when they are forced to do so.  Around 15% of them stated that they have never changed their password.  As more and more of our data is stored online, it’s suggested that such a lack of concern over password security is due to a lack of understanding that passwords are slowly becoming the only obstacle in the way of hackers and your personal data.  What’s more, with everyone using the “Keep me Logged in” feature, they end up entering their password so rarely, that it becomes even more of an afterthought.

Make sure you’re doing your active part in keeping your data safe, and not simply leaving it up to the website logins themselves to keep your data safe.

 Read More

Salted Passwords Explained

images (16)

What is a “salted” password?  Is it anything like a “salted pretzel”?   Does it also go good with mustard and a soda?  Let’s find out… First a little background on why passwords get “salted”:

Passwords are no longer kept in clear text, but are now hashed before being stored on a computer.  Hashing a password consists of applying an algorithm to it to produce a completely new value.  The new value will always be the same when using the same hashing algorithm against the same password.  The hashed version of the password is stored and in the future, when a user enters their password, the authentication utility will apply the same hash algorithm against the entered password and then compare that hash to the hashed password value that was stored when the password was first set.

The problem with hashing is that most people choose simple passwords which make them easy to guess.  All an attacker has to do is generate a list of common passwords and their corresponding hash value.  Each hash can be compared against all of the stored hashes and when a match is found the attacker knows what password was used to create the matching hash and thus has the password for that account.

Salting a password (or creating a salted password) simply means concatenating an additional random string value (the salt) to the password before generating the hash.  Now the hash is being created from a random password value and an attacker cannot use a list of predetermined passwords and their hashes to try and hack a user’s account.  The salt can be stored in the clear with the hash of the password.

So the short answer is that passwords are salted to thwart would be hackers from learning the password associated with a stored hash.

To answer the original question, a salted password will not taste as good as a salted pretzel, but to give the salted password its due respect, the salted pretzel will not protect a password as good as the salted password.

For your convenience, here is another author’s explanation of a salted password:

“A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. This allows for later authentication while defending against compromise of the plaintext password, even in the event that the database is somehow compromised. The original intent of salting was primarily to defeat pre-computed rainbow table attacks that could otherwise be used to greatly improve the efficiency of cracking the hashed password database. A greater benefit now is to slow down parallel operations that compare the hash of a password guess against many password hashes at once.” 1