Question re: hidden iframes

Discussion in 'other security issues & news' started by eyes-open, Oct 7, 2007.

Thread Status:
Not open for further replies.
  1. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    A bit late in the day I know, but the Bank of India hijack got me wondering.

    Is it possible for a page to host a hidden iframe that isn't detectable by a browser that is set to block or prompt iframes ?
     
    eyes-open, Oct 7, 2007
    #1
  2. Bubba

    Bubba Updates Team

    Joined:
    Apr 15, 2002
    Posts:
    11,271
    Perhaps I am not comprehending exactly what you are saying but HTML code is simply basic HTML code. What ever code is contained between <html> and </html> on any web page will be seen by the browser and the action will be taken.

    Bubba :doubt:
     
    Bubba, Oct 7, 2007
    #2
  3. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    Hi Bubba & thanks. No, the question was that simple and that's what I thought must be the case.

    I occasionally struggle to see how they continue to be used so successfully as a vector of infection - particularly on major sites like the *Bank of India. I'd have thought such sites were comprehensively audited & such an intrusion picked up almost immediately.

    I began to find it easier to believe the tags could somehow be hidden rather than be injected unnoticed. So I thought I'd double check that nothing new had been added to the mix.

    * I'm not actually aware of how long the Bank of India was actively infected, so I accept that it may be that a bulk of traffic was caught out in a very short time.
     
    eyes-open, Oct 7, 2007
    #3
  4. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    Does nobody here with a website of their own, have any automated way of being aware of a change to their server pages?

    I get the small guy with the domestic and/or small business site might come back after a weekend to find their site has been cracked. The same imperative for 24hr monitoring isn't there.

    However for the bigger organisations, are there really no effective methods to be immediately alerted when a servers host pages have been altered?

    If Wilders was the unlikely victim of an intrusion, how long would it take to notice either a new invisible iframe had been added, or an existing iframe been subverted with a new javascript?

    Edit: additional, I just went back and double checked about the Bank of India crack, it was according to F-secure, a new hidden iframe added to the front page. So it wasn't even that an existing iframe was subtly changed to run an injected script.
     
    Last edited: Oct 8, 2007
    eyes-open, Oct 8, 2007
    #4
  5. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    It's becoming more like a chapter than a thread - but I wanted to add a little extra....using the Bank of India as a vehicle for looking at an IFRAME exploit.

    I'd missed that the BOI (Bank of India) page in question was hosted externally by a US hosting company, which being an extra step away from their central bank, became an additional liability. I understand how with the power of an organisation like the Russian Business Network, reputed to be behind the attack, there could be several methods for leveraging an attack on this or any site. That said, it's not so much the mechanics of the cracking of the site, which as far as I know, remains undocumented at the moment, or even the nature of the exploits, described elsewhere as 'unremarkable' that interests me at this time. It's the responsibility/ability of a providers iinfrastructure to detect and act on what I see as very tangible change to a frontpage.

    The initial discovery of the Bank of India intrusion was as far as I know, alerted by Sunbelt who while researching a different issue, became aware that the Bank of India site was compromised. Unless someone has additional information, we'll never know at what point the BOI would have identified the problem with it's own page - nor, unless they document it, how long the page was infected before then.

    One entry in the Sunbelt blog which was reporting on the event reads:-

    "Update 3: As I write this, it is currently 1:20 a.m EST (10:20 a.m. in India), and the malicious IFRAME is still located on the Bank of India website."

    So we can be reasonably sure there wasn't an immediate and 'definitive' response by the BOI. Reading a little more, I see that once having been alerted, the bank rolled back their index page to a clean pre-attack stage - only to discover that the page was immediately replaced again by one containing the infected IFRAME*. Actually where I sourced this statement it said "each time" they rolled back, so quite how many times it took them before they realised they had a duty to close the site and protect customers I don't know. Is there a code of practice that covers this - if so was it adhered to and if so, does it need re-writing?

    Since the infection, the BOI has moved their website nearer home, stating that the decision to move away from the US hosting service was not directly connected and was already in the works. A move which they say is facilitated by a substantially improved IT infrastructure in India. Also, the executive director, K R Kamath, said: "Following this incident, more security features have been added to the website and monitoring of the website has become much more stringent”

    It's also important to note that the BOI have pointed out that the actual core banking component operated on separate servers which are well protected and remained untouched by the intrusion. Normal banking operations they said, continued to be secure on these servers. This has been subject to the counter-argument that courtesy of the malware that was able to propagate on their front page, those customers who visited this gateway with unpatched systems may as a result have had their information harvested by a data harvesting trojan.


    * For a little more about IFRAMES, and an easy to read introducton into how bogus versions may be introduced, together with a link to MPac an IFRAME manager tool see the links below:-

    http://authentium.blogspot.com/2007/09/bank-of-india-confirms-site-hack.html

    Quoted from above: "The disturbing thing about all this is the likelihood that thousands of web site administrators will not read any of these posts, and continue to download MPack-based fake administration tools, and infect tens of thousands more sites - including online banking and commerce sites."

    http://authentium.blogspot.com/2007/08/mpack-developer-just-creating.html

    Quoted from above: "MPack presents itself as an IFRAME Manager tool, basically an FTP updater client, written in PHP language, that runs on a webserver with MySQL as back-end. It takes as input a list of website administrator accounts (possibly obtained in the black market). It then periodically checks the home pages of those sites to inject a chosen IFRAME into their code."

    I'm grateful to LowWaterMark who replied to a PM and suggested some leads I might like to follow around the subject of site auditing. Especially the one about 'Tripwire'.
     
    eyes-open, Oct 10, 2007
    #5
  6. Pieter_Arntz

    Pieter_Arntz Spyware Veteran

    Joined:
    Apr 27, 2002
    Posts:
    13,491
    Location:
    Netherlands
    Just throwing in a bone so you won't get the feeling you're talking to yourself. :D
    Have you considered the possibilities of server-side scripts?
    I can imagine one would be able to hide the code for an iframe pretty easy from a layman in php and asp

    In the old days it was very likely possible to post the code for an iframe in a post on a forum untill someone figured out this could be abused.
    Most of the times this "figuring out" means someone notices it too late. ;)

    Regards,

    Pieter
     
    Pieter_Arntz, Oct 10, 2007
    #6
  7. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    Hi Pieter, always a pleasure to hear from you :) I'm really just thinking out loud as it were. I've no idea where I'm going with it - just taking a closer look at the way that iframes are being abused and how well targets are responding. Anyone with an observation is welcome to add a post.

    I have taken a further look around at less high profile sites, albeit without much of a skills-set, at the role of PHP in hidden iframe and similar exploits, like the use of <u style=display:none>.

    I recognise that there is a dynamic aspect that may mean that the scripts are altered or even not present at all, when the casual observer looks for them. Poor password protection, concerns around exploits on host servers and vulnerable software, all appear to be common links. Here, your proposition Pieter that 'figuring out' means someone notices it too late, is an understandable one, given the lack of ongoing auditing/attention that seems to be applied to these situations by too many site owners.

    Ah well, just another part of the ongoing battle for ownage I suppose.
     
    eyes-open, Oct 11, 2007
    #7
  8. Pieter_Arntz

    Pieter_Arntz Spyware Veteran

    Joined:
    Apr 27, 2002
    Posts:
    13,491
    Location:
    Netherlands
    Yes. another one I remembered later was where adds were fetched from an outside server and these adds contained exploits.

    That is another option where the site-owner isn't necessarily "responsible" although he should be able to remove the adds as soon as they are made aware of the fact that there is an exploit.

    Regards,

    Pieter
     
    Pieter_Arntz, Oct 11, 2007
    #8
  9. eyes-open

    eyes-open Registered Member

    Joined:
    May 13, 2005
    Posts:
    721
    My final post then on this. I do have sympathy for site owners who find themselves in difficulty - the link below gives some insight into the way individual site owners can be affected and clearly want to understand how and why - although a lot seem only to want to look outwardly for answers. Luckily a lot of the exploits were spammers who were using <u style=display:none> to hide links that were placed there to raise the spammers site rankings and not inject malicious code onto client machines.

    So 2 final links - the first showing a cross section of people struggling with these sort of php exploits:-

    http://www.mezzoblue.com/archives/2007/06/05/unsettling/

    This second one is a link provided by the only poster from the above link (#49) out of 104 replies to raise the subject of file monitoring/intrusion detection. This has a guide to using 'Integrit' - described as a lightweight and fast file monitoring application.

    Simple webserver file alteration monitoring using integrit/

    I don't know how good the tutorial is - but it's fairly recent and may benefit someone.
     
    eyes-open, Oct 11, 2007
    #9
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Accept Learn More...