Project Euler Humble Return(projecteuler.net) |
Project Euler Humble Return(projecteuler.net) |
Ex) https://projecteuler.net/profile/daguava.png
But you can also use this to quickly test the status of accounts.
For example, I was able to find Euler is an admin account by trying
https://projecteuler.net/profile/euler.png
It tells you it's admin in the image, why?
Edit: Wonder if they're exposing some vulnerability with the HTTP 300 Multiple Files they're returning.
If you try something like this: https://projecteuler.net/profile/.wat
the page confirms a .htaccess file exists at https://projecteuler.net/profile/.htaccess we also find one at https://projecteuler.net/.htaccess
While currently inaccessible, this is significant information leak
All directories allow this, so you can do some digging to find what files exist.
Edit 2:while logged in, you can enumerate all usernames with a skill level attached by using URLs like
https://projecteuler.net/level=1
If you try changing the level to a period, the page conveniently tells you there are over 118k users in total (listing the first 10k), and MAY even show accounts without levels, but I'm not sure.
Combine this with the profile image URLs above and you may be able to find more admin account usernames if they have levels associated with them.
Kind of a jerk move.
https://projecteuler.net/level=19
Look for the gold stars
1. Your login page leaks information, as it returns "username not found" if you enter an invalid username. This is a bad idea. Better to simply say "login failed" in any case. Now, thanks to a few minutes of playing around, I have a fairly good idea that "admin" is a valid username on projecteuler.net. For the sake of argument, let's assume that's a real account, and actually has some administrative access... that's a bad idea. "Security through obscurity" is oft derided, but no sense making it easy for the bad guys. Make your admin username "flummoxedrabbit" or something that nobody bothers trying. As it is, I'm hoping this "admin" account is a dummy or a honeypot or something, but if it isn't, I definitely encourage you to change that and quit leaking username validity information.
2. From the limited testing I did, it doesn't appear that you limit the number of failed login attempts. Or if you do, the login limit is awfully high. I tried logging in 10 times and as far as I can tell, I could have kept going. If there really is no limit, it's probably not that hard to brute force your password. There are plenty of scripts and browser plugins to sit there and try to login repeatedly, trying to brute force forms like that.
3. In addition to limiting the number of login attempts, it's possibly a good idea to add a steadily increasing delay before accepting another login try from the same IP address, after each failed login. This will slow down at least some attempts to brute force your password.
4. You could consider some sort of Multi-Factor Authentication setup.
5. You could also consider adding code to do something similar to what fail2ban does, and automatically block connections from an IP where more than X failed logins originate in some period of time.
It is a pity it keeps getting hacked. I think that the site owners are more interested in algorithms and mathematics than mundane engineering. It would probably be a good idea to open source the site.
...Hack This Site is a free, safe and legal training ground...
Usernames cannot contain more than 32 characters
and they may only contain upper/lower case
alphanumeric characters (A-Z, a-z, 0-9), dot (.),
hyphen (-), and underscore (_).
Passwords must contain between 8 and 32 characters.
256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. In reality, even if they were stored as encrypted binary/base64 in a nosql file system of structured data files, 4096 is pretty much the de-facto floor for disk space occupied by non-zero-byte individual files on most modern file systems.
...variable data size being a concern in cases where the transformed value is encrypted rather than hashed.
I took that to mean that prior to being pwnd they had been storing passwords cleartext and would no longer be doing so.
Also, the wording about allowed special characters seems to be incorrect. I personally have a non ./-/_ special character in mine. Unless they are doing something terribad like silently discarding noncompliant parts of the password.
Re: password length - at least 32 characters is respectable. I believe last time I used outlook.com they had a max length of 12-16!
I find it concerning that folks are so eager to rush back into a warzone when they know it's not safe. Piling onto a recovering website after a cyberattack is akin to running back into a field where landmines were found. Maybe somebody was able to remove a landmine or two, but wouldn't it be wiser to just walk around it?
Unlike, for example, actual mines.
It's taken blood, sweat and tears to save up 20k (a lot for me) and even though I have a secure authentication scheme for the website, I worry about it getting hacked all the time.
"...there is absolutely no risk"
You have no idea! There's little practical risk in people getting access to my (fictional) ProjectEuler account, but there is absolutely some risk into returning to the same scam twice. Say they exploit PE again and are able to extract more than just password and email, maybe they find a way to get more info about the user's browser, or cookies, or SOMETHING. Anybody foolish enough to continue to navigate to projecteuler.net will suffer the consequences. They'd be better off never returning.
I know the response to this will be, "Oh, you can't possibly expect people to just abandon services that are compromised once" but I absolutely don't expect people to do that. I do it, because my security is worth it to me. Others don't, and this is the sort of thing that happens.
We've no way to really isolate what happened to projecteuler, and no way to now what kind of nasty code got injected into the pages.
I haven't found any indication that the website behind Project Euler is open source or follow open source development processes.
edit. Such as allowing people to audit the source of the site as opposed to requesting pentesting.
Comments like this (sometimes) go half-way. If there's a point behind it, enumerate the ways you think would improve his practices.
Also:
Github Presence != Open Source
Open Source != requirement in asking for help/advice
As such we can only trust that the people running the site are taking due notice and patching it correctly -- which, (I hate to say) given Project Euler's track record in the last year or so...
#2-#5 are all good points, though, and would help prevent username enumeration as well.
Agreed, but I would lean towards giving the bad guys as few tools as possible. If you require a captcha to register, and if you limit the number of registration attempts, you can also cut down on that channel.
That's not to say that this stuff is the be all / end all of course. It would probably be better to eliminate username/password combos altogether and do everything with keypairs, but until that day comes...
Unfortunately, the alternatives are unthinkable for everyone who isn't a programmer.
When setting the password, max length was only enforced by a text input with a max length attribute. You could happily type more characters and everything would work as expected....until you went to log in. The max length on the password field on the login form was greater so those characters that were silently dropped when setting the password suddenly weren't.
It took me a couple of minutes to get everything fixed, but I can only imagine what would have happened if they were more malicious and used it to serve malware or as part of a botnet attacking other sites.
It was still annoying, disruptive and unwanted, but it was so much easier to deal with than some more malicious hacks out there.
(not to mention interfaces, languages, security, identity, manufacture, physics and pop-tarts)
and if you get upset at people pointing out how much nicer things could be, then things probably wont
> In 2015, becoming a Web developer is all about learning Ruby or figuring out Node.js, not just building cool things you like.
This is patently wrong. Maybe it was harsh to call him a moron but the content was very weak in that particular piece.
The character limits for usernames, though... smells like a SQL injection issue. Which is an obvious and completely naive thing to assert but they're using PHP so my immediate thought is that they're passing raw userdata into the database as strings.
That was my first thought too. I'd guess that it's a vulnerability somewhere in the code for handling the forums.
I would be willing to bet that they could get rid of a lot of the attack surface just by using standard services for certain things.
Although judging by a screenshot of the recent hack[0] posted here[1] escaping (and XSS) may not be an issue.
I think I take greater risks going for a walk in the evening.
With that said - "Linux" is safe by being such a tiny population of the community that browser malware generally isn't written for it. In general, I take it as a given that people have deleted/disabled flash and java plugins a long, long time ago.
Well, we don't know that, actually. The info given on the PE site say that the attacker gained access to the server and modified the database. Do you have proof that it's serving up malware to visitors?
In any case, it's an odd situation and an odd response from Project Euler. It doesn't seem like a complicated enough site to get hacked in a mysterious undetermined way.
Bug bounty programs searching for security vulnerabilities rarely need completed proof of concept exploits – crashes are enough. You've laid down all of the pieces for someone competent to potentially do some real damage without much work at all, and that's exactly why the request was made not to disclose any further vulnerabilities.
And yes. You completely went around their request, and made this info public without their consent.
Actions like this are THE reason the relationship between vendors and security researchers is strained.
There's a SPECIFIC reason it's considered common courtesy to wait until a vulnerability is patched before public disclosure.
IANAL, but you also violated their ToS by doing this, and if you did this to a site I owned, especially without my consent, I'd be very motivated to contact the proper authorities and pursue civil remedies.
Actions like this are THE reason the relationship between vendors and security researchers is strained.
You want the owner to be cool with you disrupting business, causing untold financial damage?
PEOPLE like you are the reason that relationship is strained, and the reason the CFAA was written in the first place.
So please do keep "pen-testing" sites you down own without anyones permission, I'm sure you'll end up with a great life that way.
We've already been using PDO. As for overall privacy/security, please see https://projecteuler.net/privacy
Thank you for showing up and addressing my armchair criticisms. I appear to stand corrected.
Secondly, why are "non-americans" cool with breaking other peoples shit without permission?
They shouldn't be storing passwords at all so storage space should be a non-issue. My 20 meg password should hash down to the same small(er) value as your 15 character one.
$ python -c 'print "8 bytes\n" * (20 * 1024 * 1024 / 8)' > 20meg.txt; time shasum -a 512 20meg.txt
59cb7f88ad8d6229e6d3a74ee422dff57e17f168c6e6fa44ef32c3f07a73a6e455d8b55c1265d5212b9ed5475b6d9364286645200dada59aa16905a9ce748561 20meg.txt
real 0m0.289s
user 0m0.284s
sys 0m0.004s
$ python -c 'print "8 bytes\n" * (16 / 8)' > 16byte.txt; time shasum -a 512 16byte.txt
b6043d3a520424d5ec17dc0c23ba3b591d74517e2b9faa0df2d69d13c89a5f372d6dc35f95836687ee05be18433277e1c4b67393eb2771b475d655a832b16654 16byte.txt
real 0m0.045s
user 0m0.040s
sys 0m0.004sHiding the technique to compute the hash is relying on security by obscurity. Ideally you want a system that is secure even if potential attackers know what methods you're using.
The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.
> If you're not sending 20 megs of data,
> you're not getting 20 megs of security.
> So why allow it if it doesn't add anything?
> If you're not sending 2 KB of data,
> you're not getting 2 KB of security.
> So why allow it if it doesn't add anything?