Well, Jeff, it could be any of a number of things, but I think you're on the right track that it's more of a config thing than a code thing.
My first guess (from helping others with a similar kind of breakin) is that the bad guys may have gotten in through the CFIDE/componentutils folder, which many leave open to public access (requiring a login, but still vulnerable). There's a certain URL they can compose that can allow them to edit/upload files. Since few CF folks really use the CFC browser which the componentutils provides access to, or they may not want it open publicly (even though it does offer a login prompt), this is one of the folders you can and should block entirely like the CFIDE/adminapi. If you're on IIS 7+, is "request filtering" feature is the best way. I discuss that and other options in a series of blog entries I did earlier this year, when a similar but different exploit happened starting late last December. See the 3-part series at: http://www.carehart.org/blog/client/index.cfm/2013/1/ Now, you'll notice that the latest entry of the 3 talks about an Adobe hotfix that addressed the particular vulnerability then (in the adminapi). But here's the thing: you really need to lockdown these vulnerable folders within the CFIDE (like adminapi and componentutils), because the bad guys can and do come up with new ways to get in even after Adobe plugs one known hole. They do mention in the technote for that Jan 13 security bulletin (http://www.adobe.com/support/security/advisories/apsa13-01.html ) that you should lock down those folders. They also mention locking down the CFIDE/administrator. That's a bit different. While if you don't use the features provided by those other folders at all (adminapi and componentutils) you can entirely block them, you probably don't want to do that with the administrator directory, though you may want to reconsider how accessible it is. The login prompt is not enough: you should add IP address restrictions or additional web server authentication to limit who can even see that (and therefore all the files in that administrator directory). Again, I discuss that further in those 3 entries. Finally, your bad guys may be exploiting an old FCKEditor code deep in the CFIDE/scripts/ajax folder. The problem is that you can't just block that folder (or indeed the CFIDE/scripts or the whole CFIDE folder) if indeed you use CFML code that generates HTML that relies on that CFIDE/scripts folder. Now, you could block it (the FCKeditor code) if you absolutely KNEW that your code never used it, using the same approaches I discuss in the entries. But if you can't block it, I'll warn of another potential problem: It could be that you HAVE (or someone on your server HAS) applied hotfixes that addressed previous FCKEditor vulnerabilities, but you/they may have made a mistake in applying the update. I see many people who maybe apply a given CF update/hotfix to ONE copy of the CFIDE, but then they have another that they don't realize is in use (as a real or virtual directory in one or more web sites) but which they DID NOT update at the same time, and therefore remains vulnerable. I discuss that problem here: http://www.carehart.org/blog/client/index.cfm/2011/10/21/why_chfs_may_break Hope some of that may help you. You can also learn more about some aspects of what I discuss above, and really a LOT more, in the Adobe CF LockDown Guides, available for CF 10, 9, 8, and 7. I point to those in the blog entries as well. If you don't want to wade through all that info or perhaps may not trust yourself to properly get these blocks and updates done correctly, I can help with that by way of short-term remote assistance, with satisfaction guaranteed. More at the consulting page at carehart.org. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Howard Sent: Sunday, November 10, 2013 9:30 PM To: [email protected] Subject: [ACFUG Discuss] AVG exploit blackhat seo type 1703 I have a client that has a user that uses AVG that had the alert "exploit blackhat seo (type 1703)" pop up on a site that I do maintenance for. This happened a few months back and it seemed unfounded. I got an email saying that it is happening again and this time when I viewed the source code for the page there was a bunch of injected links at the bottom of the page. I've been researching for awhile now and I'm having a hard time figuring out how the exploit happens (understandable) but I'm also having a hard time finding how to prevent it from happening again. Does anyone have any experience in dealing with this? If so, what steps can I take to prevent it? Something that is kind of confusing me as well is that client's client has 2 separate domains on their server. One is the site that I do maintenance for, the other I have no access to but they are both displaying the same error/alert. This makes me believe that it may be more server security than web site security. If anyone has any experience or knowledge they can share on this issue, I gratefully thank you in advance for your assistance. Thanks, Jeff ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
