Project Euler Humble Return
projecteuler.netYou can list what problems you've solved by showing an image generated for you.
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.
So basically, by telling us this, you're completely contravening the request they made that security vulnerabilities be disclosed privately?
Kind of a jerk move.
While I am kind of a jerk, I haven't made a vulnerability of it yet, just an info leak that may help someone here complete the puzzle.
If this was an essential security library instead of a fun website, this would have been an incredibly irresponsible disclosures.
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.
The whole point of Project Euler is you're not supposed to give hints.
The attackers didn't give hints either :(
I think you're confusing "exploit" and vulnerability. An info leak is a vulnerability. Period.
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.
> 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.
Good grief, Americans and threatening to sue anything that moves.
First of all, how do you even know I'm an American? Nothing in my post, my bio, or anything mentions that, so that's quite a sweeping generalization, and baseless assumption.
Secondly, why are "non-americans" cool with breaking other peoples shit without permission?
Excuse me? You want to be able to launch an attack, unprovoked, against a server you don't own, without permission, and you want the owner to be cool with that?
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.
100% agree!
All of this info (sans the HTTP 300 issues) is accessible via means which have been specifically GIVEN to users on the statistics and profile page. All I've done is point out combining these lovingly provided sets of information may have a role in what has happened.
Yeah but how else would he get the same ego boost from showcasing his brilliance on HN?
Is there any reason why you're intentionally not using the email denoted on the news page?
No the original commenter, but is PE looking for any maintenance help? I certainly don't mind doing things like issue tracking, documentation, etc.
Turns out you don't need the image method, the skill level pages put a special star next to your name if the account is an administrator:
https://projecteuler.net/level=19
Look for the gold stars
Open source that site. Vet a few devs to have access to the source to begin with then opensource it. Or even better, let the community rewrite the source from scratch. How hard can it be? and there are often a lot of people willing to contribute to open-source projects.
"How hard can it be?" <--- yeah, that's how you end up with vulnerable sites.
Not if you make security your number one goal from the beginning. But "letting the community rewrite the site" would be very complicated, especially on a niche website such as Project Euler, where a lot of its users are opinionated and would probably take a long time to reach consensus on anything.
If security were really your "number one goal", then you would not create a site at all.
Number two after availability, then.
OK, well, here's an initial observation:
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.
Regarding #1, telling the user that their login failed doesn't eliminate their ability to enumerate existing usernames. All they have to do instead is attempt to register a new account with the username they're testing. At some point, the site will have to tell them that the username already exists.
#2-#5 are all good points, though, and would help prevent username enumeration as well.
Regarding #1, telling the user that their login failed doesn't eliminate their ability to enumerate existing usernames. All they have to do instead is attempt to register a new account with the username they're testing. At some point, the site will have to tell them that the username already exists.
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...
Except you aren't really limiting the tools available to the bad guys, you are just making the UX worse. I find this 'best practice' annoying design and doubt that it has mitigated any attacks.
Using what Daguva mentioned above, it looks like admin (https://projecteuler.net/profile/admin.png) is just a regular accounts, compared to say, euler (https://projecteuler.net/profile/euler.png)
Yep, which makes his discovery much more damaging. That was a good find, and something PE should definitely fix!
Another area I'd suggest looking into is your "recover your account key" setup. If the keys really really are random, then this is probably fine. But if there's any flaw resulting in your generated keys being less than ideally random, somebody could have figured out a way to generate an account recovery key, and then used that to steal an administrative account. That is, assuming your administrative user even has that option. If it does, it might be a good idea to disable that, since you presumably have direct db access anyway, and can always backdoor your way in if you forget your own password.
There are times when I lie in bed at night and stare into the shadows and think to myself web based administration is probably always a bad idea.
Unfortunately, the alternatives are unthinkable for everyone who isn't a programmer.
csrf tokens would be nice too.
There's also an account named "backdoor".
And "root" as well, apparently.
It would be nice if source were provided, so that we can do a whitebox analysis. I don't have confidence that there is one single point of failure here, given that the site has already been compromised multiple times.
Especially since PE is such a technically simple site. It's login/logout, listing of problems, and confirmation/logging of problem success. It's simpler than the apps that beginning web framework tutorials show how to make.
We see lots of projects on HN that get open sourced. It's surprising nobody has made one yet. I've even seen clones to HackerNews open sourced here.
Part of me learning to code was by going through the challenges on Project Euler and I always get a sense of nostalgia when reading about it.
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.
I can't imagine the rationale for hacking projecteuler in the first place. Always a favorite place of mine as well and I still bring newbies to the scene there when I attempt to show them the basics of programming. I guess there's just an asshole for everything when you have hundreds of millions of people online these days. Sucks a bit doesn't it?
Despite the whole situation being rather embarrassing, it seems like they're handling this quite well. Whitehat to the rescue!
I don't get it why someone would hack project euler.
http://www.hackthissite.org/ lists "hack project euler" as the final challenge
Where does it show this?
It's rather amusing how they claim they're 'legal', then....Hack This Site is a free, safe and legal training ground...For some reason, I have little desire to follow that link.
Do you know who Jeremy Hammond is?
Is that the guy from Top Gear?
Yes.
Some hacker kid that couldn't figure out the answers?
to serve malware
Sigh...so true. Sad to say, I miss the days when folks did this sort of shit just because they're asshole sociopaths.
Right! A couple of years ago some (self-reported) Turkish hackers exploited a Wordpress vuln and took control of my hosting. All they did was change index.php into their own landing page telling everyone that I got owned, that Turkey is the best, and (from memory) an Islamic Nasheed playing in the background.
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.
How do you know the defacement was not just a distraction of the NSA adding your machine to their bot net with some privilege escalation and root kit? Sorry :-)
The ultimate project euler challenge!
Cue thousands of determined hackers descending on Project Euler! It would be great if the community could find the exploit and save the site.
Finding an exploit doesn't necessarily mean they've found the exploit, unfortunately.
I can't wait for someone to figure out the exploit. Very excited. Go crowdsourcing!
I am unable to login to my account, so I'm not able to test this. But if I remember correctly this site used a poor captcha. There has been a lot of advancement at captcha breaking software in recent years. If they used some kind of custom captcha to prevent password guessing, then it's not extremely secure.
Does anyone know how Project Euler was storing the passwords?
My money is on "ineptly."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.There's really not much rational for capping passwords at anything beneath 256 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.
> 256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space.
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.
On the other hand, you might not want to be hashing a 20meg password. It is fast on my computer but it's fair to limit at something more reasonable.
$ 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.004sFast password hashing is bad anyway. Slow schemes are better (assuming they come from a thoroughly tested library written by someone that actually knows what they're doing).
I'm admittedly not familiar with the details of the hashing process, but it could be done client-side, no? Then the compute power required falls on the user, PLUS the 20 megs never gets sent over the wire.
No. Actually we would not want the hashing technique to be exposed in the source code.
That turns out not to be the whole story.
Hiding 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.
If you do the hashing on the client side, then the hash itself effectively becomes the password.
That would assume your users have JS enabled. I've seen something like that done before, but always with a fallback in case user has JS disabled.
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?
It doesn't add to the security, but I might find it easier to remember 20 MB of redundant and meaningful stuff than to remember 384 bits of literally random stuff. The entropy might be the same, but my memory is not a computer. I can remember vast amounts of material that is meaningful and use it as a password. I can't remember 384 bits that have no meaning.
The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.
Maybe 1 or 2 KB, max. 20 million characters is a ridiculous password to remember.
That's not the point - the difference between 2 KB and 20 MB is purely a detail. You said:
You could just as equally say:> 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?
Your point is the same, and it's still wrong. What you're getting is not the security - that's only half the story. My point is that is does add something, it's just that the something it adds isn't the entropy for the purpose of security.> 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?
When there will be multiple shorter passwords that hash to the same value, is there a point to a 20mb pass?
Yes. Ideally you want users to be able to remember their pass-phrases. To do so usually implies significant internal structure and/or correlations, so to get the necessary entropy they will be large. The fact that they hash to the same value as other things is effectively irrelevant.
I misspoke, I meant size.
Depends. Can you guess them?
If I'm an attacker who is running through hashes...yes. Faster than the 20mb one.
There is a slight exception to this. If they are using an older statically typed language like C, it might make sense for them to have a limit on the buffer ready to store your unhashed password. Yes it seems crazy these days, but it might apply to some of the older systems which have password length limits.
BCrypt has a character limit of 72.
Hard limit of 72, beyond which many implementations will silently truncate, and reduced entropy from each character beyond 55 bytes.
Probably a good idea to pre-hash. Or use scrypt.
I can't find it now but I seem to remember this came up in response to another breach ~24 months ago. At that time they made an announcement to the effect that from then on you'd no longer be able to have your password sent to you if you forgot it, but that you would instead need to use an account recovery key.
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!
Oh and on the topic of silently discarding portions of passwords, another outlook.com password deficiency (circa 2011, doubt it still exists):
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 used to be a salted MD5 hash, but it may have changed.
I would have assumed of course that the size limits were because the passwords were being stored in plaintext in fixed-length fields, but I guess they wanted to make sure they were 'complicated' enough? I guess salted md5 is literally better than nothing.
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.
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.
Probably. If they're not using PDO then that needs to be their first priority, dead stop. After that, maybe looking at their captcha script, because those sometimes have issues if they're not well designed. I don't know where theirs comes from but it doesn't seem to use much obfuscation so it's probably old. After that, Twig.
Although judging by a screenshot of the recent hack[0] posted here[1] escaping (and XSS) may not be an issue.
Admin from PE here.
We've already been using PDO. As for overall privacy/security, please see https://projecteuler.net/privacy
And PHPass as well, fair enough.
Thank you for showing up and addressing my armchair criticisms. I appear to stand corrected.
I genuinely hope the security hole is findable/fixable. Thank you guys for continuing to run an awesome service, despite asshats repeatedly trying to abuse it.
Thanks for the response!
Haven't they been wrecked once before this most recent incident?
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?
Except that as long as you use a unique password, and don't give any details that you don't mind falling into the wrong hands, there is absolutely no risk.
Unlike, for example, actual mines.
There is a lot of risk going to a compromised website. You are basically inputting potential malware onto your computer, and, if there are zero-days present on your system, handing control of your computer over to a malware author.
Yes, I'm pretty worried about browsing a website with no ads using Chrome on my Linux machine with uBlock origin and Flash disabled.
I think I take greater risks going for a walk in the evening.
A random website? Absolutely, 99.999% of the Web is safe. But we're talking about a site which is specifically compromised with malware.
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.
> A random website? Absolutely, 99.999% of the Web is safe. But we're talking about a site which is specifically compromised with malware.
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.
I use a unique password and even a burner email, and a phone number that I update every 8 weeks for my banking website.
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 checked the license. It appears that the content is licensed under creative common attribution non-commercial.
I haven't found any indication that the website behind Project Euler is open source or follow open source development processes.
So?
So, it's much harder for the community to find and report security bugs.
It's a shame the maintainer of the site is going to let it fall into obscurity instead of just adopting more modern development practices.
edit. Such as allowing people to audit the source of the site as opposed to requesting pentesting.
Please don't post backhanded swipes like this, or outright insults like "This guy is a moron." [1] The idea on HN is to comment civilly and substantively [2], or not at all.
Fair enough, just frustrated with the overwhelming number of "the modern internet is broken!!" posts that have been clogging up the front page lately. That also happened to be one particularly light on content.
the modern internet is broken
(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
Again, I understand there are issues with the modern internet, but that article was unironically calling for the return of geocities. It's a hyperbolic clickbait title that has no place in a reasonable discussion about the actual issues that we're dealing with. Beyond that, I even quoted the passage I took issue with.
> 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.
I didn't down-vote you (yet), but I don't understand how asking for security help is the same as letting the site fall into obscurity. What modern development practices would you suggest?
Comments like this (sometimes) go half-way. If there's a point behind it, enumerate the ways you think would improve his practices.
It's less that he's asking for help and more that this has happened multiple times and it's quite clear he should be allowing someone to audit the source code, not just search blindly for attack vectors. It's clear there are issues, it's time to invite some help.
Then I agree ... having a community of people who can help with the source code is a valid suggestion.
It's a shame to not be more sympathetic to people with less experience or less time on their hands, especially when they run a widely appreciated site.
Why is project euler not on github? Yeah..no one's gonna help unless you open-source your project buddy.
That's not nice. It's also plainly false. Lots of people love Project Euler.
Like me. And I would like to help but I know almost nothing about penetration testing. :(
Exactly. Source code would help a lot. It's an education site that's extremely amateur in nature. It belongs as open source.
How to down-vote a comment ?
You click the "down" arrow that's below the up arrow. You also need a bunch of karma, like 500 or a 1000.
Why is X not on Github is the programmer version of folk getting offended when you don't use Y social network.
Also:
Github Presence != Open Source
Open Source != requirement in asking for help/advice
Of course, but perhaps the point that most people who try and coerce others into using GH are making, is that the community would be more able and more ready to help them fix vulnerabilities quicker if they had access to the (non-sensitive parts of the) source code.
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...