I appreciate the reply and I'm going to read through the links that you posted. I did not mention they are still running CF7. I will definitely pass your name along for a quick remote fix if I am unable to lock things down more to prevent this from happening in the future.
Thanks again. Jeff On Sun, Nov 10, 2013 at 10:49 PM, Charlie Arehart <[email protected]>wrote: > 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 FusionLink <http://www.fusionlink.com> > -------------------------------------------------------------
