Exception Rewriting javascript
Hello, I have a application that load javascript on the APM with Portal Access and full patching. The application loads on the mobile devices and the loading is long, due to the rewriting of JavaScripts. I believe this is due to the resource restrictions on the mobile devices to handle/process large content. There are not links on the JavaScripts, then we do not need to patch it. I want to disable the rewrite for the JavaScripts I create Irule: when HTTP_RESPONSE { if { [matchclass $my_uri_SAP contains my_uri_SAP] && [HTTP::header "Content-Type" ] contains "javascript"} { REWRITE::disable } } It's not working fine 😞 At which event flow APM, I must to insert the rewrite::disable ? Or disable the process of rewrite. Thanks you in advance. Best Regards,
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.