‫ اخبار

صفحات: «« « ... 8 9 10 11 12
Responding to Various Types of Incidents- Section 1
Date: 2011-07-11
In the “Computer Security Incident Handling in Six Phases” articles, we outlined actions that are applicable to a wide variety of computer security incidents. In these new articles, we define common types of incidents and suggest specific actions appropriate for dealing with each type. In these articles we will address Malicious Code Attacks, Probes and Network Mapping, Denial of Service, Inappropriate Usage, Espionage, Hoaxes, Unauthorized Access and Intellectual Property.
Type 1: Malicious Code Attacks
Malicious code is the name given to programs such as viruses, Trojan horses, worms, and scripts used by crackers/hackers to gain privileges, capture passwords, and to modify audit logs to hide unauthorized activity. Malicious code is usually designed to be difficult to detect and trace. Certain viruses can even modify their signature. NOTE: Even when your firewalls and other defenses stop adversaries, those attackers may be able to accomplish the same objective with Trojan horse code preinstalled on computers you purchase. In general, you should not rely on a single security component, such as a firewall, or a virus checker, to reliably protect yourself against malicious code.
Special Action 1: Use virus checkers
Anti-virus software can be effective at preventing the spread of common viruses, Trojan horses, and worms. Ensure that anti-virus software is widely available and that the signature files are kept up to date. Consider employing mechanisms that automate signature updates.
Special Action 2: Encourage users to report suspicious activity
Encourage users to report suspicious activity to help you detect an infection early on; educated users can act as effective anomaly sensors. Unexplained disk activity, unusual system messages, strange processes, and unexplained software behavior could be a sign of malicious code infection. Advertise an e-mail address or a phone number where internal users can report suspicious activity.
Special Action 3: Monitor for abnormal outgoing traffic (Advanced)
Malicious code specimens may attempt to communicate with external systems through HTTP, IRC, and other outbound protocols to propagate, announce their location, or download updates. Focus network monitoring systems to detect inexplicable packets originating from your organization bound for the Internet. Such activity occurs most frequently at system boot up, especially at the first bootup after the initial infection.
Special Action 4: Protect the software load process by doing it yourself (Advanced)
Develop processes to install all operating system software and applications locally, from tested configurations. Discourage users from installing software downloaded from the Internet, emphasizing the need for the use of trusted application images available internally.
Special Action 5: Consider alternative sources of support
Consider your actions in a scenario where you are infected by malicious code that is not widely known, in which case you might not be able to obtain detailed information about the program from anti-virus vendors. Have contact information at hand for relevant mailing lists (see Resources) and user groups that you may need to query for containment and eradication information.
Type 2: Probes and Network Mapping
Probes are a special case of unauthorized access attempts. One class of probe occurs when a potential intruder uses an exploit script against your information systems, or firewall, and the script fails. The failure occurs because the exploit script does not find the target vulnerability. The probe then attempts to map your network using SNMP or broadcast ICMP "ping" packets to determine the architecture of your network. Another class of probe is used simply for information gathering. In this case, the attacker tests a variety of ports (a behavior often called a port scan), or host addresses (called a host scan), attempting to map your facility. Some attackers "war dial" your organization's phones looking for modems. With the widespread use of wireless networks, attackers are now "war driving" using wireless scanners like NetStumbler to find these networks.
Special Action 1: Report probes to your CIRT
Even if your facility doesn't have vulnerability, your customers and suppliers may. If they have access to your systems, your facility could still suffer. There is some controversy as to whether one should "bother" CIRTs by reporting probes. AusCERT's guidance on this follows: "A reason for reporting probes to your CIRT is that they act as a central reporting agency. We have seen cases of probes that were not considered significant by individual sites being part of significantly larger attacks against many sites."
Special Action 2: Assess the damage
It is great if the intruders do not actually get inside and do damage, but ask whether they learned information about your operating systems and network architecture that they can use in the future. Examine logs carefully; if the exploit script or technique is available, consider running it against yourself to determine what information can be learned.
Type 3: Denial of Service
Users rely on services provided by networks and computers. Attackers use many tools to cause your network and/or computer to cease operating effectively: erasing a critical program, "mail spamming and mail bombing" (flooding a user account with electronic mail), and altering system functionality by installing a Trojan horse program.
Special Action 3.1: (Advanced) Employ backups for core services
The most likely targets in your organization for a network attack are DNS, web and mail servers. If your organization conducts a lot of business over the Internet, it may pay to establish backup facilities. Denial of service attacks is a problem because they are hard to trace, easy to execute and they are effective. In such a dangerous environment, it is sometimes smart to use backups to bring the system back from a denial attack.
Related Links:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Security in Internet Explorer 9
Date: 2011-07-09
In this article, we'll look at the security mechanisms in IE 9 and compare it with earlier versions of IE.
Microsoft has released the latest version of its web browser, Internet Explorer 9, in March. It’s sleek and pretty, and it’s definitely faster than its predecessor - but is it more secure?
Why browser security matters more than ever
There are two components to web security: the security of web sites and the servers on which they reside, and the security of the client software that accesses those sites – the web browser. There was a time when the web browser was just one of many Internet applications.
Whereas we once used separate email clients, FTP clients, IRC clients, newsgroup readers and more, today many computer users do the majority of their computing tasks through their browsers.
Now that the web browser has taken center stage and is inextricably involved with most of what users do on their computers, it’s more important than ever that the browser provides a secure environment not just for surfing sites for information, but for actually performing sensitive tasks. The web browser is one of the most frequently exploited applications, and at the annual Pwn2Own event, security researchers compete to bring down the popular web browsers. At this year’s competition, IE 8 was successfully hacked, along with Safari 5.0.3.
The evolution of Internet Explorer security
Microsoft’s web browser has come a long way since IE 1.0, which came in the Windows 95 Plus! Pack. Security wasn’t nearly so much of an issue back in those early days of the commercial Internet, although by the end of 1995, when version 2.0 was released, Microsoft had added support for Secure Socket Layer (SSL). Subsequent versions of the browser focused more on adding features such as multimedia enhancements and increasing performance and stability. However, enhanced functionality also meant more features that could be exploited, and IE used the concept of security zones to.
IE 6.0, which came preinstalled on Windows XP, was the first version to actually start to address security and privacy, with a new cookie handling tool and the first implementation of the P3P protocol for controlling privacy settings. This is a bit ironic, given that IE 6 is now considered a big security risk and everyone, including Microsoft, is urging computer users to stop using it.
The real push for security came with IE 7, which came with a phishing filter to protect against malicious web sites but this feature wasn’t support on XP computers. In addition, Active X opt-in helped to defend against some of the dangers of Active X controls and IE 7 allowed you to enable it on a per-zone basis, and security zones themselves were more locked down by default. Another security improvement in IE 7 was designed to protect against cross-domain scripting by making scripts keep the same security context. Better SSL/TLS notification made it easier for users to know whether a web transaction was secured, and web sites that obtained high assurance certificates (which require an identity verification process) were identified by a color coded (green) address bar. New registry keys were added to prevent HTML access to users’ personal data. There was even a “no add-ons mode” to ensure that threats couldn’t be introduced via browser add-ons. All in all, IE 7 was a big step forward for Microsoft, security-wise.
IE 8 came out in 2009 and added more security improvements such as domain highlighting, which makes it easier to determine the domain of the site you’re accessing, and the SmartScreen filter, which was a new and improved version of IE 7’s phishing filter that, in addition to protecting against phishing sites, also protects you from sites that are known to deliver malware. Although the browser gives users the option to disregard the warning, administrators could use Group Policy to prevent them from doing so. In addition to the blacklist, the filter also used heuristics to detect potentially dangerous sites. IE 8 also includes changes to ActiveX, so that controls are now installed on a per-user basis by default and can also be installed on a per-site basis. ActiveX killbits was integrated with Windows Update so the controls could be automatically disabled when an exploit was discovered. Data Execution Prevention (DEP) was enabled by default, the XSS Filter offered better protection against cross-site scripting, and the Cross Domain Request and Cross Document Messaging features make it more secure for sites to share information with one another.
What does IE 9 bring to the table?
IE 9 builds on all the security features that were introduced in IE 7 and IE 8. It also brings with it some additional protections, such as enhanced memory protection features that are aimed at preventing malicious code from running when a memory-related vulnerability is discovered. DEP/NX is the foundation of memory protection, and it causes the processor to terminate a process when a block of memory doesn’t contain the proper marking indicating that it is executable code. That means if an attacker places data in memory, the processor raises an exception and causes a “safe crash” rather than execute the potentially dangerous instructions.
IE 9 also improves on another IE 8 feature, Address Space Layout Randomization (ASLR), which helps prevent attackers from bypassing DEP/NX protections by ensuring that a process’s memory space is laid out in a way that’s not predictable. The randomization process has been improved in IE 9 to eliminate predictable memory mappings. IE 9 also supports a new feature call SEHOP (Structured Exception Handler Overwrite Protection) that validates the integrity of the exception handling chain to prevent structured exception handling from being exploited. This overcomes some of the limitations of SafeSEH (Safe Structured Exception Handling) which was designed to prevent malicious structured exception handlers from being introduced into the chain, but which was enabled on a per-DLL basis and required add-ons to be compiled with the SafeSEH flag.
Another focus of IE 9 security is protection against social engineering attacks. This makes sense, because many experts believe social engineering is one of the biggest threats to the IT infrastructure..
And the social engineering contest, in September of last year, showed that most organizations easily give up vital information to social engineers.
Social engineering is attractive to attackers because they don’t need deep technical skills to pull off an attack; all they have to do is convince a computer user to do something that will allow the attacker to get in. IE 9 improved the SmartScreen Filter by adding the SmartScreen Application Reputation feature, which works with URL Reputation to improve protection against socially engineered attacks. Application Reputation attempts to distinguish between reputable downloads and those that are potentially malicious. The SmartScreen filter is also integrated into the new download manager in IE 9.
Yet another security/privacy feature that’s built into IE 9 is called Tracking Protection. This feature makes it easier for users to block or allow third party content by using Tracking Protection Lists from trusted organizations.
Finally, the Pinned Sites feature in IE 9, while it may seem like merely a convenience, also provides some security benefits. By pinning the sites you use often, such as your banking site, to your toolbar, you make it easy to go to the site. Another advantage is that because pinned sites run in a separate session of IE, cookies used by those sites can’t be accessed. Another good thing about pinned sites is that they run without add-on toolbars or helper objects so attackers who use those as an attack vector won’t be able to attack your pinned sites sessions. You can also ensure that you always connect to the secure (https) version of the site and don’t get redirected to the non-secure (http) version. And you get some protection from man-in-the-middle attacks aimed at the HTTPS protocol, because the connection will be terminated if there’s a problem with the site’s certificate.
What more could you want?
There have been complaints that the default security settings are not stringent enough, and that all active content should be completely locked down by default, then users could add trusted sites one at a time.
Along those same lines, security purists might object to the blacklist method used by SmartScreen. This basically allows sites that aren’t known to be malicious (although as mentioned earlier, heuristics are also used). Those folks would prefer a whitelist method, which disallows all sites except those that are known to be trustworthy. Certainly that is the more secure approach – but it’s also one that would probably earn the ire of many users.
Another commonly heard complaint is that IE’s security settings, while they provide very fine grained control, are overly complex for the average user.
18 مرداد 1393 برچسب‌ها: مقالات
Computer Security Incident Handling in Six Phases- Follow Up
Date: 2011-06-28
In Follow Up phase, the goal is to learn from the incident. You are searching for lessons that will help you do a better job in the future. Some incidents require considerable time and effort. Stress levels rise and relationships may become strained. Afterwards, the folks who were at the center of the storm tend to want to forget it and get on with their lives. Performing follow-up activity, however, is one of the most valuable activities in responding to incidents. This procedure, only slightly more popular than wisdom tooth removal, is known as "the search for lessons learned". Organizations that follow up soon after problems have been contained find they rapidly improve their incident handling capability. Rapid follow up also helps support efforts to prosecute those who have broken the law.
Experience must be captured quickly. A Follow-up report, including lessons learned, is the accepted method of protecting the knowledge so it can be used in the future.
Action 1.1: Start as soon as possible.
Folks who wait until weeks after the dust has settled, learn that the human memory, unlike fine wine, does not improve with the passage of time.
Action 1.2: Assign the task to the on site team.
In order to make the lessons learned section as positive and effective as possible, most sites require the incident handling team to draft the Lessons Learned Report as an integral part of their handling of the incident. The job's not finished until the paperwork is done.
Action 1.3: Include forms from this guide.
The incident report is generally an electronic version of the identification, survey, containment, and eradication forms that are included in this guide. Focus especially on answering the questions on the Lessons Learned form.
Action 1.4: Encourage all affected parties to review the draft.
Submit the Lessons Learned, along with the draft incident report, for review by all affected parties.
Action 1.5: Attempt to reach consensus.
Gather responses, disagreements, additions, and suggestions from all the interested parties. Encourage them to submit comments electronically, so they will do it quickly. Keep their comments as part of the record.
Action 1.6: Conduct a Lessons Learned meeting.
Distribute the comments in advance and plan for a one-hour Lessons Learned meeting. If you surprise people with comments they had not previously reviewed, meetings can take much longer. Focus the meeting on recounting the incident and ratifying any process changes.
Action 1.7: Create an Executive Summary.
Summarize the incident, including cost and impacts, for management. Submit the summary to management with a promise that recommended changes will follow.
Action 1.8: Send recommended changes to management.
Provide management with a prioritized set of recommended changes from the Lessons Learned process along with cost estimate, high-level schedule, and impact of implementing or not implementing the recommended actions.
Action 1.9: Implement approved actions.
Where you get management approval, ensure the changes are made using your organization's tasking system.
Incident Follow-Up questions
Below you will find some suggested questions for the Lessons Learned meeting. The primary purpose of the meeting is to improve your incident handling process, not to play politics! In almost every incident some things are done well, some things aren't. People have a tendency to remember the screw-ups. Accentuate the positive.
Briefly describe what has transpired and what was done to intervene. Was there sufficient preparation for the incident? What preparation wasn't done that should have been done?
  • Did detection occur promptly or, if not, why not?
  • What additional tools could have helped the detection and eradication process?
  • Was the incident sufficiently contained?
  • Was communication adequate, or could it have been better?
We have never been involved in a serious incident where anyone could seriously claim that "communication was great". The phone lines are overtaxed; the onsite team has trouble reaching the command decision team to provide them needed tactical information. As stress goes up, communication degrades. The point of this question is to find ways to improve communication. An organization might not wish to approve three extra phone lines into the facility that will be used by the command decision team. After an incident, (and its lessons learned phase), in which the team was unable to stay in communication with critical parts of the organization, phone lines are often installed without further comment.
  • What practical difficulties were encountered?
Analyzing the cost of the incident. Work within your chain of command to determine personnel time that was invested in dealing with the incident, including time necessary to restore systems. Convert those hours into monetary cost. The simplest method is to multiply the time spent by the burdened rate, usually about 1.5 times what the organization pays in salary.
  • Ask how much the incident disrupted ongoing operations?
  • Were any data irrecoverably lost, and, if so, what was the value of the data?
  • Was any hardware damaged?
Generate an executive summary that includes cost and schedule impacts. If possible, post the results of the incident investigation on the incident handling intranet web page.
Related Links:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Computer Security Incident Handling in Six Phases- Recovery
Date: 2011-05-31
We have studied the “Identification”, “Containment” and “Eradication” phases of incident handling process in the previous sections of “Computer Security Incident Handling in Six Phases” article. This section explains the “Recovery” phase which is the fifth phase of incident handling process.
Recovery Phase
In the Recovery Phase, your task is to return the system to fully operational status as soon as possible.
Speed is critical, but a misstep at this stage may allow the attacker to re-enter the system later.
Action 1.1: Restore from backups or reload the entire system
Some incidents, such as malicious code, may require a complete restoration of operation from backups. In this case, it is essential to first determine the integrity of the backup itself. In general, the idea is to restore from the most recent backup made before the system was compromised. Make every effort to ensure that you are not restoring compromised code. If no backups have been made prior to compromise, you may have to rebuild the system from CD-ROM or other trusted media and apply patches, or to obtain and use a backup from a similar system that has not been compromised.
Management and users want to know whether the problem has actually been eradicated.
Action 2.1: Once the system has been restored, verify that the operation was successful and the system is back to its normal condition.
Ideally there is a system test plan to evaluate the system. More commonly, the system is run through its normal tasks while being closely monitored by a combination of techniques such as network loggers and system log files. A caveat: sometimes patches or techniques used to prevent a vulnerability, will cause the system to function differently than it did before the event.
Uncertainty about whether all malicious code has been removed can cause long delays.
Action 3.1: Put the final decision in the hands of the system owners.
We suggest that the management of an affected system and their system administrators make these decisions. Quite often, they will be sufficiently sensitive to security threats that they may wish to leave the system offline for a couple days to do an operating system upgrade or even to install additional patches.
Back doors and other malicious code can be very well hidden.
Action 4.1: Once the system is back on line, continue to monitor for back doors that escaped detection.
Related Links:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Computer Security Incident Handling in Six Phases- Eradication
Date: 2011-05-31
The goal of the eradication phase is to eliminate or mitigate the factor(s) that resulted in a compromise of system security. Compromise of a system can be traumatic for a system owner. But if the incident handling team fails to adequately eradicate the problem, and if another compromise occurs, then management can legitimately question the competency of the incident handling team itself.
You cannot fix the security problem that led to a system compromise if you don't know what happened.
Action 1.1: Isolate the attack and determine how it was executed
Information collected during the survey phase may be sufficient to determine the root cause of the incident. In most incidents, there are multiple causes for a compromise. The absence of adequate technical controls, for example, may result from the failure to adequately select and train system administrators; from the lack of written security policies and procedures; from the absence of management emphasis; or all of these reasons. Team members must conduct a comprehensive review of the data gathered, and not assume that one factor alone contributed to the compromise.
If for whatever reason, there is insufficient evidence to arrive at an exact understanding of the attack and how the attacker exploited a weakness, then team members may list all realistic possibilities based upon available information. From what is possible, the team can collectively develop scenarios to explain what has occurred.
Once a system has been compromised, its password file, IP address, and operating system may get advertised to the hacker community. As a result, for weeks following the incident, the system may get repeatedly probed or attacked. New attackers may have enough data to launch attacks. More importantly, the original attacker may be unaware that the system's owner has discovered the compromise. That attacker may continue to return to the compromised system to obtain additional information and to use the compromised system as a springboard for attacks on other systems.
Action 2.1: Implement appropriate protection techniques such as firewall and/or router filters, moving the system to a new name/IP address, or in extreme cases, porting the machine's function to a more secure operating system.
The incident handling team cannot permit a compromised host to reestablish network connections until the team fully understands the cause(s) of the incident, and can direct the system's owner to follow specific eradication procedures that will preclude a reoccurrence. The team must always verify the correct implementation of those procedures before reconnection.
Depending on the environmental and operational factors involved, many procedures may be outside the control of the system's owner. For example, typically in large enterprises, firewall and router configurations are the responsibility of another organizational entity. The team should serve as the liaison between the system's owner and these entities to ensure adequate protection. Similarly, the system's owner may lack the technical expertise to re-build a system after a compromise. The incident handling team may have to provide assistance, or again serve as a liaison. Finally, the team may decide that the cause of the compromise was an insecure operating system or network environment that cannot be addressed by simply re-building an existing system or network. The team may then recommend that management approve a redeployment on a safer operating system before reconnection.
Though prudence dictates that all sites that care about security perform regular vulnerability analyses of their systems and networks, many do not. When they experience a security incident, however, they usually act quickly to look for additional vulnerability analyses. The use of automated vulnerability assessment tools can assist an incident handling team not only to validate the correctness of eradication procedures, but also to anticipate and correct factors that might facilitate an attack.
Action 3.1: Perform system vulnerability analysis
Use a system vulnerability tool to determine whether configuration and software versions at your site need to be updated. Either acquire a vulnerability analysis tool or hire a security consultant who brings one along.
Both host-based and network-based assessment tools can determine the robustness of system and network configurations. Host- based tools provide a higher degree of accuracy than do network-based tools. Increasingly host-based tools such as bastille, available at http://www.bastille-linux.org or the tools from the Center for Internet Security http://www.cisecurity.org/ have the capability to actually correct or to strengthen the security of a system. Network-based tools such as nmap, available at http://www.insecure.org/nmap or nessus, available at http://www.nessus.org can identify, and in some cases stress, common vulnerability exposures that may have resulted in a compromise. A combination of tools is beneficial because each tool may have unique capabilities.
Action 3.2: Search for related vulnerabilities
One critical step, often forgotten in the eradication phase, is to ensure other platforms within the organization are not vulnerable to the factor(s) that allowed the compromise. Incident handling team members can quickly use automated assessment tools to search for these factors. Team members must be aware, however, of two pieces of information that can facilitate the search. First, does the organization have an inventory of computing resources? If so, that inventory will expedite the search. Team members must recognize that, if they employ a network-based assessment tool, they may have no assurance that all potentially vulnerable systems are online at the time of search. Without a valid inventory of computing resources, any network search may be an exercise in hit-and-miss.
Second, does the organization have an effective configuration management program? If so, is the program centralized or decentralized? Inventories and centralized configuration capabilities will allow the team to focus its attention and resources productively when searching out and correcting related vulnerabilities.
Deciding what to do to remove the cause is often a great challenge. The actions below provide high-level guidance. Additional guidance for each of the common types of attack is offered in a later section.
Action 4.1: For virus infestations
In the case of a virus, eradication simply requires removing the virus from all systems and media, usually with virus eradication software.
Action 4.2: For other malicious code infestations
Commercial software may exist to eradicate common or "in the wild" malicious code. Most commercial programs will identify computer viruses, well-known Trojan horses, and certain worms—all forms of malicious software for the Windows and Macintosh environments. For Unix environments there are few commercial programs available. However in most cases, dedicated professionals have released detection and removal tools into the public domain to address the influx of Trojan horses and worms that have appeared in UNIX systems within the last three years. The incident handling team must stockpile both commercial and free detection/ eradication software in anticipation of an infection.
The team must recognize the potential for reinfection, given that it may be difficult to disinfect all media—particularly backup media. If backups become infected, then the potential for reinfection increases.
Finally, the team must ensure that there is an effective procedure by which updates to commercial anti-viral programs are available.
Action 4.3: For network intrusion
In the case of a network intrusion, eradication is more difficult. Many attacks over a network are in two parts. First there is an initial phase, where a system vulnerability is exploited and the system is accessed. Once in, the intruder often installs a tool (back door) to provide continued access. The intruder may also set up shop on the compromised system to use it for intrusions into other computers. There are many examples in which intruders have launched exploit scripts against other computers from a single compromised system. Attackers also often install backdoor access programs and sniffers to collect additional passwords and user ID's. Your team's job—often its most difficult job—is to search for all such programs and remove them.
The team must determine whether the attacker has modified the compromised system in any way (i.e., alterations of system binaries and files, installation of attack programs, creation of "backdoors" into the compromised system). The only practical way to do this is to immediately disconnect the compromised system from the network until such time as team members have completed forensic analysis. This assumes that team members have information as to what was the baseline "norm" of the system before compromise; and that they have access to clean, uncompromised system binaries and application programs installed on the compromised system.
If there are business reasons that preclude disconnection, then the team can consider alternatives. For example, it may be possible to place a firewall directly in front of the compromised system and establish an Access Control List (ACL) to preclude an attacker's access. Another possibility may be to filter incoming and possibly outgoing connections to and from the compromised system at the organization's network perimeter.
Finally, if law enforcement considerations dictate that monitoring the attacker takes precedence over eradication, then the system may be left in place with appropriate sensors to capture the attacker's keystrokes. Only senior management, not the incident handling team, or the legal department, has the right to approve such a course of action.
Action 4.4: If the attacker discovers your efforts
Sometimes the attackers will detect your eradication efforts and attempt to maintain control of your system. This is a tough situation for which you may wish to request law enforcement support. Continue in your efforts to remove the attacker's code from your system. Do everything possible to get network/phone logs of the attack. If the source address of the network traffic is not spoofed and if your policy allows, contact that owner for the source network and try to get their logs as well.
In some cases, attackers have actually contacted organizational personnel with offers to help in the eradication.
Each organization must have written policies and procedures in place to address such situations. The policy must indicate at what point the organization will report to and seek assistance from law enforcement agencies. Most importantly, the policy must identify who within the organization will make the decision, and who will make the contact.
Team members should refrain from direct contact with an attacker in the absence of written policy. If such contact does occur, team members must maintain detailed audit records of all contact. Once law enforcement personnel have responded to an incident, they—not organizational personnel—will usually manage all contacts. For this reason organizations should make liaison with respective law enforcement agencies in advance of an actual intrusion.
In the next phase you'll restore the system to operation. First, however, you must locate a backup that is not infected and that is current.
Action 5.1: Search for a current backup (i.e., pre-infestation or intrusion)
It can be hard to know just when the attack occurred, and this makes selecting your backup problematic. During the Code Red worm attack, the second version, "variant c" installed a back door onto the Windows NT or 2000 system running IIS. Most of the people affected by Code Red were unable to determine when their system was first compromised. Though there were tools to remove the infection, there was no way to know what had been done to the system while it was compromised. They had to choose between rebuilding the entire system from original media or restoring files from a backup created before the second version of Code Red was first detected in June 2001. In either case, high quality backups were critical.
· In case of a root kit-style attack
A root kit attack embeds so much malicious code in so many hidden places in a computer system that cleaning the system is almost never a viable option. If there is evidence of a root kit style attack, it may be better to avoid the backups, nuke the disk, rebuild the operating system (without the vulnerability), configure the operating system safely, patch the operating system with the latest patches, and reload the data.
Related Links:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Computer Security Incident Handling in Six Phases- Containment
The goal of the containment phase is to limit the scope and magnitude of an incident—to keep the incident from getting worse.
If data is not gathered quickly and accurately, it may never be gathered.
Action 1.1: Deploy a small team
Four or five people are the limit for an On site Team at one location. The risk of loss of coordination leading to errors and the overhead of incident communication goes up with a larger team. Also, if this incident should ever go to court, everyone who stays in the area is a potential witness.
Action 1.2: Secure the area using physical security personnel if possible.
Action 1.3: Use the survey forms provided at the end of this article
The fields in the survey forms will help ensure that all needed information is recorded.
Action 1.4: Review the information that was provided to you from the identification phase
Be very careful to check any conclusions others have reached.
Action 1.5: Keep the system(s) pristine
Do not allow the system to be altered in any way until the backup has been completed.
If a network-based intrusion is determined, be careful not to give away what you know.
Action 2.1: Avoid using obvious methods to look for the intruder
A classic rookie error is to ping, nslookup, finger, telnet to, or in some other way make contact with the suspected source of the attack (hours later). If your adversaries detect you trying to locate them, they may delete your file systems and break off the connection (for a while anyway) in an effort to cover their tracks.
Action 2.2: Maintain standard procedures
If your site is protected by an active intrusion detection system that drops connections or blocks attacking IP addresses, do not disable the IDS to try to gather more data. This would create a change in your profile that might warn the attacker
Intruders may install Trojan horses and similar malicious code in system binaries.
Action 3.1: Be wary of compromised system binaries
It is not advisable to log in to a system suspected of being compromised, as "root" or "administrator," and then start typing commands such as ftp to download tools from another site. If possible, record the cryptographic fingerprint of critical binary files for the organization's core operating systems. Some experienced incident handlers recommend building disks with core binaries. In any case, the only binary you want to be particularly concerned about at this moment in an incident is the system's backup program.
Perpetrators of computer crime are becoming increasingly proficient in destroying evidence of illegal activity to avoid detection or prosecution. Therefore, it is extremely important to obtain a full backup, preferably using disk imaging of the system with known good binaries in which suspicious events have been observed.
Action 4.1: Backup to new (unused) media
Do your backup as soon as there are indications that a security-related incident has occurred. Use new media because juries may be convinced that the "evidence is faulty" if it is written over old information. Making a full backup immediately captures evidence that otherwise may be destroyed before you and others have a chance to look at it. If possible, make two backups, one to keep sealed as evidence, and one to use as a source of additional backups. The backup will also provide a basis for comparison later in case you need to determine if any additional unauthorized activity has occurred. Disk-to-disk backup is often the fastest method. Though there are tools for some Unix systems that do destructive formats, in general if you have to reuse media you should not count on format to erase all of the previous data.
There are tools that clear disk by overwrite to U.S. Government standards such as BC Wipe. Finally, you could always try using dd, e.g. dd if=/dev/zero of=/dev/hdb.
Action 4.2: Safely store any backup tapes so that they will not be lost and/or stolen
Tape protection is an important part of the chain of custody of critical information. If tapes are unprotected, the entire case could be damaged.
One of the most difficult decisions, and one subject to extreme pressure by end-users and senior management, is what to do about the compromised system. Here you will decide whether a system should be shut down entirely, disconnected from the network, or be allowed to continue to run in its normal operational status so that any activity on the system can be monitored.
Action 5.1: Acquire logs and other sources of information
Many log files turn over fairly quickly, so it is important to acquire network and computer logs immediately.
Action 5.2: Review logs from neighboring systems
Review logs and cryptographic file signature databases from other systems on the same subnet and from systems that regularly connect to the affected system(s), especially if there is a trust relationship.
Action 5.3: Make a recommendation
The On Site Team provides a recommendation to the Command Post Team, who will make the decision on what to do.
System owners' stress levels can be very high because their business may stop during the review process, and very large amounts of money may be lost.
Action 6.1: Keep system owners and administrators briefed on progress
The users of the affected system almost invariably really need the system, usually for an important project due that day. There is also a tendency for the system administrator or manager responsible for the system to internalize the incident. They might become defensive because they sometimes feel that since they operate the affected computer, the situation is their fault. Keeping them informed and aware of progress can help lower the stress level.
Action 6.2: Never allow fault to be an issue during incident handling
As you work to contain an incident, try to take time to give your co-workers a smile, a pat on the back, and mention the things that are being done right as much as possible.
A common target of intruders is root or administrator account names and passwords.
Action 7.1: Change the password on the affected systems
In the case of system compromise, passwords should be changed on the compromised system and all systems it regularly interacts with.
Action 7.2: If a sniffer is detected or suspected, expand the password change order
If you have reason to believe your systems have been subjected to a sniffer attack, passwords may have been compromised on all systems on the affected LAN or subnet. If a large system such as a POP mail server is compromised, and the organization wants to keep rumors and questions to a minimum, it may be advisable to explain the password change as part of a system upgrade or as the routine recommendation of an external security auditor. Emphasize how important it is for users to change to a unique password that is not being used on any other computer system.
Related Links:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Computer Security Incident Handling in Six Phases- Identification
Identification involves determining whether or not an incident has occurred, and, if one has occurred, determining the nature of the incident. Identification normally begins after someone has noticed an anomaly in a system or network. This phase also includes informing and soliciting help from the people who can help you understand and solve the problem. It is important to recognize at this point that not every network or system anomaly will be a security incident. Too often, people leap to the conclusion that there's a hostile intent behind every problem.
Without a central point of control, too many people may be working at cross-purposes. Undirected activities could cause the misdiagnosis of the nature of the incident, loss of forensic evidence, and possibly creation of a worse situation than the incident by itself would have caused.
Action 1.1: Select a person to handle or coordinate identification and assessment
If at all possible, the method for selecting a person as an incident handler should be predefined. This person should have broad general knowledge of the enterprise, and have some experience in handling incidents and problem determination. If the Command Decision Team and On Site Team are in different locations, it is imperative the two teams remain in communication using secure means throughout the incident. Because incidents often take place during off-hours, weekends or holidays, a pool of several potential handlers should be identified and be familiar with the security policies and procedures. And they should know where to find the contact and escalation lists developed during the preparation phase, both internal and external.
Action 1.2: Begin a log of the incident
From the very beginning of a suspected incident, the person handling the incident should start taking notes on each step, identifying who did what, when and how and why they did it. The notes should be chronological, with the time of each entry indicated. Keep the log as factual as possible; care should be taken to avoid speculation. Avoid statements like "The hacker has clearly erased the system logs"; instead use a statement like "The system logs do not show any entries for a period of six hours." Log entries must be statements of fact; careless speculation can confuse the evaluation of the incident, and when repeated in court, could damage a legal case.
Evidence indicating a potential security incident often turns out to indicate something else too. If a situation is misdiagnosed, it is often easy to make the data "fit" the misdiagnosis.
Action 2.1: Check for simple mistakes
Examples of simple mistakes include errors in system configuration or an application program, hardware failures, and, most commonly, user or system administrator errors. A seasoned incident handling professional, who has seen many cases, can often make the determination with just a few questions of the local system administration staff. Taking the time to evaluate the configurations for simple mistakes has a dual purpose: it is also possible to expose other related problems or vulnerabilities through this initial examination process. Once the simple mistakes have been quantified or ruled out, it is much easier to determine the total scope of the incident.
Action 2.2: Assess the evidence in detail
Use the list of indicators you developed during the preparation phase to quickly assess the possible type of incident.
The events that you see and the evidence you collect may be excellent, but they won't be worth much in a courtroom unless you can prove six months later that these are the exact events that happened, and are the same evidence you collected during the incident. Maintaining a clear chain of evidence may become critical in the event that the incident ends up in a legal case. The opposition will challenge each item. If they can show that someone has had the opportunity to modify the evidence during or after the time it was collected, they can radically reduce the legal impact of the evidence.
Action 3.1: Identify every piece of evidence
Unless you are facing a dire emergency where you must immediately unplug the system to stop damage, before you touch the computer, begin to identify the evidence. Your logs should state the day and time, and describe your location and any serial numbers or other identifying information. Law enforcement agencies may request that suspect disk drives be removed and sealed as evidence. If they have identifying information—make, model or serial number—be certain to record that. In addition, plans should be in place to recover both hardware and backup data. Even older backup tapes that predate the incident may provide valuable evidence. Whenever copies of electronic data are made, the original data, not the copy, should then be sealed for evidence.
Number, date, and sign notes and printouts. Seal disks with original, unaltered, complete logs in an envelope or other container; then number, date, and sign the container. When you turn evidence over to the appropriate person in your organization, have the recipient sign for each item. If evidence is turned over to law enforcement, ensure every item turned over is detailed and signed for as part of your chain of custody process. Original handwritten notes should be copied, and the original notes sealed as part of the chain of custody. Electronic data should be captured as soon as possible, and the process of making copies of the evidence should be witnessed.
Action 3.2: Control access to evidence
Identify an evidence custodian to ensure that you can prove who has access to the secure container used to store the evidence – and this is a very small group of people. If there is a key lock, each key should be stamped do not duplicate. Make sure, by policy and practice, that each person with access understands they are required to control access to these items. Any and every person with access to the evidence may have to testify if the incident results in a court trial.
Problem: Many of the corrective actions may require the assistance of your ISP. Filters may need to be applied, or routing tables modified before the network traffic reaches your site. In addition there may be forensic evidence in the ISP's logs that should be protected.
Action 4.1: Coordinate closely with your Internet Service Provider
Inform your ISP of your initial evidence or opinion, and ask the ISP to assist in the investigation. If possible, it is helpful to have contact names and numbers of the senior personnel at the ISP prior to the incident. Many hours can be lost navigating through the average help desk escalation procedures. You need to reach those people who have the capacity and experience to evaluate the logs and to make changes to the network equipment.
To protect themselves against user complaints, most ISPs will ask for a properly executed court order before sharing any information they gather with you. Unfortunately normal log rotation schedules may destroy evidence before a court order can be obtained. To protect the data, ask your ISP to set aside copies of their logs as a courtesy until a final determination is made about whether a court order is merited.
Problem: Computer incidents, fires, and medical emergencies are usually a lot easier to handle when reported promptly. If you saw a co-worker in the cafeteria collapse, hopefully you wouldn't wait until the next day to alert the emergency medical system.
Action 5.1: Notify your local or organizational incident handling team
Notify your manager and security officer as soon as the incident is suspected. It is far too easy to begin working through an incident and forget to involve the management team. It is the responsibility of the management team to insure that proper notifications are made and that the necessary resources are made available to the team. It is a common practice to have the incident handler separate from the designated contact for management, so that the handler is able to focus on coordinating the technical activities. A management person should work closely with the handler in order to keep the management chain of command informed and involved.
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institue, 2003
18 مرداد 1393 برچسب‌ها: مقالات
Cross-Site Scripting Vulnerabilities
Have you ever mistyped the address of a web site and received a message like “Error - page name could not be found” or “The page you requested: page name does not exist”? Certainly you have, and odds are you never gave it a second thought; you simply corrected the address or went to a different site altogether. It happens all the time. There are plenty of dead links, or links with typos to stumble upon. However, when you encounter an error message like the two listed above, you are actually witnessing a potential security breach—not necessarily against the site, but rather against you directly.
Suppose you entered the following valid URL:
If the document "FILENAME.html" did not exist, the web site could return an error message such as
<HTML> 404 page does not exist: FILENAME.html
.... </HTML>
Notice that "FILENAME.html" is a string that you entered. The web site has included it in the page returned straight through to your browser.
This may seem harmless, but now imagine that you are browsing through auctions on a popular site; let’s call it auctions.example.com. You come across several auctions that someone has posted and would like to see more items that the same person has for sale; let’s assume this person is a “bad guy” (though you don’t know it) and call him BG12345. You click on BG12345’s website and see a listing of his auctions. You click on a link on his page that interests you and are taken to auction.example.com’s site displaying that item. You scroll down to place a bid, and the auction site prompts you for your name and password to sign in. You enter all the information and hit the submit button. Everything looks fine, but in reality, the information that you submit is getting sent back to BG12345. How can this be? The answer is that auction.example.com has what is known as a cross-site scripting (CSS) vulnerability.
A CSS vulnerability is caused by the failure of a site to validate user input before returning it to the client’s web-browser. The essence of cross-site scripting is that an intruder causes a legitimate web server to send a page to a victim's browser that contains malicious script or HTML of the intruder's choosing. The malicious script runs with the privileges of a legitimate script originating from the legitimate web server. The two error messages mentioned earlier could be examples of such a situation. If instead of entering a page name, you entered an HTML or 1 script tag, the server would have returned that command to your browser, as well. Your browser would assume the HTML or script tag was from auction.example.com. It would run the script with the privileges that are set up for that site, and when you looked at the website, everything would appear to be normal.
BG12345 used the same method to deceive you. When you clicked on the link to BG12345’s auction, the link was actually to an invalid page. The link may have looked something like the example below, it used HTML and scripting to mimic the auction site’s page exactly. However, when you clicked submit, it used a form that passed your information back to BG12345. Now BG12345 can access your account, place bids, and change your information. BG12345 can also change your password and lock you out of your own account. Even worse, BG12345 can see the credit card number that you registered with.
So what did BG12345 do? BG12345’s web site offered a link to auction.example.com that looked something like this:
<A HREF=http://auction.example.com/<script>alert(‘hello’)</script>">Click Here</a>
The "FILENAME.html" submitted to auction.example.com was,
auction.example.com then used its ordinary routines to generate an error page to you that read,
<HTML> 404 page not found: <script>alert(‘hello’)</script>
.... </HTML>
In effect, BG12345 managed to "inject" a JavaScript program into the page returned to you by auction.example.com. The JavaScript ran as though it originated at auction.example.com, and could therefore process events in that document. It also maintained communication with BG12345 by virtue of scripting that BG12345 put in the link; this is the way a CSS vulnerability can be exploited to "sniff" sensitive data from within a web page, including passwords, credit card numbers, and any other arbitrary information you input. There are a number of variants to this problem. Odds are that bank.example.com also has the same vulnerability somewhere on its site. BG12345 could potentially access your bank account and transfer funds using the same process.
So what can be done?
The best protection is to disable scripting when it isn’t required. However, even this does not prevent the injection of malicious HTML. You should also protect yourself by accessing security sensitive pages directly instead of following links from unknown sources, or untrusted sites. For example, don’t trust a link to your banking site that is in an email message. If you need to access your banking site, go there directly. And, as always, exercise caution when supplying personal information.
• Webmasters can also help. They can ensure that none of their pages return user input that has not been validated. They can also encourage users to disable scripting.
• Another solution is to have “signed scripting” such that any script with an invalid or untrusted signature would not be run automatically. Suggestions of this nature, however, would require changes to the current Internet standards and specifications. Such changes would have to be submitted for consideration to the World Wide Web Consortium (www.w3c.org) or the Internet Engineering Task Force (www.ietf.org).
• If you notice an instance of cross-site Scripting notify the webmaster of that site, and cc the CERT Coordination Center.
Unfortunately, security is often sacrificed in favor of functionality. But, if you browse the Internet with scripting enabled, there is very little you can do to protect your personal information. Cross-site scripting is easy to overlook, and simple to correct. However, it can cause significant damage–your passwords and credit card numbers can be unknowingly divulged to untrusted sources.
Jason Rafail from cert.org
18 مرداد 1393 برچسب‌ها: مقالات
صفحات: «« « ... 8 9 10 11 12