Proactive Bot Defense Using BIG-IP ASM
Bots are everywhere. Some of them are nice, desirable bots; but many of them are not. By definition, a bot is a software application that runs automated tasks (scripts) over the Internet. The desirable ones include examples like Google bots crawling your website so that Google can know what information your site contains and then display your site’s URL in their list of search results. Most people want this…many people even pay huge money to make sure their site is listed in the top results on Google. Other bots, though, are not so good. The more malicious bots are used to attack targets…typically via a Distributed Denial of Service (DDoS) attack. When many bots are controlled by a central bot controller, they form a “botnet” and can be used to send massive amounts of DDoS traffic at a single target. We have seen malicious bot behavior many times, but a recent popular botnet attack was seen by the Mirai botnet against several targets. Let’s just say you didn’t want to be on the receiving end of that attack. Needless to say, bot activity is something that needs to be monitored and controlled. On one hand, you want the good bots to access your site, but on the other hand you want the bad ones to stay away. The question is, “how do you know the difference?” Great question. And the unfortunate answer for many organizations is: “I have no idea.” The other harsh reality, by the way, is that many organizations have no idea that they have a bot problem at all…yet they have a big one. Well, the BIG-IP ASM includes several bot-defending features, and this article will outline a feature called “Proactive Bot Defense." While the BIG-IP ASM has worked to detect bots for quite sometime now, it’s important to know that it has also been steadily updated to include more automatic defense features. The BIG-IP ASM uses many different approaches to defending against bad bots, to include things like: bot signatures, transactions-per-second based detection, stress-based detection, heavy URL protection, and CAPTCHA challenges. All of those approaches are manual in the sense that they require the BIG-IP ASM administrator to configure various settings in order to tune the defense against bad bots. However, proactive bot defense automatically detects and prevents bad bots from accessing your web application(s). Here’s a picture of how it works: When a browser (user) initially sends a request to your web application, the BIG-IP ASM sees the request and responds with an injected JavaScript challenge for the browser to complete The JavaScript challenge is then placed in the browser The browser either responds to the challenge and resends the request or it doesn’t. If the JavaScript challenge is not sent back, the request is dropped (this indicates bot activity). Legitimate browsers will answer the challenge correctly and resend the request with a valid cookie. When this cookie is sent to the BIG-IP ASM, it is signed, time stamped, and finger printed. After all that validation happens, the request is ultimately sent to the server for processing. After the initial request is finally sent to the server for processing, any future requests from that browser can bypass the JavaScript challenge because of the valid, signed, time stamped cookie the BIG-IP ASM holds for that valid browser. The BIG-IP ASM steps through all these actions in order to protect your web application from getting attacked by malicious bots. In addition to the JavaScript challenge, the ASM also automatically enables bot signatures and blocks bots that are known to be malicious. When you add up all these bot defense measures, you get what we call “Proactive Bot Defense.” BIG-IP Configuration Many features of the BIG-IP ASM require you to build a security policy, but Proactive Bot Defense does not. It is configured and turned on in the DoS profile. To access the DoS profile from the configuration screen, navigate to Security > DoS Protection > DoS Profiles. Then, you will see the list of DoS profiles. Either click the name of an existing DoS profile, or create a new one in order to configure the DoS profile. Also, on the left menu, under Application Security, click General Settings, and make sure that Application Security is enabled. Once you click Proactive Bot Defense, you will be able to configure the settings for the operating mode of the profile. You will have three options to choose when Proactive Bot Defense is implemented: During Attack: This will checks all traffic during a DoS attack and prevent detected attacks from escalating. DoS attacks are detected using other features of DoS protection in the ASM like Transaction Per Second (TPS) based anomalies (measures if a browser is sending too many requests in a given timeframe) and Stress-Based anomaly detection (measures whether the web server is “stressed” from serving up too much data in a given timeframe). Always: This will check all traffic at all times and prevent DoS attacks from starting. Off: The system does not perform proactive bot defense. CORS Cross-Origin Resource Sharing (CORS) is an HTML5 feature that enables one website to access the resources of another website using JavaScript within the browser. Specifically, these requests come from AJAX or CSS.If you enable Proactive Bot Defense and your website uses CORS, you should add the CORS URLs to the proactive bot URL whitelist. Related to this, but slightly different, is the idea of "cross-domain requests." Sometimesaweb application might need to share resources with another external website that is hosted on a different domain. For example, if you browse to www.yahoo.com, you might notice that the images and CSS arrive from another domain like www.yimg.com. Cross-domain requests are requests with different domains in the Host and Referrer headers. Because this is a different domain, the cookie used to verify the client does not come with the request, and the request could be blocked. You can configure thisbehavior by specifying the conditions that allow or denya foreign web application access to your web applicationafter making a cross-domain request. This feature is calledcross-domain request enforcement. You enable cross-domain request enforcement as part of the Allowed URL properties within a security policy. Then you can specify which domains can access the response generated by requesting this URL (the “resource”), and also configure how to overwrite CORS response headers that are returned by the web server. There are three options for configuring cross-domain requests: Allow all requests: This setting is the most permissive of the three and itallows requests arriving to a non-HTML URL referred by a different domain and without a valid cookie if they pass a simple challenge. The ASM sends a challenge that tests basic browser capabilities, such as HTTP redirects and cookies. Allow configured domains; validate in bulk: This setting allows requests to other related internal or external domains that are configured in this section and validates the related domains in advance. The requests to related site domains must include a valid cookie from one of the site domains; the external domains are allowed if they pass a simple challenge. Choose this option if your web site does not use many domains, and keep in mind that it is a good idea to include them all in the lists below. Allow configured domains; validate upon request: This setting allows requests to other related internal or external domains that are configured in this section. The requests to related site domains must include a valid cookie from the main domain (in the list below); the external domains are allowed if they pass a simple challenge. Choose this option if your web site uses many domains, and list one main domain in the list below. If you selected one of the two Allow configured domains options, you will need to add Related Site Domains that are part of your web site, and Related External Domains that are allowed to link to resources in your web site. You can type these URLs in the form /index.html (wildcards are supported). While these options are great for cross-domain requests, they do nothelp with AJAXif "Access-Control-Allow-Credentials" was not set by the client-side code of the application. To solve the AJAX case, the administrator could choose from one of three options. They are: Whitelist the AJAX URLs Add allow-credentials in the client-side code of the application Use dosl7.cors_ajax_urls / dosl7.cors_font_urls DB variables. The database variables mentioned in option #3 above are as follows: dosl7.cors_font_urls URLs (or wildcards) of CSS that use@font-face to request fonts from another domain. Both the CSS and the FONT URLs are required here. dosl7.cors_ajax_urls URLs (or wildcards) of HTML pages that use AJAX to send requests to other domains. Only the HTML URL is needed here, and not the URL of the CORS request. Requests to these URLs get redirected, and the TSPD_101 cookie gets added to the query string. For the HTML URLs, this is displayed in the address bar of the browser. When the requests are sent from the BIG-IP to the back-end server, the additional query string gets stripped off. Example @font-face CSS in host1.com is requesting a font in host2.com: @font-face { font-family: myfont; src: url('http://host2.com/t/cors/font/font.otf'); } h1 { font-family: myfont; color: maroon; } To prevent the font request from being blocked, define using this command: tmsh modify sys db dosl7.cors_font_urls value /t/cors/font/style.css,/t/cors/font/font.otf AJAX var xhr = new XMLHttpRequest(); xhr.open("GET", "http://host2.com/t/cors/ajax/data.txt"); xhr.send(); To prevent the data.txt request from being blocked, define the HTML that contains the JavaScript using the following command: tmsh modify sys db dosl7.cors_ajax_urls value /t/cors/ajax/,/t/cors/ajax/index.html One more thing to note about AJAX requests: the cookie thatis set is valid for 10 minutes by default (5 initial minutes plus the configured Grace Period). Single Page Applications will send AJAX requests well past this cookie expiration period and these requests will be blocked. In BIG-IP version 13.0.0 and up, there is support for Single Page Applications. You can simply check thecheckbox in the General section of the dos profile. Enabling this option causes JavaScript to be injected into every HTML response, and allows supporting these requests. Grace Period Another configuration item to consider is what’s called the “Grace Period.” This is the amount of time the BIG-IP ASM waits before it begins bot detection. The default value is 300 seconds, but this can be changed in the DoS profile settings along with the other items listed above. The Grace Period allows web pages (including complex pages with images, JavaScript, CSS, etc) the time to be recognized as non-bots, receive a signed cookie, and completely load without unnecessarily dropping requests. The Grace Period begins after the signed cookie is renewed, a change is made to the configuration, or after proactive bot defense starts as a result of a detected DoS attack. During the Grace Period, the BIG-IP ASM will not block anything, so be sure to set this value as low as possible while still allowing enough time for a complete page to load. CAPTCHA The last thing I’ll mention is that, by default, the ASM blocks requests from highly suspicious browsers and displays a default CAPTCHA (or visual character recognition) challenge to browsers that could be suspicious. You can change the Block requests from suspicious browsers setting by clearing either Block Suspicious Browsers or Use CAPTCHA. There are many other bot defense mechanisms available in the BIG-IP ASM, and other articles will cover those, but I hope this article has helped shed some light on the details of Proactive Bot Defense. So, get out there and turn this thing on…it’s easy and it provides automatic protection!Orchestrated Infrastructure Security - Guided Configuration
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring SSL Orchestrator to decrypt inbound SSL and pass the decrypted content to F5 Advanced WAF and Protocol Inspection (IPS) with AFM for enhanced protection from threats.It covers the configuration of the SSL Orchestrator Topology, Services and more on an F5 BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. In this article we will walk you through the SSL Orchestrator Guided Configuration which covers the following: Inbound L2 Topology creation Certificate and Key used for SSL Decryption Adding the Advanced WAF and AFM devices Creating a Security Policy Creating an Interception Policy SSL Orchestrator Guided Configuration From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration from the menu on the left. Note: There are Required Configuration options on the right you may need to configure.A Route is not needed when SSL Orchestrator is deployed in Layer 2 mode. The Configuration screen presents all of the configuration options that are available.Scroll to the bottom of the page and click Next. Give the Topology a name, InboundAppProtection in this example.You can optionally configure the Protocol and IP Family you want the Topology to support.We’re using the default of TCP and IPv4.Select L2 Inbound and click Save & Next. Configure the Certificate Key Chain by clicking the Pencil icon on the right. Choose the correct Certificate and Key from the drop menu.In this example we use subrsa.f5labs.com for the Certificate and Key.Click Done. There are Server-side SSL settings that you can optionally configure.Click Save & Next. On the next screen click Add Service. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, Advanced_WAF in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the Advanced WAF devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_WAF1 and ingress_WAF1 in this example.Select the interfaces connected to the first WAF device, 4.1 and 4.2 in this example. Then click Done. Repeat this process for the 2 nd Advanced WAF device using interfaces 4.3 and 4.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 4.1 and 4.2 are connected to Advanced WAF1 interfaces 2.1 and 2.2.SSL Orchestrator interfaces 4.3 and 4.4 are connected to Advanced WAF2 interfaces 2.3 and 2.4. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Add Service to add the AFM devices. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, AFM in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the AFM devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_AFM1 and ingress_AFM1 in this example.Select the interfaces connected to the first AFM device, 5.1 and 5.2 in this example.Then click Done. Repeat this process for the 2 nd AFM device using interfaces 5.3 and 5.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 5.1 and 5.2 are connected to AFM1 interfaces 5.0 and 6.0.SSL Orchestrator interfaces 5.3 and 5.4 are connected to AFM2 interfaces 5.0 and 6.0. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Save & Next at the bottom. Click Add to create the Service Chain. Give it a name, Inbound_Protect1 in this example.Select ssloS_AFM and ssloS_Advanced_WAF Services then click the arrow to move them to the right.Click Save. Note: It is recommended that AFM be placed first in the Service Chain Order.That way intrusion attempts are detected and blocked before they ever get to the Advanced WAF.This saves resources on the Advanced WAFs because they don’t have to process any of the attempted intrusion connections. Click Save & Next. For the Security Policy click the Pencil icon on the lower right to edit the rule. Set the Service Chain to the one created previously.Click OK. Click Save & Next at the bottom. For the Interception Rule, define the Destination Address or subnet of the application servers you wish to protect.In this example the application servers are all in the 10.4.1.0/24 subnet.Specify the correct port, typically 443. For the Ingress Network select the VLAN(s) that will be receiving traffic from external users, Direct_all in this example.Set the L7 Profile to http.Click Save & Next. Make any changes to the Log Settings if needed.Click Save & Next. On the Summary screen you can review and change any of the settings.Click Deploy when ready. You should get a Success message. If you receive an error you will need to go back into the configuration to resolve it.If successful, you should see a screen like this: Notice the Service Health status is indicated by the small green circle. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to create a Topology, select the certificate and key used for SSL Decryption, add the Advanced WAF and AFM devices, create a Security Policy and an Interception Policy. Next Steps Click Next to proceed to the next article in the series.
Securing APIs with BigIP
Introduction API servers respond to requests using the HTTP protocol, much like Web Servers. Therefore, API servers are susceptible to HTTP attacks in ways similar to Web Servers. Previous articles covered how to publish an API using the NGINX platform as an API management gateway. These APIs are still exposed to web attacks and defensive mechanisms are needed to defend the API against web attacks, denial of service, and Bots.The diagram below shows all the layers needed to deliver and defend APIs. BIGIP provides the protection and NGINX Plus provides API management. Picture 1. This article covers Advanced Web Application Firewall (AWAF) to protect against HTTP vulnerabilities Unified Bot Defense to protect against bots Behavioral Anomaly DoS Defense to prevent DoS attacks As shown in Picture 1, above BIG-IP goes in front of the API management gateway as an additional security gateway. The beauty of this approach is that BIG-IP can be initially deployed on the side while the API is being delivered to users through the NGINX Plus gateway directly. Once BIG-IP is configured to forward good requests to NGINX Plus and security policies are in place, BIG-IP can be brought into the traffic flow by simply changing the DNS records for "prod.httpbin.internet.lab" to point to BIG-IP instead of NGINX Plus. From this point on all calls will automatically arrive at BIG-IP for inspection and only those that pass all verifications will be forwarded to the next layer. Configuring Data Path Data path configuration for this use case is pretty common for BIG-IP which is historically a load balancer. It includes: Virtual Server (listens for API calls) SSL profile (defines SSL settings) SSL certificate and key (cryptographically identifies virtual server) Pool (destination for passed calls) Picture below shows how all of the configuration pieces work together. Picture 3. At first upload server certificate and key Setup SSL profile to use a certificate from the previous step Finally, create a virtual server and a pool to accept API calls and forward them to the backend From this point IG-IP accepts all requests which go to "prod.httpbin.secured-internet.lab" hostname and forwards them to API management gateway powered by NGINX Plus. Setting up WAF policy As you may already know every API starts from the OpenAPI file which describes all available endpoints, parameters, authentication methods, etc. This file contains all details related to API definition and it is widely used by most tools including F5's WAF for self-configuration. Imported OpenAPI file automatically configures policy with all API specific parameters as a list of allowed URLs, parameters, methods, and so on. Therefore WAF configuration narrows down to importing OpenAPI file and using policy template for API security. Create a policy Specify policy name, template, swagger file, virtual server and logging profile. API security template pre-configures WAF policy with all necessary violations and signatures to protect API backend. OpenAPI file introduces application-specific configuration to a policy as a list of allowed URLs, parameters, and methods. That is it. WAF policy is configured and assigned to the virtual server. Now we can test that only legitimate requests to allowed resources go through. For example request to URL which does not exist in the policy will be blocked: ubuntu@ip-10-1-1-7:~$ http -v https://prod.httpbin.secured-internet.lab/urldoesntexist GET /urldoesntexist HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate Connection: keep-alive Host: prod.httpbin.secured-internet.lab User-Agent: HTTPie/0.9.2 HTTP/1.1 403 Forbidden Cache-Control: no-cache Connection: close Content-Length: 38 Content-Type: application/json; charset=utf-8 Pragma: no-cache { "supportID": "1656927099224588298" } Request with SQL injection also blocked: Configuring Bot Defense Starting from BIG-IP release 14.1 proactive bot defense, web scraping, and bot detection features are combined under Bot Defense profile. Therefore current bot defense forms a unified tool to prevent all types of bots from accessing your web asset. Bot detection and mitigation mechanisms heavily rely on signatures and javascript (JS) based challenges. JS challenges run in a client browser and help to identify client type/malicious activities or apply mitigation by injecting a CAPTCHA or slowing down a client by making a browser perform a heavy calculation. Since this article is focused on protecting APIs it is important to note that JS challenges need to be used with caution in this case. Keep in mind that robots might be legitimate users for an API. However, robots similar to bots can not execute javascript. So when a robot receives JS it considers JS as API response. Such response does not align with what a robot expects and the application may break. If you know an API is serving automated processes avoid the use of JS-based challenges or test every JS-based feature in the staging environment first. Configuration to detect and handle many different types of Bots can be simplified by using any of the three pre-configured security modes: Relaxed (Challenge free, mitigates only 100% bad bots based on signatures ) Balanced (Let suspicious clients prove good behavior by executing JS challenges or solving CAPTCHA) Strict (Blocks all kinds of bots, verifies browsers, and collects device id from all clients) It is best to start with the relaxed template and tighten up the configuration as familiarity grows with the traffic that the API endpoints see. Once the profile is created assign it to the same virtual server at "Local Traffic ›› Virtual Servers : Virtual Server List ›› prod.httpbin.secured-internet.lab ›› Security" page. Such configuration performs bot detection based on data that is available in requests such as URL, user-agent, or header order. This mode is safe for all kinds of API users (browser-based or code-based robots) and you can see transaction outcome on "Security ›› Event Logs : Bot Defense : Bot Requests" page. If there are false positives you can adjust bot status or create a new trusted one for your robots through "Security ›› Bot Defense : Bot Signatures : Bot Signatures List". Setting Up DDoS Defense WAF and BOT defenses can detect requests with attack signatures or requests that are generated by malicious clients. However, attackers can send attacks composed of legitimate requests at a high scale, that can bring down an API endpoint. The following features present in the BIG-IP can be used to defeat Denial of Service attacks against API endpoints. Transaction per second (TPS) Based DoS Defense Stress Based DoS Defense Behavioral Anomaly Based DoS Defense Eviction Policies TPS-based DoS defense is the most straightforward protection mechanism. In this mode, BigIP measures requests rate for parameters such as Source IP, URL, Site, etc. In case the per minute rate becomes higher than the configured threshold then the attack gets triggered, and selected mitigation modes are applied to ‘all’ requests identified by the parameter. The stress-based mode works similarly to TPS, but instead of applying mitigation right after the threshold is crossed it only mitigates when the protected asset is under stress. This approach significantly reduces false positives. Behavioral anomaly detection (BADoS) mode offers the most advanced security and accuracy. This mode does not require the administrator to perform any configuration, other than turning the feature on. A machine learning algorithm is used to detect whether the protected asset is under attack or not. Another machine learning algorithm is used to baseline the traffic in peacetime. When the ‘attack detector algorithm’ identifies that the protected asset is under stress and non-responsive, then the second algorithm stops learning and looks for anomalies. Signatures matching these anomalies are automatically created. Anomalies discovered during attack time are likely nefarious and are eliminated from the traffic by application of dynamically discovered signatures. BADoS will automatically build a good traffic baseline, detect anomalies and stop them if the API endpoint is under stress. Conclusion F5 offers a multi-layered solution for protecting APIs, which is easy to configure.Please connect with me via comments and keep an eye on more articles in this series. Good luck!
AppSec Made Easy: Proactive Bot Defense
Learn how to use the F5 Advanced Web Application Firewall to easily protect your applications against bots. Bots can be used as tools for a variety of attacks such as DoS, credential stuffing and brute force, or web scraping. See the entire AppSec Made Easy series.AppSec Made Easy: Anti-Bot for Mobile APIs
Learn how to use the F5 Advanced Web Application Firewall to easily lock down your applications so that bots can’t attack your mobile APIs. Integrating an SDK can be challenging, but this video will show you the quick way to add anti-bot and other protections directly into your mobile app. See the entire AppSec Made Easy series.Mazar Bot Overview
Discovered in early 2016, Mazar Bot is spread by sending SMS text messages, via a URL shortener service. Mazar Bot targetedmultiple banks specifically in the German-Austrian region according to attacks that wereencountered 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 isspread 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 formobile devices. Once the malware has received the needed login information itdisplays 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 Botexplains 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 allowsthe device to install the application from unknown sources Runsthe 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 containssome 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 SitesStatistics Researched by Kyle Paris According to attacks we've encountered in early July,there wasn't anydistinctive region target for hacked servers. The interesting patterns we did identifywere compiled from groups of 8-10 phishing links with every attack.Each link main domain was slightlydifferent, either by number or a letter, while the subdomain and subfolder remained the same. Here is a table comparing phishing links groups with theirdomain 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
Madness DDoS Bot Analysis
“Madness” is a Denial of Service bot targeting Windows machines. While it constantly evolves its capabilities, it certainly represents the progress attackers made in Layer 7 DDoS expertise. The bot author proudly states that “Madness” is the superior successor and an actual hybrid of the notorious DDoS malware families “BlackEnergy”, “gbot”, “DirtJumper”, “Darkness Optima”, “iBot” and “w3Bot”. Its phone-home architecture is based on polling the C&C server. Once a minute it sends a probe to its operator with information on the infected machine (OS and level of privileges) and the number of attack payloads successfully sent, while the C&C will respond with the current attacking command (base64 encoded). DDoS Capabilities Madness DDoS capabilities consist of network floods, such as UDP and ICMP, however the more interesting part is its diversity of HTTP (Layer 7) floods. We can separate its HTTP floods to those using "low-level" libraries such as Windows Sockets API and those using more "high-level" libraries such as “WinInet” and “Urlmon”, which are also used by “Internet Explorer”. All the floods support up to 10 different URLs which might be used to attack different servers or different URLs on the same server. Going "low-level" lets the attacker make the flood much faster, and not less importantly gives him the flexibility in constructing the HTTP request from head to toe to bypass many DDoS protections. The added value of using "high-level" HTTP libraries is that they automatically handle all HTTP protocol aspects such as request construction, managing TCPconnections, caching, cookies and redirections. Those attacks support both simple "GET" requests and more complex "POST" requests with the ability tocontrol the data being sent in the POST body. While analyzing the threat, we have also noticed a very strange version of a SLOW GET attack, which rather may be called a "HOLD" flood attack. It sends a “GET” request containing only the “Host” header, sleeps for 0.1 second and only then completes the request by sending "\r\n". Bypassing Challenges Another aspect indicating a progress in attackers DDoS capabilities is having built-in techniques for bypassing anti-bot challenges. It starts with a simple “Anti-Cookie” feature for bypassing simple challenges, while mainly relying on parsing the response and responding appropriately in order to resemble a real browser. It appends cookies issued by the server either by the “Set-Cookie” response header or a JavaScript containing “document.cookie=” code. It also parses a specific JavaScript challenge issued by a well-known Russian web-hosting service. The challenge is obfuscated JavaScript which sets a cookie once executed. The bot looks for the strings "Cookie", "realauth=<value>" and "location" in the response and sets the appropriate cookie as a legitimate browser which renders JavaScript would do. However, the highlight is “Madness” ability to bypass more complex JavaScript challenges, specifically targeting “Cloud Flare”, a popular DDoS protection service. The challenge is JavaScript code which makes a certain calculation and sends back the result. If the result is correct, the server will issue an authorization cookie and all the following requests contacting that cookie will be considered legitimate. Instead of trying to simulate a browser, “Madness” author chooses to use a real browser. Once the attacker issues the “cfa” (apparently “Cloud Flare Attack”) command from the C&C, the victim machine runs an Internet Explorer in minimized window, browse the targeted website, performs the JavaScript challenge calculation, as it is a legitimate browser, and gets the authorization cookie. Once the cookie is saved in the browser, the attacker executes one of the “high-level” HTTP floods, specifically the one that uses the “Urlmon” library which is also used by Internet Explorer’s core, automatically appending the authorization cookie to each attacking request. Summary As layer 7 DDoS attacks are being effective, “Madness” provides different flavors of GET/POST floods with a high level of flexibility while integrating more advanced capabilities to bypass security solutions. We expect this bot to be seen more in the wild with upgraded capabilities. One of the lessons we learn from this analysis while protecting our servers is that it is not enough relying on clients simply answering the challenge, as complex as it might be. It also requires a proactive bot defense which has more integrity checks and implements more sophisticated logic around those challenges, as well as other prevention means such as rate limiting, CAPTCHA and behavioral anomaly detection.
Threat Analysis: perlb0t
This ancient bot, also known as the “Mambo” bot (due to an old vulnerability in the Mambo CMS it tried to exploit) has been around for a very long time, and many variations of it has been seen. However, from our observations, it is still being actively used in recent exploitations. After successfully exploiting an existing vulnerability on an unpatched webserver, a malicious Perl-based script is executed and turns the webserver into a member of a botnet. The names of the variables and functions in the code reveal that the bot author is likely a Portuguese speaker. Examples are words such as “servidor” (server), “conectar” (connect) and “pacotes” (packets). Like every “good” bot, perlb0t supports several functionality, such as port scanning, using Google search to find other vulnerable servers (also known as “Google Dorking”), running shell commands on the server and more. However, it seems that the main business model of this bot is a DDoS service. The bot supports HTTP and TCP floods, by sending “GET” requests or just opening (3-way handshake) and closing TCP connections respectively. But the most interesting DDoS functionality in this bot is the “UDP flood”, as its author calls it. At first glance it seems like the author is trying to create specific floods (ICMP, UDP, IGMP, TCP), however when further analyzing, this functionality is no more than just sending malformed packets of different protocols. Let’s look at this one… The C&C (Command&Control) instructs its bots to perform a “UDP flood” with 3 parameters: 1. Target (IP/Domain) 2. Packet size (in Kbytes) 3. Duration (in seconds) As we see from the source code, the bot uses raw sockets for the three types of packets, with different protocol numbers as the third argument, and one datagram socket for simple UDP. Using a raw socket enables the attacker to control more fields in the packet itself, however the bot writer needs to manually construct all the protocol headers. By looking at the table of supported IP protocols, we see that the bot creates raw packets of IGMP, ICMP and TCP protocols. Those packets are just being marked with those protocol numbers, however other fields and headers are not actually set. The packet is filled with “A” characters according to the size specified by the C&C command, making the packet a malformed one. However, even more interesting is the distinction the bot writer makes between the above protocols and other protocols the writer uses afterward. After sending malformed IGMP, UDP, ICMP and TCP packets, the bot will send 252 additional malformed packets of all other protocols (running from 3 to 255 protocol numbers, skipping previously sent protocols). The above screenshot displays a single loop in the attack, while each loop uses a different source port sequentially (running from 1 to 65000). Note the inaccuracy; the bot writer must have meant to run over all the 65k ports, which is 65,536. As we see from the bot’s traffic, a sequence of malformed packets is sent (the only well-formed is UDP), while the protocol number is sequentially incremented. (In the screenshot, this is shown as: 0xc, 0xd, 0xe, 0xf, 0x10…) It is important to note, that creating raw sockets needs administrative privileges, so if the infected webserver does not run as the root user, the attack will be a simple UDP flood. Note the destination port sequence. To sum up, a lot of attackers are lazy. They will do the minimum required to make their money suggesting DDoS services. As we learn from this example, an ancient bot first detected back around 2005 is still in the wild. Having the same basic structure, with edited nuances and sometimes functionality, it still spreads by exploiting recently discovered web vulnerabilities, making your web server part of a botnet.
