The Top 10, Top Predictions for 2012
Around this time of year, almost everyone and their brother put out their annual predictions for the coming year. So instead of coming up with my own, I figured I’d simply regurgitate what many others are expecting to happen. Security Predictions 2012 & 2013 - The Emerging Security Threat – SANS talks Custom Malware, IPv6, ARM hacking and Social Media. Top 7 Cybersecurity Predictions for 2012 - From Stuxnet to Sony, a number of cyberattacks emerged in 2011 that experts have predicted for quite some time. Webroot’s top seven forecasts for the year ahead. Zero-day targets and smartphones are on this list. Top 8 Security Predictions for 2012 – Fortinet’s Security Predictions for 2012. Sponsored attacks and SCADA Under the Scope. Security Predictions for 2012 - With all of the crazy 2011 security breaches, exploits and notorious hacks, what can we expect for 2012? Websense looks at blended attacks, social media identity and SSL. Top 5 Security Predictions For 2012 – The escalating change in the threat landscape is something that drives the need for comprehensive security ever-forward. Firewalls and regulations in this one. Gartner Predicts 2012 – Special report addressing the continuing trend toward the reduction of control IT has over the forces that affect it. Cloud, mobile, data management and context-aware computing. 2012 Cyber Security Predictions – Predicts cybercriminals will use cyber-antics during the U.S. presidential election and will turn cell phones into ATMs. Top Nine Cyber Security Trends for 2012 – Imperva’s predictions for the top cyber security trends for 2012. DDoS, HTML 5 and social media. Internet Predictions for 2012 – QR codes and Flash TOP 15 Internet Marketing Predictions for 2012 – Mobile SEO, Social Media ROI and location based marketing. Certainly not an exhaustive list of all the various 2012 predictions including the doomsday and non-doomsday claims but a good swath of what the experts believe is coming. Wonder if anyone predicted that Targeted attacks increased four-fold in 2011. ps Technorati Tags: F5, cyber security, predictions, 2012, Pete Silva, security, mobile, vulnerabilities, crime, social media, hacks, the tube, internet, identity theftHow BIG-IP can help secure your network against malware (Maze and Cloud Snooper)
In the F5 SIRT and F5 Support, we are often asked how F5 products can be used to defend against threats like ransomware, malware and rootkits. Threats like these can enter a target network through a multitude of vectors specific to the target endpoints – email spam campaigns, phishing and spear-phishing attacks, drive-by download vulnerabilities – but they can also enter the network through direct compromise of internet facing hosts. It’s tempting to look at F5 products and think they aren’t designed to detect a malicious binary being injected into your network, and while (with the exception of ICAP virus scanning of files uploaded to a webserver) that might be true, it is definitely not true to think that F5 products can’t be used as part of a defence-in-depth strategy to protect yourself from both compromise and post compromise exploitation. So let’s talk about a few ways you can bolster your network security using F5 products… The BIG-IP itself The first step is to understand that the BIG-IP is usually found sitting at the border of your network, therefore it is crucially important to protect the BIG-IP from compromise. If the BIG-IP is compromised then it doesn’t matter how good your Advanced WAF policies are or your AFM rulesets, the attacker has a neat jump-box which they can use to pivot into the rest of your network. Fortunately, protecting yourself against exploit here is as simple as following a few basic principles: Don’t expose the management interface to the Internet (if at all possible) Ensure Self IP addresses have appropriate Port Lockdown settings Use strong passwords and definitely don’t leave the passwords at their defaults (fortunately, changing the passwords at installation is now mandated in recent versions) Monitor log files for suspicious activity (like unexpected logins) If you absolutely must expose the management interface to the internet, be sure to set appropriate ACLs to restrict access to specific IP ranges. All of which is documented in our Ask F5 article K13092 Protecting your (other) assets Now that you’ve got the BIG-IP sorted, you can turn your attention to how the BIG-IP(s) in your infrastructure can help protect your internal assets. As we discussed earlier malware can enter your network in a number of different ways, and a BIG-IP can help secure a number of those: Ensuring that your assets can only be accessed via the BIG-IP on ports you control immediately ensures you aren’t accidentally exposing SSH on your webserver, ruling out the possibility of an attacker simply brute-forcing credentials and uploading malware directly. The BIG-IP is (usually!) a full proxy right down to Layer 4, so any exploits or C2 channels that rely on quirks of TCP or utilise unusual header fields to transfer data will fail when the BIG-IP proxies and applies its own optimisations to the server-side flows Placing Advanced WAF in front of your internet-facing web services, configured with an appropriate policy, significantly reduces the possibility of an attacker exploiting a weakness in your web applications to upload a malicious payload (such as SQL Injection or shell command injection) The AFM IPS (in AFM 13.1.0 and later with an IPS subscription license) allows you to scan non-HTTP traffic for potentially malicious activity and take action BIG-IP APM allows you to secure access to potentially vulnerable protocols like RDP, better still, APM layered with Advanced WAF allows you to protect your VPN and secure endpoints against brute force attacks Of course, it is true to say that BIG-IP products are not best placed to stop a user from clicking on a malicious link in an email, but the points above at least help close some of the vectors that malware can enter your network! But, don’t stop there. I’m sure that as part of your day to day, you are on the look-out for IOCs to watch for that might indicate a problem within your network? If you are inspecting your outbound traffic (with BIG-IP AFM or SSLO) then it’s a snap to add rules to those products that will alert you and/or block outbound C2 communication attempts from compromised clients! A practical example – Cloud Snooper Cloud Snooper first appeared in the news in February 2020 billed as “malware that sneaks into your Linux servers”. Reading the Sophos white-paper (links to a non-F5 resource) it becomes clear that the researchers aren’t sure what the original infection vector is here; they know that the key marker is a specific rootkit present on the hosts, but not how that rootkit got there in the first place. Since there isn’t a specific initial infection vector, like most malware, we know that we need to think about everything from the previous two sections: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application The white-paper tells us that the rootkit dropped initially is a local command-and-control system rather than the ultimate exploit; its job is to receive incoming C2 messages and arbitrate between those and malware subsequently installed. It does that by sniffing all of the network traffic arriving at the compromised host and inspecting the TCP source port of every incoming packet. If the source port of the packet matches one of the ‘magic’ numbers hard-coded in the rootkit then it is treated as a command, otherwise it is simply ignored, and the host processes it as normal. So we've a third item to add to our list above: Pass inbound traffic through the BIG-IP in order to block incoming C2 messages destined for the rootkit on any potentially compromised or at-risk host Good news! With even the default configuration in place there’s a good chance that the BIG-IP won’t preserve the TCP source port between the client side and the server side, especially on a system passing a reasonable amount of traffic. But you can go one step further – simply change the “Source Port” option on the Virtual Server from “Preserve” to “Change” and the BIG-IP will always try to change the source port! The C2 messages might arrive at the Virtual Server, but by the time they leave and head to the pool member they’ll be on a new port and the rootkit will completely ignore them. Want to go one step further and ensure that C2 traffic never reaches the server at all? BIG-IP AFM has you covered; just create a Network Firewall rule to deny all traffic with a source port of 1010, 2020, 6060, 7070, 8080 or 9999, assign the rule to a Rule List, assign the Rule List to a Network Firewall Policy and then assign that Network Firewall policy to any Virtual Servers you’re concerned about or even to all traffic passing through the BIG-IP. As the original white-paper notes, regular clients don’t normally use source ports below 32768 so legitimate traffic shouldn’t be affected – but simply by assigning a logging profile with Network Firewall logging enabled will let you see what’s being denied by the rule. See the following chapters in the manual (BIG-IP Network Firewall: Policies and Implementations) for your version for more information: Configuring BIG-IP Network Firewall Policies Local Logging with the Network Firewall If you don’t have AFM, we’ve still got you covered. A simple iRule attached to a Virtual Server provides a simple way to block incoming Cloud Snooper C2 communications: when CLIENT_ACCEPTED { switch -- [TCP::client_port] { 1010 - 2020 - 6060 - 7070 - 8080 - 9999 { # Uncomment the following to log locally, which should be used for debugging purposes only # log local0. "Reject possible Cloud Snooper C2 message from [IP::client_addr] with source port [TCP::client_port]" reject } default { # Not a Cloud Snooper C2 connection, continue as normal } } } Of course, an iRule doesn’t come with the many advantages of AFM's Network Firewall Policies – it’s more computationally expensive, there isn’t simple access to remote logging compatible with leading SIEM systems, and it isn’t as easily administered if needs change. But, still, it’s there and it’s an excellent option – the F5 SIRT makes regular use of iRules in order to stop the bleeding and get customers back up and running in a pinch! Cloud Snooper Conclusion In brief, to protect against Cloud Snooper: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application Pass inbound traffic through the BIG-IP in order to block incoming C2 messages destined for the rootkit on any potentially compromised or at-risk host, setting the "Source Port" option to "Change" on the appropriate Virtual Server or use a Network Firewall ruleset or iRule to block incoming connections with a TCP source port of 1010, 2020, 6060, 7070, 8080 or 9999 Example 2 – Maze The Maze ransomware has been in the news regularly since January 2020 and shares a lot of traits with previously identified ransomware – infection is likely to be through vectors such as phishing, brute force access to network infrastructure like RDP or compromising internet-facing hosts. One thing that is new (but not unique) with Maze is what it does with the data once it’s in; it doesn’t just encrypt files, it syphons them off, so the target is not only being coerced into paying to regain access to their data, but also to avoid their data being exposed on the internet. So, everything we discussed in the previous sections applies equally well to Maze as Cloud Snooper or any other malware infection, with the only difference being we aren't looking for inbound C2 messages but rather outbound data exfiltration: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers Protect servers by placing them behind the BIG-IP and passing outbound traffic through inspection (AFM, SSLO) Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application It’s currently thought that Maze exfiltrates this data en-masse via outbound FTP connections, so protecting against that threat using F5 products is as simple as passing your outbound traffic through a Virtual Server and using Network Firewall policies or iRules to block all outbound FTP or to block or alert on outbound traffic destined to one of the published IOC IP addresses for Maze. Maze Conclusion In brief, to protect against Maze: Protect the BIG-IP by ensuring access to the management interface and control-plane is not exposed to attackers Protect servers by placing them behind the BIG-IP and passing outbound traffic through inspection (AFM, SSLO), blocking outbound FTP connections from any sensitive hosts to prevent Maze from exfiltrating data Pass inbound traffic through inspection appropriate to the protocols the servers are exposing to the internet (Advanced WAF, AFM) to reduce the potential for malware to be injected into the network through compromise of an internet-facing application Conclusion Admit it, you skipped right down to this section, didn’t you? It’s OK – we are all busy people, I understand! Here’s my five-bullet BIG-IP takeaway: Ensure you secure your BIG-IP first; failure to do so renders anything else you do moot. Follow the steps in K13092! Simply placing your servers behind a BIG-IP makes many attacks significantly harder to pull off, by virtue of the BIG-IPs full-proxy architecture If it serves HTTP, put Advanced WAF in front of it Put AFM in front of everything, including your internal clients accessing the internet! If you can’t use one of the products, iRules are your friend and can help you stop inbound and outbound threats And, finally, my general advice five-bullet takeaway – things that apply equally to F5 products and general-purpose computing: Never expose the management interface of anything directly to the internet; if you must, use ACLs to restrict access Visibility is king; you need visibility of traffic in and out of your network to watch for IOCs. If you can’t use F5 products (Advanced WAF, AFM and SSLO have excellent reporting capabilities) then use something and pipe all that data into an SIEM Patch in a timely manner Don’t use weak, insecure or previously leaked passwords Did I mention never exposing the management interface to the internet yet? Those ten things, the first five of which are covered in more detail in the article above, will go a long way to ensuring the security of your network and your assets. Of course, the BIG-IP and good security practices can't obviate the need for good endpoint security, MFA for your users and so on, but you'll at least have squashed a significant amount of attack surface.
VBKlip Banking Trojan Goes Man-In-The-Browser
VBKlip Banking Trojan Goes Man-In-The-Browser VBKlip malware was first introduced by Cert Polska back in 2013. It started out as a simple yet effective threat, targeting Polish on-line banking users. Its first reincarnation intercepted clipboard data. Once a user used the “copy-paste” Windows functionality, the malware changed the data being copied. It looked forIBAN(International Bank Account Number)string format in the copied data and swapped it with its own hard codedIBAN. Recently, my colleaguePavel Asinovsky and I witnessed a significant evolution in the malware, as it followed the footsteps of well-known financial threats such Zeus and Neverquest by resorting to man-in-the-browser techniques. The current version’s infection scheme starts with a downloader which downloads two files: wmc.exe and .windows.sys (which is a dll) to %programdata% as described in Cert Polska's blog. The malware can survive a reboot thanks to the scheduled task it creates in windows task scheduler. This method is quite uncommon as most malware use runkeys in the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) in order to remain persistent. After the malicious .windows.sys dll is loaded into memory, it tries to communicate with several domains. The expected payload being another executable which is responsible for the core functionality. Each component is downloaded separately and has a different task in the whole control flow of the fraud. By dividing the operation into several modules which depend on Command and Control server communication in order to download the next component, the fraudsters make the attack harder to analyze as it is harder to obtain all of the components involved in the fraud. The core module starts by creating a thread whose sole purpose is to check the running process list every 3 seconds. Each process name is compared to a hard coded list of browser names, while the targeted browsers are the three major browsers: Internet Explorer, Firefox and Chrome. Once the malware identifies a process of interest, it writes its malicious code into the process' memory and executes it. The malware uses a mutex of the format __NTDLL_CORE__<processID> for synchronization. This is a significant improvement from its previous version that lacks synchronization and could only handle one running browser process. Now it swaps the IBAN in all running browser processes thanks to the mutex and the injection. It only injects to processes that don't have the mutex, and this mutex is created in every newly injected browser process. The injected code hooks several key functions. It hooks communication related functions in order to intercept the IBAN and swap it before the request leaves the browser. The browser functions are: HttpSendRequestA HttpSendRequestW InternetWriteFile PR_Write IBAN swapping is done in two steps. First, the Host header is compared to a hard-coded bank name. If the match is successful, the hard-coded <CreditAccount> HTML tag is searched throughout the request body and the content is swapped if it matches the IBAN pattern. Otherwise, it will scan the entire request body for the IBAN format and swap it in every instance. The fact that a backup plan is used in case the bank name does not match, shows that this features is probably still being tested in the field. This feature bares great resemblance to Zeus “man-in-the-browser” mechanism where bank names are matched against a configuration, once the request is sent by the victim. Although this approach to committing fraudulent transactions is pretty simplistic in comparison with its well-known counterparts in the wild, it is nonetheless successful, and it is safe to assume that the malware’s evolution has yet to reach its final form. Sample MD5: A86BD976CE683C58937E47E13D3EB448
Is "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.Encrypted malware vs. F5's full proxy architecture
Everyone knows that malware is a huge problem, and several recent studies (including one by our very own F5 Labs research center) have shown that nearly half of all malware is now encrypted. So, if all this malware is encrypted, then how do you go about finding it and stopping it if you can't even read it? This problem is critical to the security of web applications today and will be even more critical in the future as encrypted Internet traffic becomes more pervasive. There are two basic scenarios in which to categorize this situation: 1) inbound encrypted malware, and 2) outbound encrypted malware. What I'm calling "inbound" encrypted malware is when an attacker sends malicious traffic to your webserver in order to infect the server and/or a user accessing that server. The "outbound" encrypted malware is when a user in your organization visits an infected website and ultimately infects his/her computer with the malware from that infected site. Admittedly, the "outbound" encrypted malware situation is a huge problem and needs to be addressed, but for the purposes of this article, we will look at the "inbound" malware problem. When you configure a secure webserver (one that uses encryption), you have to generate and store the keys that are used for encryption. Those keys can be stored on the webserver itself, or they can be stored on a separate proxy device. Many organizations choose to use a proxy device because it is typically custom-built to handle cryptography operations much faster than standard webservers. This "handing off" of the crypto keys is called SSL offload. F5's BIG-IP is the best in the business at this. I won't go into all the marketing chatter about it, but suffice it to say, the BIG-IP is really, really good and fast at this. The SSL offload not only provides a faster encryption experience, but it also allows for a strategic point of control over your web traffic. The F5 BIG-IP also employs a full proxy architecture that allows full visibility of every single request to your web applications. When a user sends an HTTP request to your web application, the BIG-IP accepts that request on behalf of your webserver (in fact, the end user thinks he is talking directly to the webserver but he's really talking to the BIG-IP) and then tears down the request from layer 7 all the way down to layer 1 and then rebuilds the connection from layer 1 all the way back up to layer 7 before sending it on to the backend webserver. This is called a "full proxy" architecture because it establishes two completely independent connections...one with the client and one with the backend server. The reason this is important is that it allows the BIG-IP to inspect every single part of that request at every single layer to make sure it is legitimate traffic. If it's malware, the BIG-IP can reject it before it ever gets to the webserver. Check out the following diagram that shows the flow of the full proxy architecture: The full proxy allows for many other cool things as well (like using iRules to modify traffic in realtime at wire speed), but for the purposes of this discussion, it allows for the complete inspection of your traffic to ensure malware never reaches your webservers. By offloading SSL/TLS encryption onto the BIG-IP, you move the encryption point away from your webservers and onto the BIG-IP. From a BIG-IP configuration standpoint, you do this via the SSL profile where you actually load the encryption keys, certificates, etc. You can actually have one unique profile for the client-side connection and another, separate one for the server-side connection. This is cool as well because you can use two totally different encryption strengths, keys, etc for each side of the connection. Because the BIG-IP holds the encryption keys, it will decrypt all the web traffic and then have the ability to inspect the clear text traffic. Prior to decryption, there would be no way to feasibly inspect the traffic. When you offload all your SSL/TLS traffic onto the BIG-IP and let it inspect each request at every layer, you can free up your webservers to do what they do best...serve up those amazing web applications that we all love! Also, when an attacker sends encrypted malware to your webservers, the BIG-IP will decrypt it and stop it before it ever reaches your servers. Related Resources: SSL Ciphers Supported on BIG-IP SSL Profiles on BIG-IP (10-part article series)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.The Icebox Cometh
Will the Internet of Things turn homes into a House of Cards? Our homes are being invaded...but not with critters that you'd call an exterminator for. Last summer I wrote Hackable Homes about the potential risks of smart homes, smart cars and vulnerabilities of just about any-'thing' connected to the internet. (I know, everyone loves a bragger) Many of the many2014 predictions included the internet of things as a breakthrough technology? (trend?) for the coming year. Just a couple weeks ago, famed security expert Bruce Schneier wrote about how the IoT (yes, it already has it's own 3 letter acronym) is wildly insecure and often unpatchable in this Wired article. And Google just bought Nest Labs, a home automation company that builds sensor-driven, WiFi enabled thermostats and smoke detectors. So when will the first refrigerator botnet launch? It already has. Last week, Internet security firm Proofpoint said the bad guys have already hijacked up to 100,000 devices in the Internet of Things and used them to launch malware attacks. The first cyber attack using the Internet of Things, particularly home appliance botnets. This attack included everything from routers to smart televisions to at least one refrigerator. Yes, The Icebox! As criminals have now uncovered, the IoT might be a whole lot easier to infiltrate than typical PCs, laptops or tablets. During the attack, there were a series of malicious emails sent in 100,000 lots about 3 times a day from December 23 through January 6. they found that over 25% of the volume was sent by things that were not conventional laptops, desktops or mobile devices. Instead, the emails were sent by everyday consumer gadgets such as compromised home-networking routers, connected multi-media centers, televisions and that one refrigerator. These devices were openly available primarily due to the fact that they still had default passwords in place. If people don't update their home router passwords or even update the software, how are they going to do it for the 50+ (give or take) appliances they have in their home? Heck, some people have difficulty setting the auto-brew start time for the coffee pot, can you imagine the conversations in the future? 'What's the toaster's password? I need to change the bagel setting!' Or 'Oh no! Overnight a hacker replaced my fine Kona blend with some decaf tea!' Come on. Play along! I know you got one you just want to blurt out! I understand this is where our society/technology/lives are going and I really like the ability to see home security cameras over the internet but part of me feels, is it really necessary to have my fridge, toaster, blender and toilet connected to the internet? Maybe the fridge alerts you when something buried in back is molding. I partially get the thermostats and smart energy things but I can currently program my thermostat for temperature adjustments without an internet connection. I push a few buttons and done. Plus I don't have to worry about someone firing up my furnace in the middle of July. We have multiple locks on our doors, alarm systems for our dwellings, security cameras for our perimeter, dogs under the roof and weapons ready yet none of that will matter if the digital locks for our 'things' are made of dumpling dough. Speaking of dumplings, the smart-steamer just texted me with a link to see the live feed of the dim sum cooking - from inside the pot! My mind just texted my tummy to get ready. ps Related: Proofpoint Uncovers Internet of Things (IoT) Cyberattack The Internet of Things Is Wildly Insecure — And Often Unpatchable For The First Time, Hackers Have Used A Refrigerator To Attack Businesses The Internet Of Things Has Been Hacked, And It's Turning Nasty Smart refrigerators and TVs hacked to send out spam, according to a new report Here's What It Looks Like When A 'Smart Toilet' Gets Hacked Bricks (Thru the Window) and Mortar (Rounds) Technorati Tags: IoT,internet of things,botnet,malware,household,silva,attacks Connect with Peter: Connect with F5:The Dangerous Game of DNS
The Domain Name Service (DNS) is one of the most important components in networking infrastructure, enabling users and services to access applications by translating URLs (names) into IP addresses (numbers). Because every icon and URL and all embedded content on a website requires a DNS lookup, loading complex sites necessitates hundreds of DNS queries. And because of that, DNS is a precious target and only lags behind http as the most targeted protocol. DDoS-ing DNS is an effective way to make the service unavailable. As the flood of malicious DNS requests hit the infrastructure, the service can become unresponsive if there is not enough capacity. Organizations can add more servers or turn to their cloud-based security provider for help. One of the strategies cloud-based security providers use to shield DNS is DNS redirection. Cloud providers will divert incoming traffic to their own infrastructure, which is resilient enough to detect and absorb these attacks. The success of this strategy however depends on how well the website's original IP address can be shielded. If the bad guy can find that IP address, then they can get around the protection. So is DNS redirection effective? Researchers decided to find out. Scientists from KU Leuven in Belgium built a tool called CLOUDPIERCER, which automatically tries to retrieve websites' original IP address, including the use of unprotected subdomains. Almost 18,000 websites, protected by five different providers, were part to the team's DNS redirection vulnerability tests. In more than 70% of the cases, CLOUDPIERCER was able to retrieve the website's original IP address - the precise info needed to launch a successful attack. Researchers did share their findings with those cloud-based providers and have made CLOUDPIERCER freely available for organizations to test their own DNS infrastructure. In another DNS scam, a new version of the NewPosThings PoS (point of sale, not…) malware is using DNS rather than http/https/ftp to extract data from infected PoS terminals. This is an interesting twist since most security solutions monitor http/https traffic for suspicious activity. Anti-virus doesn’t necessarily watch DNS and admins cannot simply turn off DNS since they need it to resolve hostnames and domains. Seems like a clear shot. The newest version of NewPoSThings is nicknamed MULTIGRAIN and it only targets (and infects) one specific type of PoS platform: The multi.exe process, specific to a popular electronic draft capture software package. If the multi.exe process is not found the malware moves on. Once inside, the malware waits for the Track 2 credit card data and once it has the data, it encrypts and encodes it before sending to the bad guy via a DNS query. The use of DNS for data exfiltration on PoS devices is not new and shows not only how attackers can adjust to different environments but also, that organizations need to be more aware of their DNS traffic for potential anomalies. BIG-IP could also help in both instances. For the redirection issue, BIG-IP or our Silverline Managed Service offers Proxy mode with DNS redirection. With Routed Mode, we offer BGP to Silverline then Generic Routing Encapsulation (GRE) tunnels or L2VPN back to the customer to mask the original IP address. For the PoS malware, BIG-IP can utilize a DNS response policy zone (RPZ) as a firewall or outbound domain filtering mechanism. An RPZ is a zone that contains a list of known malicious Internet domains. The list includes a resource record set (RRset) for each malicious domain and each RRset includes the names of the malicious domain and any subdomains of the domain. When the BIG-IP system receives a DNS query for a domain that is on the malicious domain list of the RPZ, the system responds in one of two ways based on your configuration. You can configure the system to return an NXDOMAIN record that indicates that the domain does not exist or return a response that directs the user to a walled garden. BIG-IP returns NXDOMAIN response to DNS query for malicious domain BIG-IP forwards DNS query for malicious domain to walled garden DNS is one of those technologies that is so crucial for a functioning internet, especially for human interaction. Yet is often overlooked or seems to only get attention when things are broken. Maybe take a gander today to make sure your DNS infrastructure is secure, scalable and ready to answer each and every query. Ignoring DNS can have grave consequences. ps Related: "Multigrain" PoS Malware Exfiltrates Card Data Over DNS NewPosThings Has New PoS Things New point-of-sale malware Multigrain steals card data over DNS Commonly used strategy for website protection might not work Cloudpiercer Discovery Tool Application Layer DNS Firewall
Domain name holders hit with personalized, malware-laden suspension notices
This according to Zeljka Zorz, HNS Managing Editor from Help Net Security. In his article, Zeljka mention that new email spam campaign has been spotted targeting domain name holders, trying to trick them into downloading malware on their systems. The email is likely to fool some recipients, as it contains the valid domain registration and the recipient's full name, which the attackers must have harvested online, via the “whois” query. The sender's email address is also spoofed to make it look like the sender is the domain registrar. Those who get fooled and download and execute the file linked in the email will get saddled with malware - most likely a Trojan downloader, which will then proceed to download additional malware. Below is the spam e-mail that was sent: Subject: [Domain name] Suspension Notice Dear Sir/Madam, The following domain names have been suspended for violation of the Melbourne IT Ltd Abuse Policy: Domain Name: [domain name] Registrar: Melbourne IT Ltd Registrant Name: [Registrant name matching whois] Multiple warnings were sent by Melbourne IT Ltd Spam and Abuse Department to give you an opportunity to address the complaints we have received. We did not receive a reply from you to these email warnings so we then attempted to contact you via telephone. We had no choice but to suspend your domain name when you did not respond to our attempts to contact you. Click here [LINK] and download a copy of complaints we have received. Please contact us by email at mailto:abuse@melbourneit.com.au for additional information regarding this notification. Sincerely, Melbourne IT Ltd Spam and Abuse Department Abuse Department Hotline: 480-124-0101 According to the article, the most targeted registrars are Melbourne IT and Dynadot that already notified their clients of this campaign. In their official notification Dynadot states that “We have recently become aware of fake abuse notifications being sent out to our customers. The abuse messages look like they are being sent from our abuse@dynadot.com email; however, these messages are NOT being sent from us and should be disregarded. If you receive one of these emails or an email that you think may not be from us, do not click on any links, reply directly to the email, or call the number listed in the email". To read Melbourne IT public announcement click here. F5 SOC is familiar with this spam campaign as well with many others that come and go almost every day. This attack vector is very common in the hacktivists communities that using Social Engineering to lure victims into opening links and/or attachments in e-mail messages in order to broader their botnet pools and inititate DDoS attacks, money transfer, identity theft and more. On a day to day basis, F5 mitigates online identity theft by preventing phishing, malware, and pharming attacks in real time with advanced encryption and identification mechanisms enabling financial organizations working online to gain control over areas that were once virtually unreachable and indefensible, and to neutralize local threats found on customers’ personal computers, without requiring the installation of software on the end user side. If you would like to learn more about F5 fraud protection, read the WebSafe datasheet as well as the MobileSafe datasheet. To learn more about F5 Security Operation Centers, read the F5 SOC datasheet. Click here to read the original article by Help Net Security.Lightboard Lessons: What is DDoS?
Over the last quarter, there were approximately 500 DDoS attacks daily around the world with some lasting as long as 300 hours. In this Lightboard Lesson I light up some #basics about DoS and DDoS attacks. ps Related: DDoS attacks in Q2 2017 DDoS attack - Distributed Denial of Service DDoS Attacks 101: Types, targets, and motivations Getting Started with BIG-IP Application Security Manager (ASM) Getting Started with BIG-IP Advanced Firewall Manager (AFM) Securing Apps with F5 Solutions Configuring BIG-IP Application Security Manager (ASM) Configuring BIG-IP Advanced Firewall Manager (AFM)
