Ideas for Free

Execution Not Included

 
  • Increase font size
  • Default font size
  • Decrease font size
Home Information Incoming Feeds Internet Storm Center
Newsfeeds
SANS Internet Storm Center, InfoCON: green


SANS Internet Storm Center
  • Large quantity SQL Injection mitigation , (Thu, Nov 20th)
    Normal 0 false false false EN-CA ZH-TW X-NONE MicrosoftInternetExplorer4 As botnets and other automated tools are hammering at websites trying to exploit SQL injection vulnerabilities, site operators are trying hard at defending their websites. ASProx and other botnets were hitting hard at the ASP + MS SQL platform, millions of websites fell victims to the SQL injection vulnerabilities already. Although there has been a decline of wild SQL scanning by ASPRox type of botnet, we are still not in the clear yet. The unauthenticated portion of some sites might be secure, but the authenticated portion might be totally vulnerable. Since most scans only target what can be seen by Googlebots, there are still tons of web pages out there vulnerable waiting for exploitation. If you have tons of vulnerabilities on your site, you likely will take some time to fix all of it as fixing code isn't the easiest and fastest thing to be done. A short term remediation to SQL injection can be web application firewall. Web application firewall (WAF) is similar to a network firewall except it also inspect the application layer information, such as cookies, form fields and HTTP headers. With Microsoft IIS as web server, one of the quickest and easiest WAF solution maybe Microsoft's Urlscan, it is an addon to IIS5 and built-in for later versions of IIS. Urlscan runs as an ISAPI filter, so it can be easily deployed and removed. Since version 3.0 of Urlscan, there are decent level of coverage on SQL Injection capabilities. The biggest complaint is that Urlscan do not inspect HTTP request body (POST data), so it could be missing attacks that are submitted using POST. I have recently played with another free WAF product on IIS called Webknight and found it to be easy to config and full of nice features. The default configuration file is reasonably tight. In most cases, you would probably want to loosen things up so Webknight won't break your site with false positives. It inspects SQL injection in header, cookies, URL and in POST data. The detection is based on hitting two of the preset SQL keywords. For most cases, this generally works well. It may render false positives with some more complex textarea field that expect various text. Overall, Webknight is a good WAF that can fulfill basic protection needs. Remember that WAF products are meant to be an extra layer of defense and/or a very short term mitigation until you fix up all the code. For mitigation, you are really just buying yourself more time before a compromise happens. While WAF do a good job at making the site harder to compromise, they have various limitation, the most effective long term mitigation is still fixing up the code. ------- Jason Lam, author of SANS web app courses - 319, 422, 538

  • How to Handle DDoS Incidents?, (Wed, Nov 19th)
    The incident handling cheat sheets in an earlier diary applied to many types of security incidents. Some incidents, such as DDoS attacks, can benefit from specialized guidelines. As suggested by one of our readers, we'd like to create a cheat sheet that helps organizations during a DDoS attack. We would love for you to contribute. If you have handled a DDoS attack, send us your advice on dealing with such incidents faster and more effectively. The tips should assume that the organization is reactive, and has not had much time to prepare for the incident in advance. We're looking for suggestions arelated to all stages of the DDoS incident, including detection, analysis, and mitigation. Update: Here's my attempt at organizing the tips we received so far. (Thanks, Chris, Daniel, Donald and Peter!) It's still a work in progress: Prepare These steps can greatly assist if your attacked. If you haven't done this and you get attacked you will spend the first few hours trying to get some of these steps done. Contact your ISP to learn what DDoS mitigation support they offer for free and for a fee. Create a whitelist of the source IPs you must allow if you need to prioritize traffic during an attack. (Include your big customers or critical partners, etc.) Confirm DNS Time-to-Live (TTL) settings for the systems that might be attacked. Lower the TTLs, if necessary, to facilitate DNS redirection if the original system IPs get attacked. Make sure you have contacts for your ISP, IDS team, firewall team, DNS provider, 3rd party security teams etc... Document your network information, including IP addresses and circuit IDs. Prepare an asset inventory and a topology diagram. Collaborate with your BCP/DR planning team, to understand their perspective on effects of a DDoS event. Analyze Detect the incident and assess its scope. Which infrastructure components are affected, and what is the logical flow of the attack? Understand the nature of the attack. Review the load status of servers, routers, firewalls, and other affected infrastructure components. If possible, use a network sniffer (e.g. tcpdump, ntop) to review the traffic flowing to the affected infrastructure. Contact your ISP and internal teams to learn about their visibility into the attack, and to ask for help. Find out whether the company received a ransom demand as a precursor to the attack. If possible, create a NIDS signature to focus to differentiate between benign and malicious traffic. Get the your company's executive and legal teams involved. Consider involving law enforcement. Identify what aspects of the offending traffic differentiate it from benign traffic (e.g., specific source IPs, destination ports, URIs, TCP flags, etc.) Mitigate DDoS attacks often take the form of flooding the network with unwanted traffic, in which case it will be very difficult to defend against the attack without specialized equipment or your ISP's help. There are steps you can take to mitigate the effect of some DDoS attacks, though. Attempt to throttle or block the offending traffic as close to the network's cloud as possible using a router, firewall, load balancer, web server configuration, etc. If possible, switch using DNS or another mechanism to an alternate site with more network or computing resources. Blackhole the traffic targeting the original IPs. If the bottle neck is on the server side, tune the systems' TCP/IP parameters to improve efficiency. If the bottle neck is particular features of an application, temporarily disable those features. If possible, add servers or network bandwidth to handle the load. (This is an arms race, though.) If possible, route traffic through a traffic-scrubbing service or product via DNS or routing changes. Additional Tips In an incident, there's a tendency for too many people getting involved in fighting the fire. (Too many cooks in the kitchen.) The more people accessing systems the harder it is to gather data. Make changes one at a time, don't be in the position where the issue gets resolved, but two separate changes occurred at the same time, so you don't know what fixed it. Humans get tired! If the incident goes on for a lengthy period consider how you will continue to operate and fight the incident the following day. You can never have too much data, logs are king when analyzing an incident. What do you think? Any corrections or additions? Pointers to useful resources? Let us know. -- Lenny Lenny Zeltser Security Consulting - SAVVIS, Inc. Lenny teaches a SANS course on analyzing malware.

  • An Ad for DDoS Services - Network, Phone, Competition, (Wed, Nov 19th)
    The oldfashioned way to launch a network DDoS attack involved building one's own bot network that would flood the victim with unwanted traffic. However, the illicit marketplace for such services has matured, allowing a person to purchase DDoS services on demand, effectively renting a botnet for the event. Here's one ad for such services. It's in Russian; the translation follows. The ad scrolls through several messages, including: Will eliminate competition: high-quality, reliable, anonymous. Flooding of stationary and mobile phones. Pleasant prices: 24-hours start at $80. Regular clients receive significant discounts. Complete paralysis of your competitor/foe. Perhaps the most interesting aspect of the advertised service is the offer to flood the victim's phones. We often think of network-based DDoS attacks, but phone-based DDoS could be as devastating. If the service can, indeed, target stationary (landline) phones, then we're not just talking about SMS-based floods. These would probably be actual phone calls, probably initiated using VoIP, maybe via stolen Skype accounts with dial-out credits. Anyone knows more about such phone attacks? -- Lenny Lenny Zeltser Security Consulting - SAVVIS, Inc. Lenny teaches a SANS course on analyzing malware.

  • Are We Doomed?, (Wed, Nov 19th)
    In no particular order: We Are Doomed There is Hope Bot networks seem to be growing in size. Many web developers don't understand XSS, CSRF and SQL injection-type vulnerabilities. Anti-virus vendors are starting to send signature updates several times per hour. It takes a reboot to update Adobe Acrobat and updating VMware Workstation requires a 330MB download. Criminals are becoming more aggressive about protecting their enterpises via DDoS. Targeted attacks easily bypass organizations' defenses. DNS remains a weak link. Passwords suck. Wi-Fi is becoming more common, even though securing it remains a challenge. People are becoming anesthetized to security breaches, because they happen too often. It's too easy to ignore the findings of security assessments. First-time users throughout the world are flocking to the Internet, increasing the low hanging fruit attack surface. Prescriptive compliance requirements (e.g. PCI DSS) are making it harder for executives to ignore IT security. Security technologies are becoming smarter (e.g., web application firewalls) and more powerful (thanks to cheaper ASICs and disk space). Anti-virus vendors are paying more attention to behavioral protection and performance. The community's expertise in analyzing malware is becoming more sophisticated. Search engines are starting to warn users about potentially malicious sites. The law enforcement seems to be getting better at catching alleged cyber-criminals. It may be getting harder to host malicious sites on a large scale. The media is improving security awareness by advertising security breaches. The developers of operating systems and web browsers are paying more attention to security of their software, and are providing safer default settings. Microsoft is making a version of their anti-virus free for home users. Companies are starting to include security throughout the SDLC and offer developers training on security issues. Any suggestions for the lists above? We'd love to hear them. It's probably easier to come up with the items for the Doomed column, but consider what we can build upon to tip the scales in the defenders' favor. Update: Thanks to everyone who wrote in with their perspectives, including: Mark Buchanan, Chris, Swa Frantzen, Tom McFadden, Frank Mellon, Jeff Martin, and David Rundle. -- Lenny Lenny Zeltser Security Consulting - SAVVIS, Inc. Lenny teaches a SANS course on analyzing malware.

  • 2 Cheat Sheets for Incident Handling, (Wed, Nov 19th)
    People only see what they are prepared to see. it's hard to find time to prepare in advance. Here are two cheat sheets that may help. In each case, I link to the HTML version cheat sheet. That page includes the printable 1-page PDF version, and the Word version of the file you can edit for your needs. Security Incident Survey Cheat Sheet for Server Administrators This cheat sheet captures tips for examining a suspect server to decide whether to escalate for formal incident response. Its steps attempt to minimize the adverse effect that the initial survey will have on the system, to decrease the likelihood that the attacker's footprints will be inadvertently erased. Initial Security Incident Questionnaire for Responders This cheat sheet lists the questions the incident handler should consider asking when taking control of a qualified incident. It's too easy to forget an important question when trying to think on your feet. How Else to Make Incident Response Less Stressful? Thanks to everyone who already offered feedback on these cheat sheets. If you have suggestions for improving them, please let us know. For additional tips on incident handling, see the summary of the suggestions we published in October. Yeah, I should have written this diary last month. Update: A related diary invites you to contribute to the DDoS incident cheat sheet we're working on. -- Lenny Lenny Zeltser Security Consulting - SAVVIS, Inc. Lenny teaches a SANS course on analyzing malware.