Welcome to Geeklog, Anonymous Sunday, January 12 2025 @ 03:46 pm EST

Geeklog Forums

How secure?


Status: offline

geek0402

Forum User
Newbie
Registered: 04/02/10
Posts: 4
I have volunteered to help my church create a website and since I'm a PHP programmer I wanted something wirtten in PHP so I could mod the code if I have to. I don't plan on being the webmaster so I want something that is easy to use. Geeklog seems to be pretty simple to administer so it might be a good fit.

I have a question about the security. You call it the secure cms, but I couldn't find anything on the site about how it is secure. What does geeklog do that it you apart from the others where security is concerned. Security is a big deal for us I mean who wants a church website hacked right. I have to present to the church council what we are going to us so can I get some more information on what makes you guys better than everyone else in the security area.

- Jack
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Quote by: geek0402

What does geeklog do that it you apart from the others where security is concerned.


That's a good question, actually. There isn't any certfication program for secure web applications that I'm aware of, so I can't point you to a certifacte or something like that (there are such programs for e-commerce and banking sites, but those have a different focus, obviously).

Geeklog was originally written to run a security portal, so security has been an important feature from day 1. Over the years, renowned security experts have had a look at our code and even though they did occasionally find a flaw, they did usually give us good overall marks. For example, back when the discussion about the infamous PHP register_globals setting was still going on, well-known PHP security expert Stefan Esser used Geeklog as a positive example.

Admittedly, we did have a phase in the past where we let things slip a little, which then promptly led to a series of security issues. We have since re-confirmed that security is our prime feature and that we will focus on that above everything else.

We do monitor the usual channels where security issues are discussed so that we become aware of new trends and types of attacks so that we can pro-actively address these issues before they become a problem. We also try to keep up to date on new measures to reduce security risks and implement them ASAP. We also try out new tools to scan for security vulnerabilities, e.g. Google's recently released skipfish.

Does that address your questions?

bye, Dirk
 Quote

Status: offline

geek0402

Forum User
Newbie
Registered: 04/02/10
Posts: 4
Thank you for the reply. I guess you answered the question, but you really didn't tell me anything more than you re-confirmed security as a prime feature. I had assumed with such a bold claim, you were doing something specific to address security, but it doesn't sound like you are doing anything more than any other CMS. I don't want to start an argument so please do not take my comments the wrong way. It sounds to me that you are implying other cms system do not take security seriously, which I dont think is true and probably not what you are really trying to say. What I wanted to know was how you made it a prime feature. If monitoring the usual security channels and running some free vulnerability tools is all, I don't think that makes you any different than any other open source project. I'm pretty sure they probably do the same thing. I appreciate your time to answer my question.

- Jack

 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
No worries, I get what you're saying. Now that we make such a bold claim, we should really formalize things more. But I think it wouldn't be too different from what we've been doing all along, which is why I tried to point to our track record. Since there is no equivalent of a certification, we may want to ask for an audit by some security expert, if we can afford it. Have to think this through some more when the current GSoC madness is over ...

But security isn't a state that you reach and then keep forever. As I said, new exploits and techniques are popping up all the time. So as unscientific as it may sound, monitoring the usual channels is indeed the best way to stay on top of those developments.

bye, Dirk
 Quote

Status: offline

1000ideen

Forum User
Full Member
Registered: 08/04/03
Posts: 1298
Quote by: geek0402

...but it doesn't sound like you are doing anything more than any other CMS.



It does not sound so but it is. Not every CMS is being programmed by professionals and has security in mind. Just 1 example. Mambo always claimed to be easy to install but for that purpose the installation process was so easy that it contained a potential security risk. Users didn`t set the config file to less than 777.

GL puts most code above the web root and has a rights management inside. This is still not a wide spread feature.
 Quote

Status: offline

geek0402

Forum User
Newbie
Registered: 04/02/10
Posts: 4
I don't think you guys get it. I agree that security is not a state you achieve it is something that you have to continuously work towards. I guess having a security expert review the code would give you a good baseline to start, but it is just a snapshot in time. Making claims like Mambo isn't developed by professionals is pretty bad. There are 2 ways to be good, you are either better and toot your own horn or your say bad things about everyone else. Attacking Mambo doesn't do anything to bolster your claim. At least at the Mambo site I can find references to how they handle security, from a process standpoint which is exactly what I was asking for here.

I spent some time this weekend going through the Geeklog source code and was pretty surprised by some of the things I found. I also asked the security guys at work to take a look and tell me what they thought. They didn't come back with a very good report either.

I debated posting again because I don't have much good to say at this point, but decided I would offer some constructive critisism for you to do with as you please. And I think it is fair that anyone who stumbles upon the secure cms claim have all the facts. This is what I found and the security guys here at work found.

There is at least 1 published exploit for Geeklog that has not been fixed. Searching the full disclosure mailing I found this - http://seclists.org/fulldisclosure/2009/Oct/58 - it documents 2 different vulnerabilities - unchecked upload for user image and a XSS flaw in the forum plugin. Both of which are still exploitable (I tested and confirmed both using geeklog 161) and the XSS exploit works in the forum here. Sounds like you monitoring of the usual sources has a few holes.

The full disclosure post talks about a cookie exploit that has not been fixed. I saw this as well in the code for the session handling. There were 2 things that disturbed me about how this is handled. You are using MD5 to encrypt the password which is not secure. What is worse is that you actually put the encrypted password into the cookie. The encrypted password should be treated a sensitive and confidential and never used in a cookie. Anyone who can access a users computer can now login as that user or just take the password and decrypt it. It gets worse. Since the cookie is the only thing checked to see if the user can automatically login, Geeklog is susceptiable to brute force hacking attempts. Write a script to set the cookie on the attacker system and hit the geeklog site, if the encrypted password isn't valid just keep trying. There is no lock out protection for this. Someone could easily brute force an account on any Geeklog site if they had the time and the will. I was surprised that there are basically no protections on the auto login code. Actually it looks like the comments state the code came from an old version of phpBB and I guess it hasn't been updated in years.

Searching through the site here I found a story about a 'so-called exploit' - http://www.geeklog.net/article.php/so-called-exploit - and people confirmed they had been hacked by it. But you refused to acknowlege it as a real exploit. One guy called you on the carpet pretty well over it telling you that people were being exploited so it was a real exploit, but you still refused to acknowlege it as a real exploit. That arogance is dangerous and certainly does not match the security as a priority claim. Just like the guy commented on the story, if the only security protection is in the documentation and not in the software, it isn't very secure.

I spent a lot of time searching around this site and never did find a document for new users to help them secure their site. I found addons like bad behavior and captchas but I had to go looking for it. I recommend you write a story or put something in the installation instructions that tell users how to secure their site. What is worse is that I downloaded bad behavior and then installed it through the upload a plugin page. It uploaded and then installed without error telling me the installation was successful. Turns out it wasn't actually doing anything. I had to manually edit lib-common before it was actually doing anything. If I hadn't actually been testing for security issues I would have never known it was not working. It should provide some feedback to the user that there is a manual step required before it will work.

I hope you can take this post in the manner it was meant as feedback to help you improve the code.

- Jack
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Okay, just a quick response after looking at some of those links:

The problem with image uploads isn't fixable, effectively, since PHP will happily run a tiny snippet of PHP code even in the middle of a huge piece of binary data. So putting PHP code in the comment field that many image formats have is still an option, even if you double-check that it's really an image. So you need to make sure not to offer a way to include such an image in a way that it's not treated as PHP code.

I'm pretty sure we don't have such a problem in Geeklog itself at this point, but I can't vouch for all plugins. Same goes for XSS attack vectors.

So that's one point for the to-do list: Document how to prevent those and educate plugin authors.

As for the "so-called exploit": Yes, that post does come across as arrogant. But I still think that if you leave your backdoor open, it doesn't matter if the lock would have worked or not. We did have a bug there, but it only affected sites that didn't follow the installation instructions. Which falls in roughly the same category as your problem with Bad Behavior - not reading instructions. We have since pasted security warnings all over a fresh Geeklog install in the hope that people actually read - and act on - them.

We could put a "how to secure your Geeklog install" page up here on the site but I'm not convinced that it would help a lot. Anyway, I'll put that on the to-do list as well. Maybe we should try another case of inconveniencing our users for the sake of security and prevent the site from working unless the built-in security checks pass. We've shied away from that so far as it could drive new users away.

That the auto login is vulnerable to a brute-force attack is indeed something that I wasn't aware of, so thanks for that. I don't think it's a very promising attack in general, but with weak passwords and a dictionary attack, it may become practical. So we need to look into that ASAP.

Thanks for taking the time to try and punch a few holes in our (over?)confidence. I do appreciate that.

bye, Dirk
 Quote

Status: offline

geek0402

Forum User
Newbie
Registered: 04/02/10
Posts: 4
Boy you really don't get it do you? The image upload problem can and should be fixed. You can put PHP code in the meta data of an image and it is possible that it can be executed, but that isn't the problem Geeklog has with the profile image. The problem with the profile image is that Geeklog does nothing to validate what it just received it completely trusts the mime type sent by the browser. Never trust user input, this is security 101! You do not have to put PHP code in the image meta data, you can put whatever you want (PHP, javascript) in a file, put a .jpg extension on it and Geeklog happily accepts it and stores it on the server in the web space. If you choose to ignore this hole because there isn't anything that can exploit it today, you completely missed the point that security is not a point in time, it is something you continuously strive to.

You do not think having documentation on how to secure a Geeklog installation would do any good? Don't you think it is arrogant on your part to make that decision for all Geeklog users? Why bother to put the notice to run the security check or delete the install directory on the site, no one would read it, right? You would think that the 'secure CMS' would do everything in its power to educate and inform the users on how to best secure their site.

I find it interesting that you think my problem with bad behavior addon was my fault for not reading the instructions. I guess in some way you are correct but step back and look at what YOU built as a process for installing addons. You created the ability to upload and install without having to extract the archive on the workstation. I used the tools you provided and they told me everything installed without error. There is nothing on the download page to indicate that there is a manual step, there is nothing in the automatic upload and install process to indicate there is a manual step there is only a confirmation that everything worked fine which was not true. How would a new user to geeklog know that on some addons the sucess message is true but for others it is false?

You also don't get the brute force attack on the login cookie. MD5 hashes are not unique so even if someone used a strong password that doesn't mean that a dictionary attack has to hit on the same password there are other words that will generate the same hash. There is a reason why MD5 is no longer considered secure. Any brute force attack will take time but the point is there are no protections to prevent them in Geeklog.

Something I don't think you understand is that exploits usually don't happen because of 1 thing it takes 2 or more issues to make them successful. Look at the SQL injection exploits geeklog had last year. They were bad because they exposed the MD5 password. If that was the only issue with geeklog it would not have been so bad. But because you have no protections on the auto login the exploit was a huge security hole. Why you fixed half of the problem I do not understand especially when there were several SQL injection issues that exposed the password and used the auto login as the exploit vector. Ignoring the profile image issue will come back and bite you in the butt someday just like ignoring the auto login has.

As we say here in East Texas, I don't really have a dog in this fight since I won't be using geeklog to run our church site. I will continue my search for a simple and secure CMS so I will leave you with these comments to ponder and hopefully once you get past the sting they will prove beneficial.

- Jack
 Quote

Engel

Anonymous
Is this guy right about the holes. Will someone from the dev team let us know if we need to worry?
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Quote by: Engel

Is this guy right about the holes. Will someone from the dev team let us know if we need to worry?


The brute force attack against the auto login is quite possible (as already confirmed above). We'll take care of it.

bye, Dirk
 Quote

All times are EST. The time is now 03:46 pm.

  • Normal Topic
  • Sticky Topic
  • Locked Topic
  • New Post
  • Sticky Topic W/ New Post
  • Locked Topic W/ New Post
  •  View Anonymous Posts
  •  Able to post
  •  Filtered HTML Allowed
  •  Censored Content