Lawman Technology and Consulting Group LLC

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

In response to the heavy publication in the press about the DLL hijacking vulnerabilities, Microsoft released a number of publications and even a tool of their own.
Judging from the comments on the article by Bojan and the difficulty in reading the instructions and the lack of a clear recommended value that stops the current ongoing attacks without breaking commonly used software packages, it's clear there is still some work ahead of us.
Not only do we need to understand it in detail and understand what we can block, but we need to test it all as well.
So, in a spirit of sharing how to make it work:

What are you using as mitigation against the DLLhijacking vulnerabilities ?
What did your tests with the different values and commonly used software packages (such as Microsoft Office)yield with the different values the tool supports ?

--

Swa Frantzen -- Section 66 (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

FTP brute password guessing attacks are a fairly regular occurrence at the moment. The fact that these are occurring with regularity means that they are still working, so If you have an internet facing FTP server then there are a few things that you might consider doing to help weather the storm.
Watch your logs!

It is surprising when you work on an incident to see how long an event goes unnoticed. Sometimes months, even though the logs are full of events such as:


09:19:44 211.45.113.143 [2]USER Administrator 331 0

09:19:46 211.45.113.143 [2]PASS - 530 1326

09:19:46 211.45.113.143 [2]USER Administrator 331 0

09:19:46 211.45.113.143 [2]PASS - 530 1326

09:19:46 211.45.113.143 [2]USER Administrator 331 0

09:19:47 211.45.113.143 [2]PASS - 530 1326

09:19:47 211.45.113.143 [2]USER Administrator 331 0

09:19:47 211.45.113.143 [2]PASS - 530 1326

09:19:47 211.45.113.143 [2]USER Administrator 331 0

09:19:48 211.45.113.143 [2]PASS - 530 1326

09:19:48 211.45.113.143 [2]USER Administrator 331 0

09:19:48 211.45.113.143 [2]PASS - 530 1326

It is quite clear what is going on here. a user typing a password multiple times per second? not likely. The log shows very clearly what is going on someone is guessing passwords. In this case it was a Microsoft FTP server which was being attacked, so there is likely to be an administrator account on the system and eventually this attack result in access.
Many people don't have their logging enabled. Make sure it is switched on and watched regularly, this is something junior can do on his own.
Rename Administrator

On windows systems I like renaming the administrator account and then setting up a new user called Administrator, but without any privileges or access on the system. I set the password to something very long and then watch the logs. Even if they eventually manage to guess the password the account is not worth anything. It is a simple thing to do, but can be very effective. The FTP brute password attack above won't work and you may pick something else up as well. Simple but effective.
Remove Anonymous Access

Should you remove Anonymous access? I guess the answer depends on why there is an FTP server in the first place. Anonymous access is usually abused. When placing a FTP honeypot on the network the first files start getting uploaded, usually within the hour. So unless you really need it, remove it.
Restrict Access to FTP

In many organisations the actual use of FTP is fairly limited. There is no need for the whole internet to access the FTP serverthere may be a finite number of locations. Restrict access to FTP to these locations only, either through firewall rules, or on the FTP server itself (or even both). This will limit the opportunity for abuse of your FTP server.
The above are a few simple ways to reduce the risk of losing your FTP server to someone else. If you have some nifty tricks that will help protect an FTP service, write a comment or use the contact form.
Cheers

Mark H


(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

For the last couple of days there have been a lot of discussions about a vulnerability published by a Slovenian security company ACROS. HD Moore (of Metasploit fame) also independently found hundreds of vulnerable applications and, as he said, the cat is now really out of the bag.
In order to see what is going here we first have to understand how modern applications are built. Modern applications come modularized with multiple DLLs (Dynamic Link Libraries). This allows the programmer to use functions available in other DLLs on the system Windows has hundreds of them. Now, if a DLL is not available on the system, the developer can decide to pack it with the main applications executable and store it, for example, in the applications directory.
The most important DLLs are specified in the KnownDLLs registry key (HKLM/System/CurrentControlSet/Control/Session Manager/KnownDLLs). These are easy if an application needs to load it, the system knows that they have to be in the directory specified by the DllDirectory registry key, which is usually %SystemRoot%/system32.
However, when another DLL is being loaded, the system dynamically tries to find the DLL. Historically, Microsoft made a mistake by putting the current directory in the first place (some of you Unix oldies might remember when . was at the first place in the PATH variable). This has been fixed by Microsoft by introducing the SafeDllSearchMode setting (registry value). This setting specifies the order in which a DLL will be searched for. For example, as specified in http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx this is the search order with the SafeDllSearchMode setting enabled:
1. The directory from which the application loaded.

2. The system directory. Use the GetSystemDirectory function to get the path of this directory.

3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.

4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.

5. The current directory.

6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If multiple directories hold a DLL with the same name, the first match wins. This setting is enabled by default on Windows XP SP2.
Now, the problem happens when, for example, the application tries to load a DLL that does not exist on the system. You can see one such example in the picture below, where I found out that one of my favorite applications is very much vulnerable. See how it tries to find the DLL in all those directories before if gets to the one on the share? Both names of the application and DLL have been blacked out no point in serving this on a silver plated dish :(

Ok, so what about attack vectors. Any place where the attacker can put both the file to be opened by an application and a malicious DLL can be used as the attack vector. Obviously, as in the example above, the most obvious attack place are Windows shares so I guess we are looking at another vulnerability that uses similar attack vectors such as the LNK vulnerability last month the difference here is that by just browsing to the directory nothing will happen since the user has to open the file.
In order to protect your networks/system be sure to audit permissions on shares to prevent unauthorized users from putting files where they shouldnt be. Of course, I expect that by now you already blocked SMB and WebDAV on the perimeter so an external share cannot be used.
What about a fix? This will be a difficult one, especially since we can look at SafeDllSearchMode as a fix. So in most cases, developers of vulnerable applications will have to fix them and judging by the numbers Ive seen around we are looking at a very difficult period. Hopefully those popular applications (such as the one I successfully exploited above) will get patched quickly so the final risk will be reduced.
We will keep an eye on this and update the diary as we get more information.
UPDATE
Microsoft released several articles describing details about this vulnerability as well as offering some workarounds. The main security advisory is available here (2269637). Recommendations are basically similar to those Iwrote above, however, Microsoft also released a tool that allows blacklisting certain directories (locations)from being used for library loading. You can find more information about the tool here, and the tool itself here. The tool adds a new registry setting called CWDIllegailInDllSearch. This allows you to block loading of DLLs from shared network disks or through WebDAVclients. Of course, if you plan on deploying it, Irecommend thoroughly testing it before push it somewhere as it might break loads of things - that is probably why Microsoft doesn't push this as a security update. To be fair, this is not Microsoft's fault, but bad programming since this vulnerability has been known for years and years (although some new attack vectors have been published recently). Microsoft also released a nice document about searching DLLs that you can find on the second link above (Iespecially like how they used Process Monitor to demonstrate the vulnerability and removed the vulnerable application's name and the DLLit's loading - same as Idid in the picture above :).
Finally, Iwould like to say thanks to readers who wrote in, especially to Stefan Kanthak who shared a whole list of possible attack vectors. After spending some time going through this and locating even more, this looks extremely bad, but it is questionable if we will see wide exploitation of this vulnerability.
Let us know about your experiences with this and especially if you see someone/something exploiting this.
UPDATE2
We received some e-mails about active exploitation of this vulnerability in the wild. While there are potentially hundreds, if not thousands of applications that are vulnerable, it appears that the attackers so far are exploiting uTorrent, Microsoft Office and Windows Mail, which are, coincidentally or not, applications for which Proof of Concept exploits have been published. Remember, it is extremely easy to exploit this and it doesn't require any advanced knowledge so be sure to check Microsoft's recommendation above or be very careful about files you open from network shares.
UPDATE 3
US-CERThas released an advisory regarding this issue today. As far as I can see there isn't any new information as such. The latest version of the bulletin can be found here http://www.us-cert.gov/cas/techalerts/TA10-238A.html - MH



--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Pedro Bueno (pbueno /%%/ isc. sans. org) Twitter: http://twitter.com/besecure (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Pedro Bueno (pbueno /%%/ isc. sans. org) Twitter: http://twitter.com/besecure (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

One of the most interesting challenges of working as Chief Information Security Officer in a utility company is the variety of infrastructure types that supports the business process. I refer here to the infrastructure that supports real-time management systems for generation transmission and distribution of energy and the system that are responsible for coordinating the pumping of water to individual households and industries.

The implementation of a information security management system that includes this kind of critical infrastructure to the business processes provides a number of interesting challenges which are not covered in the conventional security model for IT processes:

Information Security risks associated to the delivery process of energy and water utility services process, can lead to disruption of both services for a large number of people in a country. If errors in the handling of SCADA equipment have been responsible of cascading effects that collapse most of the electrical system of a country, what if someone is doing an identity theft in the energy SCADA system and performs tasks such as increasing the rotation of the generation turbines, increasing the energy flow exceeding the capacity of a transmission line or simply turning off the turbines of a power plant? Imagine the chaos that would plunge a country or region.
What if in the water tanks of a city begins to overflow its maximum level and the pressure causes the pipes bursting in the streets? Imagine scenarios like the following in every city: http://www.youtube.com/watch?v=kbz_zxsJCfgfeature=related
The cost of repairing damage of any of the above scenarios is enormous. If we add the inability of the company to generate money for generation, transmission and distribution of energy, how much time passes before the company cease to exist?


SCADA systems have a very particular operating environment. Because they are real-time systems, data monitoring and orders sent to the RTU should arrive in the shortest time possible, since an additional delay of even 10 ms can mean a massive blackout by activation of the protections of a substation. Similarly, suppliers of these systems tend to provide support on these only on a specific configuration, which is usually not too safe and lacks basic security controls such as security patches, data encryption, authentication and non default configurations.

The architecture for a SCADA system is as follows:



The components are:

Remote Terminal Unit (RTU): The RTU is defined as a communication device within the SCADA system and is located at the remote substation. The RTU gathers data from field devices in memory until the MTU request that information. It also process orders from the SCADA like switch off a transmission line.
Master Terminal Unit (MTU):The MTU is defined as the heart of a SCADA system and is located at the main monitoring center. MTU initiates communication with remote units and interfaces with the DAS and the HMI.
Data Acquisition System (DAS):The DAS gathers information from the MTU, generates and store alerts that needs attention from the operator because it cancauseimpact on the system.
Human Machine Interface (HMI):The HMI is defined as the interfacewhere the operator logs on to monitor the variables of the system. It gathers information from theDAS.


Due to its criticality, SCADA operators are reluctant to implement any type of information security controls that can change the operating environment for the system. How to implement a security scheme that does not interfere with the functionality needed for the business process? We took the following items specified in the standards of North American Reliability Corp (NERC) Critical Infrastructure Protection (CIP) to implement controls for an Energy SCADA:

Project 2008-06 Cyber Security Order 706

CIP0022 Critical Cyber Asset Identification
CIP0032 Security Management Controls
CIP0042 Personnel and Training
CIP0052 Electronic Security Perimeter(s)
CIP006-2a Cyber Security Physical Security
CIP0072 Systems Security Management
CIP0082 Incident Reporting and Response Planning
CIP0092 Recovery Plans for Critical Cyber Assets

For point number two, we took the same table to classify information assets for the corporate information security management system and applied it to the energy processes:






Consequence



Value



Criteria





Catastrophic



5



a) Generates loss of confidentiality of information that can be useful for individuals, competitors or other internal or external parties, with non-recoverable effect for the Company.





b) Generates loss of integrity of information internally or externally with non-recoverable effect for the Company.





c) Generates loss of availability of information with non-recoverable effect for the Company.





Higher



4



a) Generates loss of confidentiality of information that can be useful for individuals, competitors or other internal or external parties, with mitigated or recoverable effects in the long term.





b)Generates loss of integrity of information internally or externally with mitigated or recoverable effects in the long term.





c)Generates loss of availability of information with mitigated or recoverable effects in the long term.





Moderate



3



a) Generates loss of confidentiality of information that can be useful for individuals, competitors, or other internal or external parties, with mitigated or recoverable effects in the medium term.





b) Generates loss of integrity of information internally or externally with mitigated or recoverable effects in the medium term.





c)Generates loss of availability of information with mitigated or recoverable effects in the medium term.





Minor



2



a) Generates loss of confidentiality of information that can be useful for individuals, competitors, or other internal or external parties, with mitigated or recoverable effects in the short term.





b) Generates loss of integrity of information internally or externally with mitigated or recoverable effects in the short term.





c)Generates loss of availability of information with mitigated or recoverable effects in the short term.





Insignificant



1



a) Generates loss of confidentiality of information that is not useful for individuals, competitors or other internal or external parties.





b) Generates loss of integrity of information internally or externally with no effects for the company





c)Generates loss of availability of information with no effects for the company.






From the previous table, we assigned controls to implement and ensure the security level for the asset. For point 3 and 4 we adopted all definitions from the corporate Information Security Management System. See all the required controls here: http://www.nerc.com/files/CIP-003-1.pdfand http://www.nerc.com/files/CIP-004-2.pdf.

The biggest issue here was authentication and clear-text traffic. Many devices from our SCADA system did not support authentication and also information was sent using cleartext protocols. Every time we tried to introduce a VPN or crypto level-2 devices, the network latency increased and functions of the system were degraded, which is why we had to remove those controls. When we askedour vendor for those controls as native functions for the system,we receiveda request to purchase the next version of the SCADA System.

The corporate antivirus didn't work because it consumed all the resources of the DASand the HMI. Same happened with the Host IPS. The solution we found for the problem was SolidCore S3 product(http://www.solidcore.com/products/s3-control.html), as it was non-intrusive, did not add extra layers and virtual devices to the operating system and controlled very good the zero-day problems.

For configuration changes, we established a weekly maintenance schedule in which the service of the SCADA system would stop for three hours changing the operation mode to contingency, so the IT operators could perform screening for viruses, install security patches and modifying security baselines. If the change was not successful and the system is degraded, the changes were removed and tried again the following week. This was not an easy task, because the vendor would not support us and we had to learn a lot on how the system components worked.

For point 5, We tried to redraw the SCADAnetwork socritical traffic would not mix with other type of traffic. For wireless devices, we managed to implement 802.1X authentication.Wedivided theSCADAnetwork into the following perimeters:



CiscoFirewall Service Module inside Catalyst 6509 with VSSsupervisors (VS-6509E-S720-10G) gave us the required bandwith and no disruptions were presented within the SCADA environment. It also have IPS (IDSM-2) that sends the alerts along with the log firewalls to our RSAenvision correlator.

For point 6, all the place has armored doors, CCTV, biometric authentication and security guards patrolling around the physical perimeter.

Now we are able to managethesecurity controls inside the corporate IT network and the SCADA systems. I still know that I have many things to dototo achieve the other points of NERC, butstill will be an interesting and challenginggoal.

-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Jhaddix wrote an interesting blog posting showing some tools that can be added to firefox to perform penetration testing activities. The ones I like most are FoxyProxy(for TOR navigation), Wappalizer(to recognize content management system), Add N Edit Cookies(to evaluateand inspectcookies)and SQL Inject Me(for SQL Injection).
Please read the article at http://www.securityaegis.com/hacking-with-your-browser/
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Niels Provos has done an excellent blog post on how to exploit CVE-2010-0188:An integer overflow in the parsing of the dot range option in TIFF files. Find the adobe advisory here.
More information at http://www.provos.org/index.php?/archives/85-Anatomy-of-a-PDF-Exploit.html#extended
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Several readers have pointed us to an article about the preliminary report of the Spanair flight that crashed on takeoff in 2008 killing 154. The article suggests that a Trojan infected a Spanair computer and this prevented the detection of a number of technical issues with the airplane. The article speculates that if these issues had been detected the plane would not have been permitted to attempt take off.
There is still a lot that is conjecture and unknowns at this point in the investigation and I will try not to add to the speculation, but it made me think about the parallels to information security.

In information security we often speak of controls. There are three types of controls; preventive, detective, and corrective. Predominantly in information security we deal with preventive and detective controls.
Preventive Controls aim at preventing issues before they occur. Some examples of preventive controls are policies, standards of operation, procedures, checklists, segregation of duties and change controls. From an IT technology point of view firewalls and intrusion prevention systems are popular technological preventive controls. The airline industry also has procedural and technological controls. Airlines have operating protocols covering most aspects of operations from when it is safe to fly to how to maintain the equipment. Pilots have pre-flight and in-flight checklists to ensure safe operation of the aircraft. Modern airliners have similar interlocks and safety systems to attempt to protect the aircraft from mechanical failure or human error.
Detective controls aim to detect an issue when it does occur, or as soon as possible after. In the words of Dr. Eric Cole, a notable SANS instructor, Prevention is ideal, but detection is a must! If at all possible we would like to prevent the event from occurring, but if we cant prevent the event we want to know it happened so we can adequately respond. The obvious IT detective controls are host and network based intrusion detection systems (IDS). But less technological processes such as audits are also a detective control aimed to detect and correct anomalies before they become more serious. Modern airliners also have detective systems to detect events before they are service affecting. One quote from the article, indicates a failure in a detective control occurred ... The plane took off with flaps and slats retracted, something that should in any case have ... triggered an internal warning on the plane.
I am not a pilot, so I cannot speak with authority on how to fly a passenger airliner, but it seems clear to me that this accident was caused by the failure of a number of controls leading to a disastrous outcome. Clearly the SpanAir diagnostic system (a detective control) designed to detect anomalies in the airliners system failed, possibly due to a Trojan. Also it appears the pilots bypassed part of their pre-takeoff checklist, leaving the flaps and slats in a position not recommended for takeoff. As ISC reader Frank pointed out that is most likely because the pilots had aborted the initial attempt to takeoff and most likely resumed the pre-takeoff checklist (a preventive control) too low in the checklist and missed a significant step. It is also clear that for some reason an internal system (a detective control) that should have detected the misconfigured flaps and slats for some reason did not alert the pilots to this condition.
In information security, the stakes are rarely so high as human lives, but failures in controls often lead to unexpected consequences. A misconfigured firewall rule allowing more permissive access to systems, a false negative in an IDS/IPS system, a user violating policy by plugging in a personal USB stick etc. The moral of the story is dont take your control systems and processes for granted. Audit and test them regularly to ensure they are operating correctly.



-- Rick Wanner - rwanner at isc dot sans dot org - http://rwanner.blogspot.com/ (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

We've received a couple reports lately of a bot written in Perl finding its way onto more and more Unix systems. The bot is about 110kb in size - quite chunky for a Perl script in other words.

When you search for this particular email address in Google .. well, yes, usage seems to be widespread enough. Every kid or hax0r also seems to adapt portions of the script, probably with search-and-replace, to make sure their own nick is as prominent in the script as Casper's.
Emerginthreats has a post with some good intel and a couple of Snort Sigs to detect this critter phoning home, and also links to the e107.org content management vulnerabilities for which the script contains exploits. The Perl Bot also contains other PHP remote file inclusion (RFI) exploits, but the script has also turned up on servers where PHP is not present at all. If you can share additional information on the exploits or avenues of attack used to deposit the script/bot onto servers, please let us know. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

=============== Rob VandenBrink Metafore (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

In a lot of ways, our job in IT and Information Security is implementing change. But as we all know, every change involves risk, and changes gone bad can be your worst nightmare. Ive seen the number of business system service interruptions due to changes in infrastructure pegged at anywhere from 50 to 70%, and Id lean towards the high side of that. If its not a hardware failure, its probably a mistake. Why is this number so high?'
Testing takes time, time that we often don't have. Managers will often consider every change to be simple, so getting testing time is often a challenge. We'll often be working in complex environments, environments that involve lots of people who don't care about your change until it breaks something of theirs. We often have system components in the mix that we don't know about until something breaks. We may have legacy apps that simple cannot be known - stuff that was written 20 years ago by people who have long since retired for instance.. Compound this with the pervasiveness of the GUI interface , which in a lot of ways encourages people to stumble through the menu until they find a setting that works (yes this happens, every day).



So what to do? Its our job to patch and update systems, to take projects from a set of ideas to working systems. All of this involves change, every day. Most of us have some method of change control. This generally involves forms and meetings, but dont run for the hills, its not all bad really most of it is common sense:

Figure out what youre doing

Make sure its going to work

If it messes up, have a plan

Clear it with others in your team to make sure it wont mess anyone else up (remember, theyre all making changes too)

Make the change

Tell your team mates that its done.
You can do all of this with a few emails, but as I mentioned, most of us have forms to make sure we dont forget steps in this, and we have meetings to make sure that everyone who needs to know gets told (and doesnt have the but nobody told me excuse later).



Just the facts

So lets start with the form. Its simple really. You need to describe your change in terms that your audience will understand. Your audience will usually include folks are technical, but dont always understand your job. Sometimes non-technical people will be on the list business unit people who may be affected for instance. Whoever is on the list, be sure that youre accurately describing the change, but arent talking down to them.



Youll need a plan. This needs to describe both the change and how you are going to test it. I almost always use a Gantt or Pert chart to describe my plan. Not only does everyone understand a picture (remember your audience?), but at 2am when Im doing it for real, its REALLY easy to miss a step. And an hour into it, what you DONT want to do is undo steps 4 through 15 so that you can do the step 3 that you missed the first time.



You need a backout plan. I dont know about you, but lots of things that I do fail in spectacular ways this is what makes my job so much fun. The important thing is to have a plan to deal with it.

Put a time estimate on your plan, and be sure that the change window you are requesting includes the time to make the change, test it, then back out. If you have a backout plan, then problems become what they should be - an opportunity to learn something new, rather than the political firestorm that they can become if you don't have that plan ready to go.
What is a change? Especially when change control is new in an organization, the topic of what change is will be a hot one - when do you need to fill out a change control request? How often have we had a problem that was an obvious result of a change last night, but the next morning nobody owns up to making the change? Or dealing with a change related issue that's been a problem for about two weeks, with no record of what changes were made in that timeframe? I've been in organizations where unplugging an unused ethernet cable is a change, or plugging in a power cable. On the face of it, you might think that these are both going overboard. But if you unplug that dead cable you may find out later that it's not really dead - it's only used to run that legacy accounting report at month end. Or when you plug in the new IPS unit you may trip the breaker on the PDUthat the main firewall or fileserver is plugged in to. The level of change that needs to hit the process will vary from company to company, if you're just starting out in this, no worries, just be prepared for some healthy back-and-forth as you find the level between too much paper work and enough process to get the job done
The key in determining the scope of the change management process is to make sure that it catches the changes you need it to catch, but isn't such an administrative problem that everyone hates the process. If people hate it, they won't use it and there's no point. It needs to be easy enough and useful enough so that the people in IT making system changes see it as a clear benefit instead of an obstacle.



Meetings, Meetings and more meetings OK, just one meeting, but BE THERE.

After youve got the change all mapped out, youll need to make sure that everyone who needs to know, knows. The whole point of change control is to avoid conflicting changes. Just to pick a few examples - If youre doing a firewall upgrade, it cant be when the DBA needs to VPN in to do a schema update. Or if youre doing a router upgrade, it cant be during a server migration thats on the other side of the router (yes, Ive seen both at one company or other).


The meeting before the meeting

So you need a meeting, but not immediately. In most cases, change control forms need to be submitted a few days before the meeting. This is so everyone who needs to has a chance to review the change and ask any questions. By the time you get to the meeting, you should have informal approval.



Finally the meeting

The point of a change control meeting is to get formal approval and signoff. You need to know that everyone is ok with the change, and that it wont conflict with anyone elses change. This means a few things you need a quorum, and you need the right people there. If your DBA boycotts your meetings, then theres no point in having them. Really everyone in IT needs to buy into change control, because if they dont, its their changes that will bite your company in the tender parts!
Change control meetings should be SHORT. I normally see discussion limited to 5 minutes per change discuss any last minute details, be sure that change A and Change B dont conflict, then its a yes or a no. If you go over 5 minutes, either you didnt do your homework (remember the meeting before the meeting?), or someone is hijacking your meeting.
Speaking of hijacking, change control meetings need a chair. In many companies, the chair rotates between everyone who is NOT a manager. This is a good thing for the team, as it gives people who otherwise wouldnt speak during a meeting practice in talking to actual people.It alsoemphasizes that the meeting is to make the job ofthe doerseasier - at its root change control is not supposed to be a heirarchal management function at all. On the other hand, in lots of other companies the IT manager chairs the meetings. In either case, the main job of the meeting chair is to keep it moving, to be sure that changes are approved or nixed quickly so everyone can get back to work.
Finally, any completed changes should be discussed. The point of this is to continually make the process better. Reviewing completed changes is all about making sure that the testing process is good, and that people are writing good implementation and backout plans.
Doing the Deed

When you are making your change, follow the plan. Sneaking in little changes here and there will only cause you grief. If you have an hour approved, the backout plan is 10 minutes and you are at 50 minutes and still typing, you should bail. Going over on changes is an unscheduled outage, which everyone takes a dim view of. If you needed 70 minutes instead of 60, or even 2 hours, ask for that up front. If you've got a plan and a process, this all get simple, and you get to make that change (aka - real work) in peace!


Iwrote this diary because Iend up talking to one client or other about change control processes a few times per month - it's a pretty popular topic (especially when you're convincing people who don't have a process that they need one). I've attached a a sample change control form below. If you find them useful, feel free to modify this and use it in your organization (or not). Over the years, I've seen change control implemented as Word documents in a shared folder or paper binder (this doc goes back almost 20 years), small access databases, as functions within Helpdesk systems, or recently everyone seems to havea need to write these in Sharepoint. The mechanics of how you implement your process is not important, it's the fact that you implement a process that will make your changes successful !


If you have any thoughts, or if I've missed anything, please feel free to use the comment feature on this diary. I'll update this article as the day goes on, based on your input.

=============== Rob VandenBrink Metafore =============== (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

UPDATE
Looks like some patches have already been released. More details can be found herehttp://www.adobe.com/support/security/bulletins/apsb10-16.htmlPlease note these are for the Flash Player only, still waiting on the Reader updates.

Happy Patching - MH

Adobe is planning to release critical updates on August 19, 2010 for Adobe Reader 9.3.3 for Windows, Macintosh and Unix as well as the Adobe Acrobat 9.3.3 for Windows and Macintosh and an update for Adobe Reader 8.2.3 and Acrobat 8.2.3 for Windows and Macintosh covered in security bulletin APSB10-17. This is the same issue discussed at Black Hat USA 2010 identified in Adobe Flash Player published in security bulletin APSB10-16. UPDATE
Affected Software
Adobe Reader 9.3.3 and earlier versions for Windows, Macintosh, and UNIX

Adobe Acrobat 9.3.3 and earlier versions for Windows and Macintosh

Adobe Flash Player 10.1.53.64 and earlier versions for Windows, Macintosh, Linux, and Solaris




-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

In June and July I posted two diaries (http://isc.sans.edu/diary.html?storyid=9085 and http://isc.sans.edu/diary.html?storyid=9103) in which I analyzed one campaign used by the RogueAV guys and various scripts they utilize. Last week Dancho Danchev posted a blog about mass compromises of .NL and .CH sites that are utilized in yet another RogueAV campaign (http://ddanchev.blogspot.com/2010/08/dissecting-scareware-serving-black-hat.html).
This campaign is different from the one I described in two diaries above, judging by the code it is probably a totally different group, although some of the functionality is the same. In the previous campaign attackers infected all PHP files on compromised sites while here they only used one PHP script. So lets dig into it and see what and how they do it.
The first step in this campaign was to compromised as many web sites as possible in many cases we were looking at mass compromises where a server hosting hundreds of web sites was compromised. The attackers planted one file (usually called page.php or wp-page.php) on every web site they didnt change anything else.
The page.php script does the majority of work. Similarly to the one I described in June, this script actually just asks the main controller what to do when it receives a request. The request sent to the controlled is interesting it downloads another PHP script from the controller and executes it via an eval() call. This allows the attackers to be able to constantly change how any script behaves.
This master script, in a nutshell, does this:
First it checks if the request to the page.php script contains the r= parameter. If it doesnt (meaning, you accessed the script directly) it displays a 404 error. Clever, so they hide it if you try to access it directly.
Now, if the User Agent shows that the request is coming from a Google, Yahoo or Bing bot, special content is returned (more about this below). If you visit the script directly (no referrer) it again displays a 404 error. Finally, if the referrer is set to Google, Yahoo or Bing (meaning, the user clicked on a search result), the browser is redirected to a third site (and possible fourth) that displays the infamous RogueAV warnings.
Above is the standard modus operandi of the RogueAV guys you can notice that this is almost exactly the same as the campaign I analyzed back in June, although the scripts are completely different.
The most interesting part happens when a Google, Yahoo or Bing bot visits the web page. Since this visit is actually the bot crawling the content, the script has to return the correct content to poison the search engine (otherwise it would not be related to the search terms the attackers use).
So, in order to return relevant content, the master script does the following:
First it queries Bing by using the same keyword that was used by the crawler. You can see that part of the script below:

You can see above how they nicely create the query and ask for 50 results. These results are parsed by the script and saved.
Now comes the interesting part: they get the main (index.html) page on the compromised web site with the following code line:

$index_html = file_get_contents(http://
The retrieved index.html file will be used to serve back to the bot. First the attackers remove any JavaScript from the file. After this, they change the title of the web page:

$index_html = preg_replace(~title[^]*(.*?)/title~is, title.htmlspecialchars(ucwords($keyword)). - $1/title
This will expand the old title with the keywords that they used to poison the search engine. The following pictures show the original HTML document (the real index.html) and the modified one (blacked out the title to protect the compromised web page). Notice how they added the keywords at the beginning of the title tag (and one extra blank line):
Original index.html:

Modified index.html:

Now they retrieve 100 links to other compromised web sites from the controller and insert these links, as well as results retrieved from Bing into the final index.html page. This page is then returned to the bot.
Such content clearly works much better when poisoning search engines than the one I described back in June yesterday I checked Google and I was able to find thousands of poisoned results pointing to such compromised web sites. While the search engine operators do a lot of work to prevent poisoning like this, it is clear that the bad guys are not resting either and that they are developing new poisoning techniques constantly.
--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

During Black Hat USA2010, Patrick Thomas presented a new web application fingerprinting tool called Blind Elephant (http://blindelephant.sourceforge.net). The tool uses the same techniques I've been using for a few years now, manually or through custom scripts, during web-app penetration tests to identify the available resources on the web application, and based on them, categorize its type and fingerprint its version. This methods apply particularly well to open-source web application and blogging frameworks, and CMS's, such as Drupal, Joomla, Wordpress, phpBB, phpMyAdmin, etc, as you can check the resources available on the source code for a specific version, and compare them with the resources of the target web-app.
Patrick took this idea seriously and created a Python-based tool. He has precomputed the hashes of the known files and automated the process. You can get more details from the original Black Hat presentation, or the updated version (v2). The tool is very useful from two perspectives:defensive and offensive.
On the one hand (offensive), to incorporate the tool to your pen-tests activities in order to fingerprint more accurately the target environment. On average it takes less than 6.5 seconds to fingerprint the web-app, with an average precision of three candidate versions (and the bandwidth compsumption is also very low).
On the other hand (defensive), to collect global details about the current state of the web portion of the Internet. The presentation provides results about the web application versions available out there, as well as the version distribution and real update status for the major players. The goal was to answer the following question:What % of (active) sites on the net are running a well-known webapp?. Iwould personally add ...a well-known VULNERABLEwebapp?. The results of this global analysis are pretty scary but match what Icommonly see on pen-tests. Just to provide you the insights of the phpMyAdmin vulnerability mentioned on a recent ISCdiary (from the tool author):
Scanned on June 18, the % of net-visible phpMyAdmin installations unpatched against PMASA-2009-3/CVE-2009-1151: 60.75%

(52.2% are running a vulnerable version in the 2.x branch, 8.6% are running a vulnerable version in the 3.x branch)
Please, use this tool and its results to create awareness and force people to patch web infrastructures and applications, and help them to improve the update process! Iknow this is easier said than done, but if you are still running a vulnerable web application more than one year after the vulnerability was announced, you are asking for trouble.
The project is looking for contributors, so its an opportunity to make a difference and help to make the Internet a more secure place.
----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

About a year ago, I wrote a diary here at the ISC called Putting the ED back in .EDU. Like most of the stuff I write, it caused a bit of a stir when it was published, because it pointed out that several .edu domains were riddled with compromised machines serving up link-fodder for peddlers of erectile dysfunction (ED) meds. And, oh yeah I named names.



All of this ruckus was caused by me using a little bit oGoogle-fu, to see what big-G had to say, specifically, in response to searches like these:



site:.edu buy viagra (link)



site:.gov buy cialis (link)



Its a hobby: some people collect coins, some people knit I look for compromised websites.



Being the pessimist that I am, when I re-whipped out a couple of those olGoogle-dorkin chestnuts the other day, I was pretty sure that I would still find some new best friends to chat with about their site security. (Note: If you get an unexpected phone call from me, its rarely what you would call good news.)



I wasnt disappointed.



While its been a bit over a year since I that piece was published (and three years since I originally pointed out the fun that a few choice Google searches could create) there was no shortage of joy to be found in this latest go round.



However, amid my ironic chucking and the pitter-patter of emails being fired off to various webmasters, I happened upon something that caught my interest.



It started off innocently enough: the library website of a small educational institution had been 0wned. I followed the link from my Google search to the library site and was quickly redirected to another page hawking enough sildenafil citrate to straighten up the Leaning Tower of Pisa. Heheheh...



Being the all-around nice guy that I am, I hit up the main web page of the school trying to find some contact information. While poking around, I noticed a link to the Librarys site right there on the front page.



Hmm, I thought to myself, you gotta wonder how long this sites been 0wned without anyone noticing. And I clicked the link.



A funny thing happened. The library page appeared.
Obviously, something odd was going on here. It was like a single website with two distinctly different, Jekyll and Hyde personalities...

(Somewhere, Robert Louis Stevenson is spinnin' in his grave like a top...)



Looking back and forth between my Google results and the schools main page, I fairly quickly determined that the URL at least appeared to be the same.



Just to be sure, I clicked through the Google page again and it took me right back to pharma-R-us



Then my wife called me for dinner.



Now I dont know how things are where you live, but in my house, when you get called for dinner, you go. Delay means a very quiet dinner with a side-dish of disapproving looks and no dessert.



One contented family meal later, and I returned to my desk, still intrigued.



Having closed out the browser before I left (look when you regularly search using terms like viagra, cialis, and levitra you find yourself getting into the habit of closing your browser when you leave trust me), I fired up a quick Google search based on the name of the school and the word library. Boom, there was the same link with the same sample chunk otext talking about the same virtues of cheap pharma.



So, I clicked on the link and landed on the Library site.



At that point, I clearly and loudly defined the meaning of the acronym WTF.



Now Im not always the quickest bunny in the forest (example: when I heard that Apple was patching flaws in iOS I immediately thought Thats really nice of them. I hope Cisco says thanks.) so I sat there scratching my well, lets say head, and thinking.



After a few moment's thought, an idea struck me.



Ouch.



I fired up the Tamper Data extension for Firefox, kicked it into tamper mode, and clicked on the home link on the Library page.



When Tamper Data offered me the opportunity to tamper with the request, I gladly accepted. I replaced the contents of the Referer (this is why we cant have nice things nerds cant spell) field with:



http://google.com/search?q=cialis



fired off the request, and lo! I was in erectile dysfunction heaven.



(Note: its like normal heaven, but the robes fit funny)



So whats going on here?



While I talked to the folks at the schools library, I wasnt able to get code from them. However, armed with what I had learned from finding that site, I was able to find several others, and heres what appears to be going on:



When the Ev1L H@x0rz compromise the site, their goal is pretty simple: they want to change the content of the site itself to increase their positioning on the search engines. The whole idea would be ruined, however, if they gave away the fact that they'd 0wned the site. So the idea is to use the site not abuse it.



Rather than mucking around with the code for the site itself, the bad guys target the .htaccess files. For those of you unfamiliar with the workings of webservers, .htaccess files are used by the Apache webserver (and some others) to provide a way to make configuration changes to the server itself, on a per-directory basis. So, for instance, you can use an .htaccess file to change the way that the webserver treats specific types of files in a single directory only.



The bad guys also leverage another Apache tool, known as mod_rewrite. This tool provides a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly.



So, while I never actually got my hands on an altered .htaccess file, I have a pretty good idea of what they look like:



RewriteEngine On

RewriteCond %{HTTP_REFERER} .*google.*(cialis|viagra|levitra).*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*yahoo.*(cialis|viagra|levitra).*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*bing.*(cialis|viagra|levitra).*$

RewriteRule .* http://badsite.com [R,L]



Somewhere in there, they likely also have a rule that serves up different content when it thinks that Google-bot is coming to call. I tried to trick it into doing that by switching the User-Agent of my browser to mimic Google-bot, but it didnt work. (My guess: theyre combining User-Agent matching with some Google-ish IP address ranges, or something else entirely)



So, whats the moral of this tale about the two faces of a single site? Beware, dear reader. Just because your site looks normal to you, just because your site looks normal to the bulk of your visitors, you still may have been 0wned. Constant vigilance is the only means of protecting your site, and your reputation.



Stand up tall: be aware and be vigilant.



And if youre having a little trouble standin tall, I know a library website you can visit.



Tom Liston - Handler - SANS Internet Storm Center

Senior Security Analyst - InGuardians, Inc.

Director, InGuardians Labs

Chairman, SANS Virtualization and Cloud Computing Summit

Twitter: @tliston

My honeypot tweets: @netmenaces (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

During this year we wrote only a few times about DDOS(Distributed Denial of Service)attacks, referencing a report from 2009, and a couple of attacks in January and August.
On March 2010, Team Cymru released a 4-part series of videos (Episodes 42-45) and a related paper covering the basics of DDoS, a good resource to point novice people to.
However, although DDOSis still a prevalent threat, the research, improvements and information sharing in this area seem to have decrease during this year, even with all the new and growing botnets out there, most of them implementing DOS or DDOS capabilities. Obviously, some attack reports become public, while some other DDOSincidents never see the light.
We would be interested on hearing you, and know about your experiences: what are the latest improvements on both the offensive and defensive sides, what are the solutions security vendors and service providers are offering you worldwide, what are the latest attack techniques, what are the most effective tools to detect and mitigate the attacks, what is the current underground offering (DaaS, DDOS-as-a-Service)? (...the list could go on and on)
You can share the details with us through the contact page (include DDOS in the subject) or the comments section below.
----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

The Seven Deadly Sins of Security Vulnerability Reporting pretends to become an easy to follow list, not very technical but security relevant (so that anyone can point people to it), for any organization, commercial company, and open-source project in order to improve the resources and procedures they put in place to be notified (by external security researchers or third parties) and act on security vulnerabilities on their official web site(s), services, or any of their products



This is a scenario we (Internet Storm Center handlers) frequently find ourselves at, when notifying findings during our daily activities, or acting as a vulnerability reporting proxy for other researchers.



Below you can find the summarized list, while the additional reasoning and comments for every item are available on the original post I made on Taddong's Security Blog.

Communication channels:)?
ACK (Acknowledgment): How can the researcher know you have received the notification?
Verification:How do you know if the notification is related with a new vulnerability (0-day) or is a well known issue?
Interactivity: Once you confirm it is a new vulnerability, design a plan to fix it, and keep all parties involved informed about how the plan progresses.
Researchability: All the previous sins provided guidance to the organization that has the responsibility to fix the vulnerability, but... what about the security researcher that found it?



Bonus:Once a fix for the vulnerability is available and it is finally announced, provide credit where appropriate.

I strongly recommend you to go through the list during this Summer, identify what sins you can redeem in your environment, and implement the changes on September. Let's get ready for the new season!
Please, share with us any finding or remarkable situation you might have found when reporting vulnerabilities (or when someone reported vulnerabilities to you), through the contact page or the comments section below.
----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.