AppSec Made Easy: Credential Protection
Learn how to use the F5 Advanced Web Application Firewall to protect your credentials. Identities are the keys to our applications and criminals can steal them right from the browser. DataSafe protects the credentials at the most vulnerable point. See the entire AppSec Made Easy series.
What is HTML Field Obfuscation?
And why do you need to know, anyway? I am so glad you asked! A great deal of app security focuses on the server-side component. Whether comprised of multiple microservices fronted by an API or a monolith, there is no question that a significant source of breaches occurs at the app. This is due to vulnerabilities in the platform, app frameworks (think Spring, Express, or Struts) or application code itself. Many of these apps still present a traditional HTML interface. Even if it’s using Angular or Bootstrap or some other JavaScript framework to create the real-time, interactive experience users crave, it still relies on good old HTML to solicit input from users. Many client-side attacks count on this, and exploit the markup language to great success. Interestingly, F5 Labs research found in its analysis of breaches over the past decade that 86% of the time, apps and identities were the initial target. When most folks hear “identities” it conjures up images of LDAP or ADS or perhaps more modern methods like OAuth. The reality is that before any of that comes into play, first the actual data that comprises an identity – username and password – must be collected. To do that, developers use an HTML element called “input”. The tag “input” is what tells the browser to render a text box so you can enter your credentials. To help keep passwords hidden from prying eyes (that guy reading over your shoulder right now), HTML includes the ability to further specify the type of input you’re looking for. By declaring an “input” element of type “password”, you get some default behavior that automagically masks entered characters. In raw HTML, it looks like this: input type=password name=credential_part_two> Now, that’s cool and all, but attackers know this. MItB (Man In the Browser) attacks inject scripts (or exploit other browser and HTML behaviors) to attach themselves to these fields and slurp up the credentials as users type them in. That’s obviously a Very Bad Thing™ that we want to prevent. Anti-fraud application services are designed to prevent scripts or browser extensions from successfully stealing credentials in this way. To do that, they can use a technique known as HTML Field Obfuscation (HFO). To understand how it works, first you have to see how an exchange normally works. The user requests the login page, and as part of the response, a form is returned containing the elements needed to collect credentials. You can see they are clearly labeled and easily identifiable. Before you get all angrified at developers, remember that a significant concern – especially in the enterprise – is the sustainability of software. That means it has to be clear and written in such a way that when the next wet-behind-the-ears developer is handed the application, they can follow the code and its logic and modify and/or maintain it. We are conditioned not to obfuscate variables precisely because it makes code difficult to follow and more complex than it already is. So please, try not to punch the next developer you see because of this. They’re just following coding standards. Now, obviously the naming and use of HTML types to identify credentials can make it extremely easy for malicious scripts, extensions, etc… to find exactly what they desire most: the credentials. So what we need to do is obfuscate the fields before it reaches the client, and hopefully prevent scanners, skimmers, and loggers from being able to figure out where the credentials are. We do this by inserting an anti-fraud application service into the mix. Essentially, it’s going to act as a proxy to mediate exchanges between the client and the target application and do some magic on the data to obfuscate field names. This is intended to confuse and frustrate attempts to leech off credentials. The request is made exactly the same, and passed on to the application. On the response, the anti-fraud application service quietly replaces specified HTML elements with encrypted versions using a designated private key. It then passes the modified HTML back to the client. The client renders the page as it should and the user sees no difference in the user interface. Only the HTML names have been modified, which only impact client-side scripts and frameworks. The modified page includes a script that ensures that client-side frameworks operate as expected. This technique is designed to confound attacks that rely on identifying target data based on its associated named HTML elements. IT prevents scripts and extensions from latching onto those fields and siphoning off the information. There also exist advanced techniques based on HFO that go beyond just encrypting field values, including the addition of “decoy fields” to distract attackers. No, HFO is not infallible. But it can stop lazy scripts and attacks that rely on easily identifiable field names to extract their digital bounty. HFO allows for frequent, dynamic changes of highly-sensitive form fields without the costs and time associated with modifying the application itself. This maintains the integrity (and sustainability) of the application code whilst providing a layer of protection against attempted theft of sensitive data. Although HFO and related techniques are often tightly associated with protecting financial-related applications, the reality is that all credentials are highly sought-after data today no matter what type of app or service they are for. The credential crisis is real, and so is the need to protect consumers and customers from having their credentials pilfered by malicious actors. Stay safe out there!Mazar Bot Overview
Discovered in early 2016, Mazar Bot is spread by sending SMS text messages, via a URL shortener service. Mazar Bot targeted multiple banks specifically in the German-Austrian region according to attacks that were encountered in early July 2017. This malware, seen on Android devices, permits itself to access the following device permissions: From Spam to Infection Mazar Bot is used in spam campaigns to gain access to users within a specific region, much like spear phishing. In many cases, the attack is spread via SMS, fake webpages, or email spam. First the malware tricks the user into clicking the link, and then immediately after, the user will face a login page request designed specifically for mobile devices. Once the malware has received the needed login information it displays installation info and gives an explanation on how to use and install the upcoming application. At this stage users can still question why they should be downloading another app. In order to hide from this suspicion, a php file named “apk-playstore.php” provides some assistance. Mazar Bot explains to the user how to download and use the app. Prompts the user to press the specific link button Gives screen shots that walk through the installation...this allows the device to install the application from unknown sources Runs the application immediately after installation Infection Chain After the malicious application is installed on the end user device, it asks to activate it as device administrator. In most cases the malicious application icon would be deleted and Command and Control communication will commence immediately afterwards. The ongoing communication between device and server would pull device information and look for specific targeted applications. The second stage of communication grants a user infected device with a unique ID for Database maintenance and support of campaign activity. The moment the user would interact with a legitimate bank application, Mazar Bot will cause an overlay and would display another fake page for harvesting more credentials. Interesting observation: Mazarbot (in each of the phishing campaigns) has created tailor-made applications designed specifically to attack a designated bank/organization. For each targeted application, it also creates a specific subdomain, probably for masking and tricking users which were connected to the fake login site. Strings, the C&C connection The interesting part of the apk contains some specific C&C related strings. These strings give an overview of the malware behavior and abilities that it contained. The combination of strings highly support the claim that fraudsters behind the malware plan each campaign specifically for a bank application per campaign. The features presented in the string represent device control and communication interception, allowing access into device cached memory, grabbing personal data, sending SMS, locking device, putting device into sleep mode, reporting and logging all Input/output actions, maintenance of this configuration is represented by unique ID, given by the server. Accepting Credit Cards Additionally, in the strings section, fraudsters are trying their luck by targeting Google play. The overlay that will popup to the user in mid interaction with Google play or Whatsapp, will ask for: Card number CVC Expiration Month+Year Card holder name Credit card type Phone number First, Last Name Phishing Sites Statistics Researched by Kyle Paris According to attacks we've encountered in early July, there wasn't any distinctive region target for hacked servers. The interesting patterns we did identify were compiled from groups of 8-10 phishing links with every attack. Each link main domain was slightly different, either by number or a letter, while the subdomain and subfolder remained the same. Here is a table comparing phishing links groups with their domain name: Group 1 Group 2 update9091.pw id78087.pw update9092.pw id78086.pw update9093.pw id78080.pw update9094.pw id78084.pw update9095.pw id78083.pw update9096.pw id78088.pw update9097.pw id78085.pw update9098.pw id78089.pw
CloudBleed: Guess What? There was 0-day protection
About CloudBleed If you aren’t familiar with CloudBleed, take a moment to read the following articles to get an understanding how it was found, what happened, and what PII/PCI data was (possibly) leaked: Vulnerability Disclosure from Tavis Ormandy (@taviso), a security researcher at Google Incident Response from CloudFlare 3rd party assessment from Ryan Lackey (@octal) In some of the examples shown by Tavis, or by digging into cached sites on less popular search engines, you can see how usernames, passwords, sessions, credit card info, etc could be seen in clear text despite the use of HTTPS (TLS1.2). A simplification of the flow would look like this: Request: Client >=====> CloudFlare >=====> Origin Web Server Response: Client <=====< CloudFlare <=====< Origin Web Server Despite the fact that the client is utilizing HTTPS, CloudFlare has the ability to terminate the secure connection since it has the private key. This is essentially the content (PII or PCI) that was being cached if certain conditions occurred on the CloudFlare reverse proxy. 0-day Protection Against CloudBleed So, what is the 0-day protection and what is it all about? Application Layer Encryption is a feature from F5 that would have left researchers scratching their heads when looking at the cached content. First things first, let’s dynamically encrypt sensitive parameter names using Application Layer Encryption. But really, what does that mean? Let’s take a deeper look. In all examples I will be using Google Chrome. Let’s say you have login page without Application Layer Encryption. If I were to right click on the Password box and choose Inspect, I would see something like this: As you can see from the red boxes, the parameters for my username and password are log and pwd. We can all agree that this is in human readable format (HRF). If I were to do the exact same thing with Application Layer Encryption, I would see this: In the screen shot above there are 3 things I would like to focus your attention on: Both name=log and name=pwd are no longer in HRF. Notice in the first red box that there is a slight purple hue over the value? That’s the dynamic part of Application Layer Encryption. Every few seconds the values will change. This is done on the client side, not the server side. That value will never repeat and is completely unique to the user’s session. We also removed the element IDs, id=”user_login” and id=”user_pass”. With Application Layer Encryption turned on, every user will have a unique value for name=log and name=pwd moving forward. We can also turn up the security a notch by inserting decoy fields to further confuse the bad guys. Decoy fields are only seen in the raw code and do not change the end users experience. As you can see above, there are additional IDs which makes it very difficult to pull apart in a replay attack. But Brian, what about the values being sent!?!!? Let’s look at a data submission without Application Layer Encryption from the browser via the network tools in Chrome: As you can see from the picture above, the username is briandeitch and the password is test. Although this is sent via HTTPS, CloudFlare has the private key and this is the type of data that could have been cached by search engines. Yikes! Same exercise but this time with Application Layer Encryption: Decoy fields turned off: Decoy fields turned on: As you can see from the form data, both the parameter names and values have been dynamically encrypted on the client side. Let’s say this data was leaked by CloudFlare and cached by a search engine. Couple of points: These substituted and encrypted values are single use, meaning a replay attack wouldn’t work. Good luck reverse engineering any of this. Application Layer Encryption uses private/public key technology and this key, unlike the private key for the SSL Certificate, isn’t hosted on CloudFlare. This means the payload (form data shown above, you know the values for the username and password) is completely encrypted to CloudFlare (or any other proxy for that matter). In addition, the decoy fields are sent as well. Good luck deciphering which fields are mapped to the actual application(s). Personally, my favorite part of Application Layer Encryption is that is requires no change to my back end application. This solution requires no installation or modification to the end users web browser, is 100% client-less, and transparent to the end user. At the end of the day, you can still rely on HTTPS for transport layer security however Application Layer Encryption steps up your overall security posture by using clever obfuscation and encryption to protect your data when there is a proxy (MITM device) between your customers and application(s). Lastly, Application Layer Encryption is a feature within F5 WebSafe. F5 has taken a complex security enhancement and created a point and click solution to easily protect your application(s). Configuring Application Layer Encryption Step 1: By creating a profile, specify the URIs you want protected. *Note: You are able to use wildcard URIs as well. Step 2: Add the parameters you want protected. The Encrypt checkbox is how we secure the username and password values that are being sent. By encrypting the values, this will prevent replay attacks as the values can only be used once. The Substitute Value checkbox substitutes the parameter’s value with a random value in the web application while the form is being filled. This also prevents browser based malware from capturing keystrokes as they are being entered. The Obfuscate checkbox encrypts the parameter’s name attribute. Step 2a: If you would like to insert decoy fields to further mess with the bad guys, you don’t have to be a rocket scientist. Relax, it is just a checkbox. Step 3: Associate the new profile to the application. That’s it! You have successfully configured and secured your application with Application Layer Encryption. Special thanks to BAM, Todd Morton, Chad Fazio, Jeffery McFerson, Joe Martin, and Ted Byerly for their contributions on this article.Achtung! TrickBot!
TrickBot does not rest. Following the recent addition of its first targeted US-based bank, a new version of the malware has been spotted in the wild. Now in its 11th incarnation, TrickBot has expanded its ever growing target portfolio yet again – this time increasing its focus on Germany. Figure 1 – TrickBot configuration, showing its most recent version upgrade While previously TrickBot’s focus in Germany was distinctly on Sparkassen Finanzgruppe, this latest version now includes more previously untargeted financial institutions in Germany. Figures 2-7 – TrickBot Dynamic Webinject configuration snippets showing some of its recently added targets in Germany TrickBot continues to evolve rapidly, constantly adding targets and using varying techniques to pose an ever increasing risk to online banking users and financial institutions in multiple regions across the globe. Recent TrickBot malware sample MD5s: c044f4a710f3a0b1997a4470145677ea, 07df1af1c3b8c33df61ff4f3f07f3f54 VirusTotal links: https://www.virustotal.com/en/file/f560268063ab5a2104482937212f75714a55da680d50efe4c20b1a80b29a6e8f/analysis/ https://www.virustotal.com/en/file/05389e4a60b59cb6b4d4ebe959837441b4fbbb71dd17cac77778d8973b480a26/analysis/ Analysis links: https://www.hybrid-analysis.com/sample/05389e4a60b59cb6b4d4ebe959837441b4fbbb71dd17cac77778d8973b480a26?environmentId=100 https://www.hybrid-analysis.com/sample/f560268063ab5a2104482937212f75714a55da680d50efe4c20b1a80b29a6e8f?environmentId=100 References: TrickBot targets its first US bank - https://devcentral.f5.com/s/articles/malware/trickbot-targets-its-first-us-bank-24713 TrickBot targeting Sparkassen Finanzgruppe - https://f5.com/labs/articles/threat-intelligence/malware/trickbot-now-targeting-german-banking-group-sparkassen-finanzgruppe-24420 Review of TrickBots rapid evolution - https://devcentral.f5.com/s/articles/malware/is-xmaker-the-new-trickloader-24372TrickBot targets its first US bank
The latest arrival to the banking malware scene, and successor to the infamous Dyre Trojan continues to evolve. TrickBot previously targeted banks and businesses in Australia, New Zealand, Germany, UK, Ireland, Canada, India and Singapore. In a recent update, this list has now expanded to include The United States. Figure 1 – Map showing TrickBot’s global target distribution Figure 2 – TrickBot configuration snippet showing newly added US based target. TrickBot’s target tally now includes a total of 225 unique banking and business related URLs. While this is still a far cry from vast numbers of banks and businesses targeted by Dyre globally, this number is very likely to grow in the future as the malware’s authors are constantly increasing their target tally and continue to improve their malware with new features and abilities. A previous review of TrickBot’s rapid evolution can be found here: https://devcentral.f5.com/s/articles/malware/is-xmaker-the-new-trickloader-24372 TrickBot sample MD5: 5abea77ce54fc029151a524ff1d428f VirusTotal link: https://www.virustotal.com/en/file/554132df407db525382baceb43fc0804839592fbd7038ffcd0e3736119d37be2/analysis/ Analysis link: https://www.hybrid-analysis.com/sample/554132df407db525382baceb43fc0804839592fbd7038ffcd0e3736119d37be2?environmentId=100Is "Xmaker" the new “TrickLoader”?
Overview During November of 2015, the Dyre banking Trojan, which was very prolific at the time and targeted countless financial institutions worldwide, vanished from the wild almost overnight. It was only during February of 2016 that the announcement was made that Russian authorities had arrested most of the gang that was operating the Dyre banking Trojan. (Reference: http://www.reuters.com/article/us-cybercrime-russia-dyre-exclusive-idUSKCN0VE2QS) Since then, nothing was heard from the actors behind Dyre, but it has been speculated that members of the Dyre gang which managed to avoid arrest by the Russian authorities have been integrated into other cybercrime gangs. During September of 2016 a new breed Malware has surfaced, calling itself “TrickBot”, which shares some similarities with Dyre. Among these similarities are a similar loader, similar encryption and decryption routines, and similar structure of the configuration files. (Reference: http://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html) However, it is lacking Dyre’s extensive Command and Control infrastructure, it’s also missing some of the modules that were present in Dyre such as SOCKS and VNC, and the coding style looks different from Dyre’s. TrickBot still appears to be a work-in-progress, doing little to hide its presence on an infected system. One interesting fact is that trickbot’s requests to its C2 servers contain easily identifiable User-Agent strings such as “TrickLoader” and “BotLoader”: (Example: https://www.reverse.it/sample/2c4eab037c37b55780cce28e48d930faa60879045208ae4b64631bb7a2f4cb2a?lang=en#http-traffic ) TrickBot’s Configuration and capability changes During the past few months trickbot is evolving rapidly add constantly adding capabilities, targeted entities, and upgrading its version number. Version 1000002: Initial samples of trickbot started to surface in Virus Total at around august 2016: Related md5s: · 38503c00be6b7f7eeb5076c0bd071b4c · bf621ef7e98047fea8c221e17c1837b8 · 0804499dba4090c439e580f5693660e0 · e4a8dc8fd08d4f65a68d0a40e2190c70 On the 15 th of October 2016, Fidelis Threat Researcher Jason Reaves publishes an analysis of the new trickbot malware. The analyzed sample was shown to be version 1000002: http://www.threatgeek.com/2016/10/trickbot-the-dyre-connection.html this version included the following “modules”: · systeminfo – responsible for grabbing system data · injectDll32 – responsible for browser injections The only method of injection in this version was “dynamic injects” which was implemented in a very similar to Dyre’s dynamic (“server side”) injects - https://devcentral.f5.com/s/articles/dyre-presents-server-side-web-injects Version 1000003: On the 24 th of October 2016, Independent Researcher @hasherezade published a detailed analysis of the trickbot malware which has advanced it's configuration to version 1000003: https://blog.malwarebytes.com/threat-analysis/2016/10/trick-bot-dyrezas-successor/ On the 25 th of October 2016, ASERT analysts publish insights regarding the methodologies used to initially distribute TrickBot: https://www.arbornetworks.com/blog/asert/trickbot-banker-insights/ Version 1000005: On the 7 th of November 2016, F5 Researchers Julia Karpin, Shaul Vilkomir-Preisman, and Anna Dorfman report updates to trickbot, which advanced to version 1000005: https://f5.com/about-us/news/articles/little-trickbot-growing-up-new-campaign-22790 The new version added new targeted entities, modified the configuration structure, and added a new method of browsers injections - static injects (AKA "redirects") which again, is very similar to Dyre’s static injects. Version 1000007: Version 1000007 of trickbot expanded its target list a bit more as described here: https://f5.com/about-us/news/articles/trickbot-now-targeting-german-banking-group-sparkassen-finanzgruppe-23630 Version 1000009: On the 30 th of November 2016, Version 1000009 of trickbot adds a new "mailsearcher" module: This new module has its own configuration settings: And its own C2 server IP address: The main functionality of the mailsearcher module is: · Traversal over all files in all drives in the system · Comparing their file extensions to the following list: · Creating an http connection with the user agent “KEFIR!” · Sending information over that connection in the following URL format: IP-ADDRESS/GROUP-ID/CLIENT-ID/send/ (client-id information was stripped out in this screenshot) Additionally, it changed its User-Agent header from "TrickLoader" and “BotLoader” to "Xmaker": (client-id information was stripped out in this screenshot) Another example of the changed User-Agent header can be seen here: (Example: https://www.hybrid-analysis.com/sample/3bf7d98b2fede6512fa2f5d5423a3e3b93a2ed357d2112bcadde751765bdb505?environmentId=100&lang=en#http-traffic ) On the 5 th of December 2016, Version 1000009 of trickbot adds a few more targets to its static inject ("redirects") targeted entity list. Shifting from the initial focus on dynamic injections to redirect attacks. This is an interesting shift, as the Dyre Malware had the opposite shift while it was active (it first introduced static injections and only after it shifted to dynamic injections) Related md5s: · 46ffaa075dd586a6f93a4d26a2431355 · 1c8ea23e2892c4c7155c9f976c6e661d · 26992865a2ae96ed48df8ddfc7223a13 Version 1000010: On the 6 th of December 2016, Version 1000010 of TrickBot several more previously untargeted banks in Australia and New Zealand, as well as several Singapore banks to target list – which were not previously targeted at all. This version also adds an Indian bank to the target list – again, previously not targeted at all. Related md5: · 52cab07e1a41e68bd2793a37ba04d270 Conclusion TrickBot is an example of a malware which is currently in an active development mode, and is constantly changing and adding capabilities. Its Authors are clearly trying to replicate Dyre’s capabilities and structure. We suggest to keep a close eye on its evolvements and prepare ourselves to the threats that is may pose to the security of our users.Don’t Take the Impostor’s Bait
Phishing has been around since the dawn of the internet. The term was first used in an AOL Usenet group back in 1996 but it wasn’t until 2003 when many baited hooks and lures started dropping. Popular transaction destinations like PayPal and eBay were some of the early victims of these spoofed sites asking customers to update their personal and credit card information. By 2004, it was a full-fledged ‘get rich quick scheme’ with many financial institutions – and their customers – as targets. Oxford Dictionary defines Phishing as, ‘The fraudulent practice of sending emails purporting to be from reputable companies in order to induce individuals to reveal personal information, such as passwords and credit card numbers.’ You’ve seen it, the almost perfect looking email with actual logos, images and links to a reputable company only to have it go to a slick looking replica complete with a login form. If you aren’t paying attention and do enter your credentials, you’ve just given a crook access to your money. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. More than in any other three-month span since it began tracking back in 2004. That’s around 230,000 unique phishing campaigns a month. And as recent as last week, American Express users were hit with a phishing email offering anti-phishing protection. Go figure. If you clicked the link, you were taken to a bogus Amex login page which asks for all the important stuff: SSN, DoB, mother’s maiden, AMEX number plus security code and a few other vitals. When complete, you’ll be redirected to the authentic site so you think you’ve been there all along. That’s how they work their magic. A very similar domain URL and all the bells of the original, including the real customer service 800 number. You can combat it however. F5’s WebSafe Web Fraud Protection can secure your organization (and your customers) against the evolving online fraud and you do not need any special client to detect it. WebSafe inserts an obfuscated JavaScript code which can detect malware like bait, mandatory words or if the fake was loaded from a different domain. It can validate source integrity like comparing fields for multiple users and detect threats like automatic transactions. Alerts are sent to an on premise dashboard and can also be forwarded to F5’s Security Operations Center (SOC). If you are configuring malware protection for the login and transaction pages for a financial application, it’s as simple as adding an Anti-Fraud profile to your VIP. First, you create an anti-fraud profile: Then indicate which URL should be watched and the action: Then enable Phishing detection: And when a phishing attach occurs, both the domain and the username of the victim get reported to the dashboard: The code that’s inserted is a little piece of JavaScript added to your website to detect the malicious activity. No action is needed on the part of the user since everything is handled within BIG-IP. This tiny piece of code will dramatically reduce fraud loss and retain the most important asset in business—customer confidence. Don't get fooled by a faker. ps Related: Security Sidebar: Spear Phishing Still Happens…A Personal Story Phishing you say, well that’s not my problem Getting Started with WebSafe Phishing Activity Trends Report (pdf)Lightboard Lessons: WebSafe and MobileSafe
The Web, while convenient and necessary for business, can be a dangerous and scary place. The good news is that F5 offers a security solution called WebSafe. WebSafe protects against sophisticated fraud threats, leverages advanced encryption, detects client-less malware, and analyzes session behavior in a single solution. MobileSafe is very much like WebSafe except it is uniquely designed and tuned for the mobile environment. The frosting on the cake for all this goodness is that WebSafe and MobileSafe alerts come to our F5 Security Operations Center (SOC) where our team of security experts are hard at work 24x7 to analyze all your threat data and help mitigate the threats to your business. How does WebSafe actually work? What about MobileSafe? Check out this edition of Lightboard Lessons to learn more! Related Resources: WebSafe Data Sheet MobileSafe Data SheetComment les institutions françaises peuvent se protéger contre la cybercriminalité
Les institutions financières sont la première cible des cybercriminels et exposent le plus de données sensibles sur Internet. Un compte utilisateur d’une institution financière héberge à la fois de la donnée financière (le compte bancaire du client) mais aussi les données personnelles et privées du client. Ces deux types de données sont tout aussi sensible, l’un comme l’autre. L’un permettra aux pirates de récupérer facilement de l’argent, l’autre leur permettra de revendre sur le marché noir des données personnelles (numéro de sécurité sociale par exemple). C’est pour cette raison, comme le spécifie KPMG lors d’une récente étude, qu’autant d’institutions financières ont connu une cyber-attaque au cours des deux dernières années, compromettant de nombreux comptes bancaires personnels. La menace vient principalement des malwares ou logiciels malveillants. Ceux-ci sont installés à l’insu de l’utilisateur, sur leur poste de travail dans l’entreprise ou sur leur ordinateur personnel. Pour y parvenir, les pirates ne manquent pas d’imagination. La méthode la plus utilisée est le social engineering ; c’est-à-dire l’utilisation des failles humaines et sociales des utilisateurs. Cela va de la clé USB offerte lors d’un salon professionnel, ou de l’envoi d’un mail avec pièce jointe. Une autre méthode très simple qui fait autant de dégâts est le phishing. Une fois ce malware installé, il se connectera régulièrement à un serveur nommé « Command & Control ». Celui-ci est le point de contrôle des pirates, leur permettant de lancer leur campagne d’attaque. Une campagne consiste à cibler une institution (financière, gouvernementale, commerciale) et récupérer les informations personnelles de l’utilisateur. Par exemple, les pirates indiqueront aux malwares de cibler la société www.mabanque.fr et plus particulièrement la page d’authentification. Le malware ne se réveillera qu’au moment où l’utilisateur se connectera sur www.mabanque.fr. Une fois les identifiants (utilisateur, mot de passe, OTP …) saisis, le malware les enverra au serveur Command & Control. Cependant, un malware peut être beaucoup plus intelligent, et peut exécuter des actions en lieu et place de l’utilisateur, sans que celui-ci ne s’en rende compte. Prenons comme exemple un virement que l’on souhaite réaliser via le site de notre banque www.mabanque.fr. Lors d’un virement, le client spécifie un compte destinataire et un montant. Le malware modifiera la requête lors de son envoi avec un autre compte destinataire (celui du pirate) ainsi qu’un autre montant. En fonction des méthodes de sécurité mises en place par l’institution financière, l’utilisateur peut ne pas s’en rendre compte. Il est donc important de protéger les clients des institutions financières car ces derniers sont de plus en plus conscients des risques, et sont 48 % à citer les attaques informatiques comme une raison de changer de banque (selon KPMG). Le malware s’installe sur le poste du client. Les solutions de protection doivent donc s’intégrer à ce poste de travail sans que celui-ci ne soit « contrôlé » par l’institution financière. Ces solutions doivent être transparentes, sans nécessiter d’actions de la part de l’utilisateur pour : F5 Networks, via son offre Anti-Fraud Websafe, permet de répondre à l’ensemble de ces problématiques ou menaces. Protéger les identifiants : un identifiant peut être protégé en étant chiffré à la source, c’est-à-dire dans le navigateur ou l’application mobile. La solutions Websafe de F5 Networks permet le chiffrement à la saisie des identifiants afin que le malware ne puisse pas les récupérer en « clair ». Celui-ci ne récupérera que des identifiants chiffrés, donc inutiles. Protéger les transactions : une transaction consiste à réaliser une suite d’actions à l’écran (navigateur ou application mobile). La première étape consiste à sélectionner un compte source, puis un destinataire, puis de saisir un montant. Tout ceci prend un temps « humain » (saisie, déplacement de la souris …). La solution Websafe de F5 Networks permet de contrôler cette saisie et de s’assurer qu’elle se rapproche d’une saisie « humaine ». Détecter le phishing : il est impossible d’empêcher un pirate de télécharger le site de www.mabanque.fr et de le déposer sur un serveur Web pirate. Idem, il est impossible d’empêcher ce hacker d’envoyer une campagne d’email aux clients de cette institution et de leur demander de s’authentifier sur le site pirate www.mabamque.fr (changement du N par un M). Par contre, la solution Websafe de F5 Networks permet d’identifier la présence d’une copie du site et de fermer ce site (dans la mesure du possible). De plus, Websafe de F5 Networks permet de connaître les utilisateurs ayant saisi leurs identifiants sur ce site pirate, et donc de les informer ou bloquer leur compte temporairement. La fraude en ligne est la menace principale des institutions financières et celles-ci doivent s’en protéger. F5 Networks propose des solutions innovantes couplées à des offres de services (SOC) permettant de garantir une analyse temps réel des menaces et d’adapter la sécurité mise en place (campagne de phishing, campagne de malware …). Pour cela, F5 Networks s’appuie sur ses SOC et sur son LAB (www.f5.com/labs).
