5

I maintain a Rails app. Every page except login and "forgot password" requires user authentication. Yesterday I noticed entries like this one in the access logs:

54.209.60.63 - - [03/Nov/2015:19:09:53 +0000] "GET /compendia HTTP/1.1" 302 120 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:19:09:53 +0000] "GET /login HTTP/1.1" 200 927 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:19:10:37 +0000] "GET /noumena/428 HTTP/1.1" 302 120 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:19:10:37 +0000] "GET /login HTTP/1.1" 200 928 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:19:15:11 +0000] "GET /data_ranges/1208/edit HTTP/1.1" 302 120 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:19:15:11 +0000] "GET /login HTTP/1.1" 200 926 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:20:22:01 +0000] "GET /fields/392 HTTP/1.1" 302 120 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:20:22:01 +0000] "GET /login HTTP/1.1" 200 926 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"
54.209.60.63 - - [03/Nov/2015:21:55:29 +0000] "GET /users HTTP/1.1" 500 1477 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25"

Each of the requests was properly redirected back to the login page. Still, those URLs would be valid for authenticated users. And anonymous users could not be able to know those URLs.

Is there some legitimate use case here? Or is one of my users compromised, and somehow they are leaking URLs but not credentials?

Improve this question
2
  • Users regularly bookmark and/or try to access pages that require authentication first. This isn't unusual at all.
    – John Conde ♦
    Commented Nov 5, 2015 at 19:24
  • Look for a pattern if you can find one. For example, are these in link order as they appear in your HTML? Could these all be typical user book-marked pages that may have been scraped from a browser via some JS or virus? Spammers and scrapers will create user accounts only later to come back. They often create a few at a time. Is there any indication that user accounts have been created and then abandoned? John is right, however, without a larger sample, I cannot tell you how suspicious this is but it looks suspicious to me so far. I am not sure we would really know without more evidence.
    – closetnoc
    Commented Nov 6, 2015 at 3:16

2 Answers 2

Reset to default
3

Are you displaying ads on your site from Amobee (formerly known as Kontera)?

The PTR record for this IP is nat.aws.kontera.com, suggesting that it is a crawler looking for your page's content in order to determine what ads may be relevant to that URL.

If you've loaded the Kontera JavaScript on login-protected pages, then you will find that they are crawled any time a logged-in user visits those pages. Try removing the JavaScript call from protected pages, and see if the crawling of those pages stops.

It's also possible that code has been added to the web page by a man in the middle attack before it reached the user who actually visited your site. Such an attack might have been launched by a network operator or malicious party in order to gain revenue from your content, or for other reasons.

This is one of many reasons that every web site should run on HTTPS.

Improve this answer
5
  • Interesting. I am not. But maybe Amobee (or some other company) installed ad injection software ... and the ads are coming from Amobee? I can see one of my users accidentally installing something like that...
    – MustModify
    Commented Jul 11, 2016 at 21:29
  • This AMA suggests that Amobee has a "network appliance": "There is (sic) also companies like rgnets (rgnets.com), amobee (amobee.com) and FrontPorch (frontporch.com), which offers network appliance that performs the HTTP interception and tampering. In this method there is no need to install anything on the user, all you need him to do is connect your network. Large public networks (hotles, events, airports, etc) are using it as well as some ISPs."
    – MustModify
    Commented Jul 11, 2016 at 21:43
  • Update your answer to include the possibility of injection at airports-or-whatever and I'll accept it as the answer. I can see a user going to an airport and accidentally leaking some URLs. We aren't seeing this on our HTTPS site, so that lines up as well (since, presumably, you couldn't inject into HTTPS.) I hadn't thought of this as a reason to promote HTTPS but wow.
    – MustModify
    Commented Jul 11, 2016 at 21:50
  • @MustModify Oh, that's nasty. I'd completely forgotten about the possibility of a malicious attack on the user. Updated.
    – Michael Hampton
    Commented Jul 11, 2016 at 22:34
  • I've noticed the same user agent string on my domain. Our users are all coming from mobile phones, so it got me thinking how Kontera is discovering the URLs. Based on this analysis, I believe it is because of shady browser extensions installed by the users. adguard.com/en/blog/big-star-labs-spyware
    – Puck
    Commented Dec 19, 2018 at 3:14
0

There is nothing to be concerned about with this as it commonly shows up with secured applications on the internet. A user accesses a link through their bookmarks bar or through their browser history to go back to a page that they want to go back to and because their session has expired they are redirected to the login page to login first. No worries here.

Update #1 Further investigations into the IP in question have shown the following points...

Based on the fact that none of these abuse reports about the IP address 54.209.60.63 actually state that anything malicious was done to the web server and even Project Honeypot confirms it is a possible web crawler and not a malicious machine there should be no concern.

The IP address has also since been de-activated from the offending account with Amazon and is no longer assigned to the original EC2 instance in question so there should be no further issues from this IP address regardless.

Improve this answer
3
  • I'm not convinced. You're saying a user had bookmarked the URL on line 1, was redirected to login, waited a minute, then used a bookmark for the URL in line 3, then didn't login again, waited 5 minutes, tried another bookmark which also didn't work, then an hour later tried a fourth bookmark, and still didn't login?
    – MustModify
    Commented Jul 8, 2016 at 14:10
  • Okay further digging into that particular IP address shows that it is known to do this same thing, no malicious actions have been taken by the IP. General consensus from what I can see is that this is some sort of crawling activity being done.
    – Chris Rutherfurd
    Commented Jul 9, 2016 at 0:31
  • Put that as an answer and maybe provide some citations and I'll accept it... though obviously it's not very satisfying in terms of what's actually happening. Like, how is it getting those privileged URLs?
    – MustModify
    Commented Jul 9, 2016 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.