{"id":149,"date":"2008-02-12T10:04:08","date_gmt":"2008-02-12T18:04:08","guid":{"rendered":"http:\/\/cubist.cs.washington.edu\/Security\/2008\/02\/12\/security-review-online-banking\/"},"modified":"2008-02-12T19:34:26","modified_gmt":"2008-02-13T03:34:26","slug":"security-review-online-banking","status":"publish","type":"post","link":"https:\/\/secblog.cs.washington.edu\/Security\/2008\/02\/12\/security-review-online-banking\/","title":{"rendered":"Security Review: Online Banking"},"content":{"rendered":"<p>Online Banking &#8211; Many banks now provide an online application that will let the bank&#8217;s clients manage their funds. This includes both, viewing, as well as transferring funds to arbitrary third parties through a feature called &#8216;Online Bill Pay.&#8217; Thus, given access to a user&#8217;s online banking credentials, an adversary can easily drain the user&#8217;s funds.<\/p>\n<p><!--more--><\/p>\n<p><strong>Assets and Security Goals<\/strong><\/p>\n<ul>\n<li>Availability. The online banking application should be available at all times for bank clients<\/li>\n<li>Funds. Adversaries should not be able to affect funds.<\/li>\n<\/ul>\n<p><strong>Weaknesses<\/strong><\/p>\n<ul>\n<li>Adversary may attempt to disrupt service. As an online service it is susceptible to any sort of denial of service attack. Denial of Service attacks come in many flavors including floods of ICMP packets or at the application level. Alternatively, Distributed denial of service attacks may be performed pooling the resources and bandwidth of many computers to perform the attack.<\/li>\n<li>Adversary may attempt to extract\/move\/increase\/decrease funds in a non-legitimate manner This can be done in many ways. Some examples:\n<ul>\n<li>Phishing: Adversaries can register URL&#8217;s that use unicode characters but render identically to the name of your bank. They can then send emails requesting customers re-enter their personal data, or trick users to interact with their page instead of the legitimate bank&#8217;s page.<\/li>\n<li>Adversary may install a keylogger on a public terminal. When an unsuspecting user uses the terminal to conduct online banking, their credentials will be logged by the keylogger. The adversary can then emplpy their credentials to drain the user&#8217;s account<\/li>\n<li>Some banks (untill even very recently) used to send online passwords in the clear, or encrypted in an insecure way (SSL was not used!). A packet sniffer attached to the network with a user performing online banking could then reveal their credentials.<\/li>\n<li>As we know, SSL is susceptible to a man-in the middle attack. If an adversary masquerades as an access point (say at an airport or coffee shop) then when a user performs online banking over SSL, the adversary will be able to spoof the SSL session with only the slightest hint to the user that something may be wrong. An unsuspecting user will likely not examine the certificate authority and continue<br \/>\nbanking as normal. In the process, the adversary will have full control of the user&#8217;s banking session.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Potential Defneses<\/strong><\/p>\n<ul>\n<li> Defenses against DoS and DDoS: There are lots of ways to defend against a DoS including firewals and other network hardware that can differentiate good traffic from DoS traffic thus reducing the ammount of traffic your services have to contend with.<\/li>\n<li> Defenses against phishing: Most browsers will now detect and warn about potentially adversarial URL&#8217;s that attempt to masquerade as others. Users should also be on allert since it is unlikely that their bank would suddenly request them to re-enter personal information.<\/li>\n<li> Keylogging:<br \/>\nDon&#8217;t use public terminals for secure communications &#8211; you cannot trust the computing<br \/>\nenvironment on a public terminal<\/li>\n<li> Plaintext passwods:<br \/>\nBanks should use secure communication at all times.<\/li>\n<li> SSL MITM Attacks:<br \/>\nExamine the CA for your session carefully and make sure it is trusted.<\/li>\n<\/ul>\n<p><strong>Risk Evaluation<\/strong><\/p>\n<ul>\n<li>Phishing &#8211; high: Individuals may not notice the hoax and, since they trust their bank, re-enter their private information.<\/li>\n<li>Keylogging &#8211; high: Many individuals will need to check their ballance on the run &#8211; for example when they are at an airport or out shopping. An internet kiosk can be convenient, but it may come with a keylogger.<\/li>\n<li>plaintext passwords &#8211; low: most (hopefully all) banks have switched away from this.<\/li>\n<li>SSL MITM attacks &#8211; medium: this one is somewhat difficult to trick the user into and relies heavily on chance (both that the user will connect to the adversary&#8217;s access point, and that the user will not examine the CA for the SSL cert)<\/li>\n<\/ul>\n<p><strong>Conclusions<\/strong><\/p>\n<p>The risks in online banking are high since there is potentially a direct monetary gain for an adversary attacking this system. Thus it is absolutely essential that both the applicaiton provider (the bank) and the user take all the security measures seriously and consider the security of their communications channel diligently.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Online Banking &#8211; Many banks now provide an online application that will let the bank&#8217;s clients manage their funds. This includes both, viewing, as well as transferring funds to arbitrary third parties through a feature called &#8216;Online Bill Pay.&#8217; Thus, &hellip; <a href=\"https:\/\/secblog.cs.washington.edu\/Security\/2008\/02\/12\/security-review-online-banking\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":51,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[100,32],"class_list":["post-149","post","type-post","status-publish","format-standard","hentry","category-security-reviews","tag-online-banking","tag-security-review"],"_links":{"self":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/users\/51"}],"replies":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/comments?post=149"}],"version-history":[{"count":0,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/149\/revisions"}],"wp:attachment":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/media?parent=149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/categories?post=149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/tags?post=149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}