1

First try clicking on the blue button here.

Then if you have a VPN start it up, open the terminal and curl the same link. In the response, you will see that the button is now disabled. The server identified you as having clicked the link already even tho the HTTP headers are mostly different and so is the IP address. Besides, there is no fingerprinting of the device since in with CURL no dependencies are loaded.

How is this even possible?

Improve this question
4
  • 1
    I don't understand. I get a quite suspicious looking site, with a popup with the text "You have given LIKES and have prized!" and a blue "OK" button under it. The blue button remains enabled even if I click it and reload the page, without using a VPN or anything. So I can not reproduce what you describe.
    – Anders
    Commented Oct 22, 2016 at 8:28
  • That is really odd. I've never seen the behavious that you describe. It start to look like if they had in place a very advance algorytm that identify if a click is legitimate..
    – silkAdmin
    Commented Oct 22, 2016 at 8:40
  • I have not spent a serious amount of time debugging this but there is this: if (wlang != "zh_CN"). Which (apart from being bad JS since it should be using !==) curl will never execute the contents of.
    – grochmal
    Commented Oct 22, 2016 at 12:52
  • @grochmal Yes CURL don't run ANY JS. But yeah the front end is a mess.. a mean there is an empty Javascript file and 2 version of jQuery.. Either these guys are genius at masking their trail either this whole thing is just a huge bug ..
    – silkAdmin
    Commented Oct 22, 2016 at 14:28

2 Answers 2

Reset to default
2

I can not reproduce any of the behaviour you describe, so this post will be a bit more theoretical in nature.

The ability that you are perplexed by seems to be the ability to recognice the source of a HTTP request even when a VPN is used and a no-features user agent like CURL is used. That would indeed be perplexing.

The super cookies or fingerprinting methods we know of all relies on some kind of feature (like HSTS, Flash, or JavaScript to report screen size or installed fonts). CURL does not support any of those featers, it does not even parse the response for you. So still being able to identify the user would indeed be magic, or at the very least a sign of a faulty VPN.

However, the test you describe in your question does not demonstrate the proposed ability. There are a large number of alternative explanations that you have not yet ruled out. Just to name a few:

  • The IP of well known VPN:s are listed and blocked.
  • The IP of the VPN is in a blocked geolocation.
  • The button is activated by JavaScript, that CURL will not run.
  • The behaviour is just random.

The test I would do would be to use CURL (with the exact same request) and a VPN for both the first and second attempt, but with different exit nodes, i.e. different IP's. If repeated tests of that kind shoved that some kind of super cookie worked I would indeed be perplexed, but not until then.

Improve this answer
6
  • When initially CURLing the link under VPN I could see the button has enabled in the resulting HTML which invalidates the first three points that you brought up. Your last point tho might just be it, that or the whole is just buggy.. Also have ever heard of this: lcamtuf.coredump.cx/p0f3
    – silkAdmin
    Commented Oct 22, 2016 at 14:25
  • Good method: 'The test I would do...'. Second and upvote that.
    – LSerni
    Commented Oct 22, 2016 at 14:51
  • @silkAdmin In you question you say the button was disabled when you try over a VPN. Now you say it is enabled? No matter what, the solution is to approach this as a scientifice problem and do tests where you only change one thing - "all else equal".
    – Anders
    Commented Oct 22, 2016 at 16:10
  • @Anders What I meant is that the first time that you visit the link, no matter if CURLing or with the browser the button will be enabled. Then after clicking it, it's disabled everywhere. Having posted here now I can see people reporting that the button was greyed out from the start for them, which seems to indicate that this whole thing is just buggy. The button can only be clicked once, period. FYI you can get a fresh "campaign" by incrementing the aid at the end of the URL.
    – silkAdmin
    Commented Oct 23, 2016 at 2:01
  • 1
    @Anders It seems like it, still not 100% sure tho, so I'll post an answer if needed a bit later. Otherwise I'll just accept yours as it most likely the onw that will be helpull for people finding this thread.
    – silkAdmin
    Commented Oct 23, 2016 at 8:28
1

There are several possibilities that I can see.

  • user error: the site actually needs Javascript or whatnot, that curl does not provide. The site does not look different because it has recognized you; it does so because the second browser does not work.
  • super-cookies: there are ways of getting/setting information, so called "super-cookies", that will not be browser dependant. Also other information recoverable by a browser, such as OS, installed fonts, screen resolution and so on, might be shared by different browsers across different IPs. If the site sees two connections with exactly the same fingerprint, it chuckles evilly and rejects the second connection.
  • social engineering: the site is actually always the same. There is no advanced algorithm and there never was. You are just setting up the question (and a just-joined user profile to do so) so that people will follow the link and accrue points, kudos, reputation or whatsnot to this "aid=1133" guy (wait -- or was it 1100?).
  • browser whitelist: the site only "reacts" to certain browsers, possibly coming from a range of IPs. If you were constructing a voting site and wished to deploy some fraud checks, it would totally make sense to run some anagraphics and possibly accept only votes from some countries, using some likely User-Agent's.

Also, re: fraud checks, one important part of this kind of work is convincing the attacker he has succeeded, or at the very least not underscore the fact he has been detected. This will delay the moment he'll try anything else. Here apparently the voting process is always successful, which is exactly what a successful defense would have us believe. What the votes accrued actually are, we do not know.

So what could have happened is that someone (either human or program) is manning the defenses, and recently something - such as a Stack Exchange pen-storm :-) - happened, that made "battening the hatches" seem advisable. The disabled button was the last time that the site let someone know "Hey, you're voting twice!". Now, maybe the site still knows, or maybe they no longer care instead - but in all cases, it's simply no longer letting anyone know.

Improve this answer
4
  • Thanks for your input. user error can be ruled out as you can make a positive test by using a different aid that you haven't clicked yet (just increment the aid i.g.: 1101). super-cookies is probably not the case here either since it would requiere a trip to the server. Here the CURL response already "identified" the request as a returning (or not returning) user. social engineering I am not that hungry for a Cobb salad but I totaly see how this could be an option : ) Feel free to change the aid in your test to make sure
    – silkAdmin
    Commented Oct 22, 2016 at 9:19
  • I already did when I answered ;-) - but yet more options are coming to me. Editing answer
    – LSerni
    Commented Oct 22, 2016 at 9:31
  • Thanks for the first bit about fraud checks. That will be useful. As for the second part it seems to hint of something rather advanced and I seriously doubt they would implement anything complex for such a small campaign
    – silkAdmin
    Commented Oct 22, 2016 at 14:27
  • I was thinking more along the lines of a sudden settings change on the site. I've just now read a good suggestion by @Anders which I hinted at, but did not state clearly.
    – LSerni
    Commented Oct 22, 2016 at 14:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .