Skip to main content
M
miki
Known Participant
February 20, 2019
Question

Need to track an outgoing call to another server on prod

  • February 20, 2019
  • 3 replies
  • 974 views

I am limited as to what i can do with the server, however i really need to verify that the code on a particular page is calling the right url into an iframe.

CF Server: Cold Fusion 11 (11,0,15,311399)

Web Server: IIS  on Windows 2012 R2

I cannot do the following:

  • turn on debugging
  • modify the JVM
  • install packet sniffers
  • modify the code to write the log file directly

I've reviewed the most recent IIS and CF logs on my dev environment and i couldn't locate outgoing calls.

Can any of you recommend some other options?  Is there a log level i might be able to turn on in CF that will capture this information?  What about IIS?

Thanks

    This topic has been closed for replies.

    3 replies

    M
    mikiAuthor
    Known Participant
    May 15, 2019

    So sorry, i had actually come up with a workaround. 

    We weren't hacked.

    I had found a configuration issue that had my dev server calling my uat report server instead of the dev one. FWIW i solved it by putting the "url" being called into a session variable and turning on debugging.  It doesn't work on prod, but we don't test on prod. For prod, we brought down the lower environment report servers and since the prod report appeared, we knew prod was calling the prod report server.

    I am so sorry to have abandoned this, but i tend to post and forget, especially when i find a work-around that works. I learned a lot about how to phrase requests better today.

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    March 3, 2019

    miki​, check out the log file, coldfusion-out.log.

    Its default location is {CF_INSTANCE_DIR}/logs/coldfusion-out.log.

    There ColdFusion logs requests to other servers.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    March 5, 2019

    BKBK, actually, what you refer to would be calls from CF via cfhttp, right? To be clear, Miki had indicated in his original quesiton that he needed to "verify that the code on a particular page is calling the right url into an iframe." Because it refers to an iframe, that's why I (and Dave) presume that Miki is referring to generated HTML that is making that call, rather than a cfhttp.

    And FWIW while such cfhttp calls do indeed show up in the coldfusion-out.log, it's actually because they are tracked in the http.log, but that happens also to be imported (as are a few other CF logs) into the coldfusion-out.log. Just sharing that for any benefit to readers.

    Of course, I realize you are trying to help Miki, as are we all. It would be great if they might respond to any of our 4 replies since Feb 20. Then we'd know for sure, rather than being left to guess.

    /Charlie (troubleshooter, carehart. org)
    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 21, 2019

    miki, if by this you mean you are trying to track when some code in HTML (like javascript/ajax/jquery) might call out from an HTML page YOU have served to some OTHER server, no, you won't be able to track that or prevent that with CF.

    That page is running in the browser, not in CF. And if the code calls to another server, CF never knows.

    I think I know the problem you're dealing with (your site having been hacked, and bad guys causing your page to have been changed, to have it do just this, and send THEM the info your users are entering).

    If that's the case, it's indeed tragic. But I can't see any way for CF to "track" or "log it", let alone "prevent it". It's a conversation between your client's browser and that "other" server. CF doesn't even KNOW about it.

    So you may wonder next, "couldn't I detect if my code is somehow sending TO the user a page that tries to call to ANOTHER server"? And the answer there also is no. Or not easily. What would you look for? And even if you may see some particular jquery or javascript method that you don't use, the bad guys could use some OTHER method.

    (And you can't add code ON your page that was hacked, such as to have it somehow tell YOU via the jquery or DOM when an outbound call it made to it, because if the bad guys could edit the page to put the bad code there in the first place, they could edit it again to remove your check.)

    So as may be clear, really the only solution is to a) remove the bad guy code, b) remove their ability to edit files (it's usually a shell script that's been put on your server somewhere, that lets them have unfettered access to files on your server, or at least those files that the user running CF can access--which is all your CF and web site files), and then c) you need to close the hole that allowed them to get on your server code that allowed them to edit files.

    For some, that's about adding either of the last two recent updates (to CF 2018, 2016, and 11), which implemented code to block a known hack. (Sadly, there have been troubles with the most recent update, released last week, so I know that puts some in a bind--wanting it for the security fixes, but not for the other things that broke some processing.)

    But I will say that there are still other vulnerabilities that can happen, that have long existed, and are not fixed. One has to do with how CFFILE action="upload" (and its default of STRICT checking of mime types) does NOT check for allowed file extensions, and a bad guy could upload an image as an executable file extension, but with some executable content in it (whether CFML in a cfm page, or .net in an ASPX page). And the problem is that if you put that uploaded file onto a web-accessible folder (as folks typically would for uploaded images), then that code can now be EXECUTED.

    I plan to do a blog post on this, but in the meantime, you could declare (in your web server) that cfm and aspx (and asp) files are NOT allowed to be run in the folder where users upload files. That would "stop" this sort of attack. There is much more to do and to consider, and that's why writing a post will take time.

    But your question here sounds a LOT like the situation a client of mine recently had, and this is what we found (what you describe, and then I relate) and this is what we did (the fixes I describe).

    Let us know if it helps. Sorry if much of it may NOT apply to you. Hope it may help someone else, until I get that blog post written.    

    /Charlie (troubleshooter, carehart. org)
    D
    Community Expert
    Dave WattsCommunity Expert
    Community Expert
    February 21, 2019

    "So as may be clear, really the only solution is to a) remove the bad guy code, b) remove their ability to edit files (it's usually a shell script that's been put on your server somewhere, that lets them have unfettered access to files on your server, or at least those files that the user running CF can access--which is all your CF and web site files), and then c) you need to close the hole that allowed them to get on your server code that allowed them to edit files."

    Just to focus on this for a minute, for the benefit of the original poster:
    a) ideally, you have daily snapshots of the codebase and assets,

    b) CF applications do not need to have the ability to edit files, unless you're explicitly using CF to allow users to create content - but by default, CF on Windows does have this ability.

    Dave Watts, Eidolon LLC

    Dave Watts, Eidolon LLC
    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 21, 2019

    Great points, Dave. And they expand somewhat on my point c (close the hole). We (and others) could both say lots more, of course.

    Indeed, this is why I said I was waiting to do a blog post on all this, because there are in fact so many factors to consider for folks facing (or fearful of) such a breach, from things to beware CAN happen, to finding what DID and how, to mitigate the impact, to handling the aftermath, to avoiding it in the first place, and so on. Of course, some of that goes beyond CF itself, but when folks without dedicated IT staff are hit like this, they are in desperate need for all that and more.

    It was because I'd really want to gather that up before doing a post that I'd not done it yet. If you (or others) may know of some good one that interest readers may want to check out, feel free to share.

    And again, Miki, I realize we don't KNOW that's what happened to you. It just "had that smell", and because I'd helped someone else with this just last week, I wanted to share what came to my mind as I was writing in reply to your main question.

    /Charlie (troubleshooter, carehart. org)
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices