• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

We have been hacked... appreciate any help...

Explorer ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Running CF Version  9,0,1,274733

One of our error reports showed:

----------------------------------------------------------------

Error Page: /CFIDE/beta.cfm

Query String: page=quickly

HTTP Referer: [removed for this post]/CFIDE/beta.cfm?page=quickly

Diagnostics: ColdFusion could not delete the file C:\ColdFusion9\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\session_log0.txt for an unknown reason.

----------------------------------------------------------------

This pointed us to that beta.cfm file that was somehow put into the CFIDE root.  No FTP access to that directory and they have cleared the CF logs so no real record of what might have been done.  Did find a few CF files that had been modified around the same time but nothing in them seemed out of the ordinary.  Have removed access to them for now to be safe.

Any suggestions on where to start to figure out how they got that file into the CFIDE root?  I do have the file (moved out of CFIDE) which I can supply but it's encrypted...

Appreciate any help.

Views

1.2K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Hi Fred,

Very sorry to hear that.

My guess as to how the file got there would be by exploiting APSB13-03 using that exploit attackers can create a scheduled task that writes the result of the task to a file (typically under /CFIDE because the mapping always exists and is often publicly exposed).

For CF9 you cannot be sure what hotfixes are applied by just the version number, so it is hard to say if you have applied the hotfix for that, however even if you had applied the hotfix an attacker might have exploited it years ago and left a backdoor on your server. FYI my company has a product called HackMyCF which does a scan of your server to determine which hotfixes are applied, it can even find some backdoors.

My advice when dealing with a hacked server is always to start fresh, new server, new CF install, and then review the application source code before putting it on the new server (to make sure other backdoors have not been added).

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Thanks Pete.  Appreciated.

We actually signed up for your HackMyCF product about an hour ago.  Having Ben Forta recommend it put it high in my books.

We had all hotfixes aside from APSB14-23 installed and now that one has been added as well.

We also limited access to adminapi which was exposed.  For quick fix just used iis request filtering but will look at the correct way to do it since request filtering stops us from accessing cf admin panel even locally on machine.

Shows we now just have 1 important (CFTOKEN is not a UUID) and 6 warnings.

And I agree about starting fresh but not something we can do quick enough not to majorly impact our clients so looking to hopefully deal with current situation and buy the time needed.

In the http.log I'm seeing a lot of lines of:

----------------------------------------------------

"Information","jrpp-58","11/23/15","16:04:54",,"Starting HTTP request {URL='http://lineronline.com:80/cgi-bin/vc.cgi', method='get'}"

"Information","jrpp-58","11/23/15","16:04:54",,"HTTP request completed  {Status Code=200 ,Time taken=297 ms}"

----------------------------------------------------

Possibly related?  And how would you deal with shutting that down regardless if related or not...

Any further thoughts?

Thanks again.  Any and all help very appreciated.

Fred

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Thanks for signing up Fred!

Yes request filtering is a good way to go, I would setup a dedicated website that you use to access the CF administrator. This stuff is all covered in the ColdFusion 9 Lockdown Guide  as well so I would recommend looking through that and following any steps you can. Also CF9 is considered an End Of Life product by Adobe, you should plan on upgrading to CF10 or CF11 so you can get the latest security hotfixes.

As for figuring out that http call, I would search your server for cfhttp calls and inspect them. You mentioned that the file might have been encoded using cfencode, you can look for encoded files by searching for files containing the string: SourceFile  /

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Thanks Pete.

Looks like a great product to get a quick summary of things to look at.

Will definitely revisit the cf9 lock down guide and we are planning to migrate in the not too distant future.

Did a search for any files modified around the time of the intrusion and did find a whole bunch of .class files in: C:\ColdFusion9\wwwroot\WEB-INF\cfclasses\

Which had modified date/time around that time.  Any easier way to deal with that aside from a full CF reinstall?

Thanks again for your help.

Fred

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

P.S. - can you give a little more details for searching "server for cfhttp calls and inspect them".  Are we talking CF logs or IIS logs?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Got a little more familiar with that cfclasses directory.  Worried a little less now.... will just delete all those and let it rebuild new ones as it needs.  I believe shouldn't be any issues with that?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Nov 23, 2015 Nov 23, 2015

Copy link to clipboard

Copied

Fred, 3 things.

1) There’s no issue with deleting the cfclass files, no, but it’s also not the solution to your problem, either. They represent CFML templates that had been compiled. They will be recreated when next executed..

So Pete was referring to your searching the codebase (your CFML) for references to such CFHTTPs as you found being logged. A great tool for doing that is File Locator Lite, from mythicsoft.com.

2) You had also asked them about how to shutdown the cfhttp calls. Note that you could use CF’s Sandbox security feature (or as it as called in CF9, if you were on CF Standard, “Resource Security”). This is an optional feature of the CF Admin, in its Security section. With it, you can limit such CFHTTP calls so that they can call only specific named (whitelisted) domains/IP addresses and ports. But do beware of a couple of things:

- you do have to then list ALL the domains/IPs you WOULD want to support being called via CFHTTP, and then any NOT listed would be blocked

- this feature is not only limiting CFHTTP calls, but ANY tag/feature in CF that calls out to a remote server, including CFMAIL, CFPOP, CFFTP, web service invocations, rest invocations, and more

- it only takes effect if you DO enabled the security feature (checkbox at the top of the security page)

- in CF Enterprise, the feature is called Sandbox security, and you can setup different controls for different code running in different directories (but of course you could setup one sandbox for all your code as found in a given location)

- in CF11, Adobe has moved this “sandbox” security feature to CF Standard, but since you’re on CF9, that’s a moot point

3) Finally, you referred previously to locking down the adminapi causing you to be unable to access the CF Admin. That should not be so. The CF Admin does not use the adminapi (via http, that is, as would be blocked by request filtering).

Hope that’s helpful.

/charlie


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 24, 2015 Nov 24, 2015

Copy link to clipboard

Copied

Hi Charlie,

Thanks for the added info.  You and Pete have been a great help.

On the cfclass files, I wasn't familiar with them so at first thought it was some cf server core files.  Once I realized what they were, I wasn't worried.

Regarding the cfhttp calls being logged, I searched but that particular url/site is nowhere in our code on any of our sites or in the CFIDE directory.  So wondering how else it might be getting called?  Any ideas?

For search by the way I use Agent Ransack.  Great piece of software though always thought the name might not be the best for marketing it for what it actually does.  I think for many might have negative connotation.  Great software though.

Thanks for all the info. on locking down cfhttp.  I've looked before at the whole sandbox aspects of CF but will probably take a closer look after this incident.  All good on the CF admin.  Basically used request filtering to shut down access to the key admin directories and then just created a single site that didn't have those request filters in place but only allowed access from local ip.  Worked like a charm.

All seems to be quiet on the server again and the beta.cfm file hasn't shown back up since the latest set of changes.  Monitoring closely.

Thanks again to you and Pete for all the help.

Fred

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 24, 2015 Nov 24, 2015

Copy link to clipboard

Copied

Hi Charlie and Pete,

All still nice and quiet here but still getting lots of:

-------------------------------------------

"Information","jrpp-1015","11/24/15","19:23:23",,"Starting HTTP request {URL='http://lineronline.com:80/cgi-bin/vc.cgi', method='get'}"

"Information","jrpp-1015","11/24/15","19:23:24",,"HTTP request completed  {Status Code=200 ,Time taken=306 ms}"

--------------------------------------------

in our http.log file...

Any thoughts on how to block and how those calls are being done anyways?

Thanks,

Fred

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 24, 2015 Nov 24, 2015

Copy link to clipboard

Copied

Might have solved the lineronline.com issue... if so, might be back to all known issues resolved... just wanted to update you both as really appreciated your help.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Nov 25, 2015 Nov 25, 2015

Copy link to clipboard

Copied

Fred, thanks for the update, and the good news.

Would you be willing to share where you found those bogus calls (since it stumped you at first)? It may help others. I'll say that I would have proposed using the search tool to search any and all CF files and extensions (*.*cf*), on all drives, because it could be that the bad guys somehow put the code to do it somewhere where you may not think to look, but that they had enabled to be executable from within CF.

As for your previous note, and with regard to your preference of AgentRansack as a search tool, just note that that is the same thing as File Locator Lite. 🙂 I love it too, and have blogged about it for years. In fact, I complained of the same concern about the AR name to the vendor, explaining that I'd recommend it to people only to find later that it was removed because the name scared off others who saw it on their server. At first the he was reluctant to change the name, but did finally, offering it with both names, but for some reason still preferring to list AR as the "main" version of the tool as he offers it on the site. 😞

Anyway, glad to hear that you feel all is well for you now.


/Charlie (troubleshooter, carehart.org)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Nov 26, 2015 Nov 26, 2015

Copy link to clipboard

Copied

LATEST

Thanks Charlie.  Definitely starting to breath a little easier...

Definitely happy to share and hopefully can help someone else... ended up finding two places those http calls were being made...

Step 1 was to look in the http.log file of Coldfusion to find out the URL that was being called.  I then searched for it in all the site code directories.  I found our first of two URLs in a .js file that was uploaded into one of the sites.  So definitely don't just search for a particular extension... search for any files/extension when looking for that URL string.  The second one was trickier... it didn't show up anywhere in either the site code or in the CFIDE... ended up finding it by looking for it in any file on any of the hard drives.  It showed up in a class file in cfclasses.  Looking at the top of that file contents, I found the original source file name.  Ended up being:  c:\Windows\msapps\msinfo\index.cfm  ... and it was an encrypted file so would have never found it by just looking for the URL search term or by only looking in site folders.

Lesson learned here was to keep a much closer look at the daily logs for strange activities...

Will keep a close eye to see if anything else shows up... hopefully we're good now till we get the server completely rebuilt from ground up to be safe.

One thing I will have to look into more is if there are ways to make the logging a little more robust so that it lists which file made the http or ftp call... that would make things A LOT easier...

Funny about Agent Ransack.  Definitely not a very good name for such a wonderfully powerful and useful tool.  Sounds like the Vendor is just too emotionally tied to a name they came up with and not really understanding how others might perceive it or how it might hold back some users from using it at all.

Thanks again!

Fred

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation