• Welcome to the DeeperBlue.com Forums, the largest online community dedicated to Freediving, Scuba Diving and Spearfishing. To gain full access to the DeeperBlue.com Forums you must register for a free account. As a registered member you will be able to:

    • Join over 44,280+ fellow diving enthusiasts from around the world on this forum
    • Participate in and browse from over 516,210+ posts.
    • Communicate privately with other divers from around the world.
    • Post your own photos or view from 7,441+ user submitted images.
    • All this and much more...

    You can gain access to all this absolutely free when you register for an account, so sign up today!

Changes to Registered User Privileges

Thread Status: Hello , There was no answer in this thread for more than 60 days.
It can take a long time to get an up-to-date response or contact with relevant users.
The limiting of some of the privileges reduced some of the spam, but there is still a lot of it in the forum, both in old threads and at new posts as well. I just did a quick search and found and reported to admins some 20 spammers. However, that's just the tip of the iceberg, and there are still many more of them.

Some of the spam bots use sophisticated methods to cloak in their spam links. The result is, that not only the Google ranking of the spammer websites improves significantly, but especially the links can harm the SEO of Deeper Blue, and that they can get DB blacklisted on Google, or have visitors coming though Google warned and discouraged from visiting as it happened several times in the past. And of course, if someone is carefree enough to follow those links, and not protected enough, he can get infected by viruses on the target website.

Originally, in April, I suggested banning all links in signatures (new and old ones) for all non-paying members. Unfortunately, instead of banning links, signature images were banned. That's completely useless, because (contrary to what some people may think, and to contrary what was stated here too) images can in no way harm neither the visitor, nor the server. It is a myth, there is no way a virus or active content could be hidden in an image and launch an attack automatically. More than ten years ago, there was a buffer-overrun vulnerability in certain graphical software products. Computers with those graphic engines could have been potentially harmed with some manipulated images, but that's fixed since a long time, and I do not think there are still some computers vulnerable to this issue.

So jpeg, gif, and png images are completely harmless, and it is futile to ban them in the signatures - it only harms regular members. Spammers/hackers do not bother about images. They need hyperlinks, and can only use images to hide hyperlinks if hyperlinks are enabled, but unfortunately hyperlinks in signatures were not banned, so spammer continue to flood and harm the forum.

So my recommendation is re-enabling images in signatures, avatars, and in messages (at least for those who have more than ~10 posts), but banning, instead of it, all kind of hyperlinks in signatures, in messages, in PM's, in visitor messages (there is a lot of spam on DB too), and in all profile fields. I'd recommend allowing hyperlinks in signatures and profile fields only to paying members (supporters), and hyperlinks in forum messages and PM's (not visitor messages!) only to members with more than 10 or 15 posts.
 
Thanks Trux - I'll be looking at the options and definitely take on board what you say. I need to look at all privileges shortly.

One thing I do want to correct is that you can have images with hidden payloads. It depends on how there server is setup but both the forum and gallery can be hit by hidden payloads and is one of the most common ways forums get compromised. We are pretty good at locking things down but attack vectors change all the time.

For example the latest blacklisting we got from google was due to a vulnerability in our ad server which required significant adjustments on our part. Not image related but once the server was compromised one of the methods of delivery was a poisoned image.
 
One thing I do want to correct is that you can have images with hidden payloads. It depends on how there server is setup but both the forum and gallery can be hit by hidden payloads and is one of the most common ways forums get compromised. We are pretty good at locking things down but attack vectors change all the time.
The image can be only used to deliver hidden content, if either the server or the client are compromised. So if you use a misconfigured, or a viral ad server, or if the client has a Trojan browser add-on, images can be used to deliver executable content, but otherwise there is no way it could be done. So I'd just recommend selecting your ad server carefully, and not allowing any Flash or Active-X ads. There is no way an image you host for avatars or signatures could contain a hidden executable content.
 
Last edited:
Actually the payload mechanism is to upload a php file as a jpg or gif. Don't want to get into the specifics here Ivo but I have been at this for quite a while and have seen multiple attempts using this method amongst many many more. There are ways of securing against it but there is always a compromise between user functionality and potential attack vectors on a server.
 
Actually the payload mechanism is to upload a php file as a jpg or gif. Don't want to get into the specifics here Ivo but I have been at this for quite a while and have seen multiple attempts using this method amongst many many more. There are ways of securing against it but there is always a compromise between user functionality and potential attack vectors on a server.

True - you can compromise servers through images if not careful and also probably even user accounts potentially through XSS. Easiest thing to do probably for the server side of things and uploads in general would be to use some service like Amazon's S3 or other solution so that the images are not hosted on the same server as the application.

I do agree though with Trux about links - I am on my phone right now so I can't check but you should at least make them 'nofollow' if they're not already, it might put off some manual spammers and link builders as the links will be of less value for SEO purposes.

Also again I am not sure what the policy on links/signatures is but some other forums do not allow links or signatures before X posts have been made by the user, by which point you'd hope it would be identified if they were spammers or they'd get bored and give up.
 
Actually the payload mechanism is to upload a php file as a jpg or gif. Don't want to get into the specifics here Ivo but I have been at this for quite a while and have seen multiple attempts using this method amongst many many more. There are ways of securing against it but there is always a compromise between user functionality and potential attack vectors on a server.
I am a hardcore security and low-level pro programmer so I know what I am speaking about. If you host an image file, and serve it as such, there is no way the image could harm anyone. Well, OK, I admit that if you post an image of Lady Gaga, it may cause some mental harm to weaker individuals, but that's all. Technically it is simply impossible to pass any malicious content through images. Different exploits trough PHP or other scripts transforming the MIME headers of images may be able to cause some harm to poorely protected clients, but it is impossible if you have the full controll of the image file that is hosted by your or another trusted server.
 
I am a hardcore security and low-level pro programmer so I know what I am speaking about. If you host an image file, and serve it as such, there is no way the image could harm anyone. Well, OK, I admit that if you post an image of Lady Gaga, it may cause some mental harm to weaker individuals, but that's all. Technically it is simply impossible to pass any malicious content through images. Different exploits trough PHP or other scripts transforming the MIME headers of images may be able to cause some harm to poorely protected clients, but it is impossible if you have the full controll of the image file that is hosted by your or another trusted server.

You can include PHP code in JPGs etc - then, depending on how the site is coded, there are vulnerabilities that might allow a hacker to run that PHP code on the server and thus take over the server, NOT clients.

Of course there are ways to guard against it but not always as straightforward, especially with open-source code you haven't written yourself since hackers have access to your source code and can spot vulnerabilities. Depending on the vulnerability, even hosting the files elsewhere might not help but it's a start.

There are also ways to bypass checks in the application for file extension etc.. PM me if you want and I can send some references if interested but it's public info on OWASP etc anyway
 
Last edited:
I am a hardcore security and low-level pro programmer so I know what I am speaking about. If you host an image file, and serve it as such, there is no way the image could harm anyone. Well, OK, I admit that if you post an image of Lady Gaga, it may cause some mental harm to weaker individuals, but that's all. Technically it is simply impossible to pass any malicious content through images. Different exploits trough PHP or other scripts transforming the MIME headers of images may be able to cause some harm to poorely protected clients, but it is impossible if you have the full controll of the image file that is hosted by your or another trusted server.
Ivo - I really don't want to get into a battle about this but depending on how the server is configured you can upload php files or code either as or in JPG's and use that to open exploits on the server. That is exactly why we had to remove sig images as it was being used as an attack vector on vbulletin and some of the plugins used in it.

Anyway - back into the topic at hand. I am looking at privileges today so will implement some of your suggestions.

As an aside - removing images in signatures was only supposed to be temporary until we implement a tougher set of levelled privileges.

Cheers!
 
Of course, PHP code may be incuded in any file, but if your server or application permits the execution of such code, you have to have an important security hole in your server or in the application you use. First of all it needs to be fixed, and the security hole plugged. Removing functionalities is not the fix. It may be a usable quick temporary measure to prevent abuse, but it definitely is not the solution. It is not the image to be blamed, but the setup or application. There are milions of websites worldwide allowing image uploads without exposing them to hacker attacks. So do not blame the images, blame the setup.
 
Trux - correct and we allow image uploads in various forms but signature images were subject to significant abuse hence the initial removal of that feature for everyone apart from supporters.

As we use third party coded solutions we are sometimes limited by their security measures in what they require in server setup hence why there are occasional challenges.

I only have so much time on my hands to configure the server, keep things patched, monitor the sites, add content, moderate and generally run the sites - remember this is only something i can do in my spare time (of which there is very little) so as always bear with me as I try to implement suggestions in a controlled manner that fits in with our application and server configuration.
 
Of course, I understand perfectly the problem of the limited time, and do not complain about it at all. I am rather surprised by the ilogical way of limiting images (including exteral ones) in signatures, while allowing then in messages. That does not make sense. If there is a security hole in vBulletin allowing the execution of code in an uploaded image, the image in a message can be used in the same way as at a signature image.

Banning all uploads would make more sense. In contrary, banning the IMG tag for the inclusion of images from external websites, as it happened, makes no sense at all. If there is a security hole in the application allowing the execution of code in uploaded files, the IMG tag has nothing to do with it. No code can be executed from external files, and even if the server had such a terrible security hole that it permited the execution of files on other servers, banning the IMG tag would not impact it in any way, and would not prevent it.

So if you need more time to fix the security hole in file upload, take as much time as you need before you are sure the hole is plugged. But if you ban uploads, ban them consistently. In the same time banning IMG tags is completely useless, and I see no good reason for disabling them.
 
Of course, I understand perfectly the problem of the limited time, and do not complain about it at all. I am rather surprised by the ilogical way of limiting images (including exteral ones) in signatures, while allowing then in messages. That does not make sense. If there is a security hole in vBulletin allowing the execution of code in an uploaded image, the image in a message can be used in the same way as at a signature image.

Banning all uploads would make more sense. In contrary, banning the IMG tag for the inclusion of images from external websites, as it happened, makes no sense at all. If there is a security hole in the application allowing the execution of code in uploaded files, the IMG tag has nothing to do with it. No code can be executed from external files, and even if the server had such a terrible security hole that it permited the execution of files on other servers, banning the IMG tag would not impact it in any way, and would not prevent it.

So if you need more time to fix the security hole in file upload, take as much time as you need before you are sure the hole is plugged. But if you ban uploads, ban them consistently. In the same time banning IMG tags is completely useless, and I see no good reason for disabling them.

Crazy as it may sound (and you are right in that the application needs to be fixed but not always easy especially with big open source projects), you can also execute files from external files if the application has some vulnerabilities - don't know if the image tag helps prevent this though but I don't know vbulletin. Will send you some details in a PM.
 
Of course, I understand perfectly the problem of the limited time, and do not complain about it at all. I am rather surprised by the ilogical way of limiting images (including exteral ones) in signatures, while allowing then in messages. That does not make sense. If there is a security hole in vBulletin allowing the execution of code in an uploaded image, the image in a message can be used in the same way as at a signature image.

Banning all uploads would make more sense. In contrary, banning the IMG tag for the inclusion of images from external websites, as it happened, makes no sense at all. If there is a security hole in the application allowing the execution of code in uploaded files, the IMG tag has nothing to do with it. No code can be executed from external files, and even if the server had such a terrible security hole that it permited the execution of files on other servers, banning the IMG tag would not impact it in any way, and would not prevent it.

So if you need more time to fix the security hole in file upload, take as much time as you need before you are sure the hole is plugged. But if you ban uploads, ban them consistently. In the same time banning IMG tags is completely useless, and I see no good reason for disabling them.
Some changes have been made and i'll make a post later about it.

As an aside - vBulletin handles signature images, post images and file uploads all slightly differently. The original reason for banning sig pics has gone and the original attack vectors used have been removed as well so it was just a matter of setting up the right user privileges.
 
Crazy as it may sound (and you are right in that the application needs to be fixed but not always easy especially with big open source projects), you can also execute files from external files if the application has some vulnerabilities - don't know if the image tag helps prevent this though but I don't know vbulletin. Will send you some details in a PM.
Simos you are mixing apples and oranges. If someone is stupid enough to write a code allowing remote execution of files, it has absolutely nothing to do with vulnerability of image files. If remote inclusion is open to abuse, it is a security hole in the code, and not a vulnerability of jpegs. And of course, if remote inclusion of scripts is possible, banning of IMG tags won't help you the smallest bit.
 
Simos you are mixing apples and oranges. If someone is stupid enough to write a code allowing remote execution of files, it has absolutely nothing to do with vulnerability of image files. If remote inclusion is open to abuse, it is a security hole in the code, and not a vulnerability of jpegs. And of course, if remote inclusion of scripts is possible, banning of IMG tags won't help you the smallest bit.

Of course, as I wrote you in the PM. But if you can't fix the holes in the application immediately then you can take some temporary measures which is what Stephan did by the sound of things.

Removing image tags could help against XSS potentially if you have a vulnerability there (maybe someone was trying to manipulate the file name etc) but as you said wouldn't help with server side issues unless the vulnerability was in the code that was reaponsible for putting the image tag there in the first place.

Anyway I have no clue what the real vulnerabilities were it's just an educated guess.
 
Regardless of security (I'll let ye argue that) I think its a great shame we are a community site but cannot represent non paying members with an avatar... I think the avatar is an expression of personality and character and one of the ways a social site works.
 
Of course, as I wrote you in the PM. But if you can't fix the holes in the application immediately then you can take some temporary measures which is what Stephan did by the sound of things.
Right. That's also why I did not tell anything during 8 months, but I think that such an important provider of commercial software as vBulletin (or its plugins) plug any security holes within hours, not within months. If images, signatures, and avatars were such an easy security hole, thousands (or perhaps tens of thousands) of forums worldwide would go down very quickly.

Removing image tags could help against XSS potentially if you have a vulnerability there
No, there was no XSS vulnerabilty in IMG tags in this version of vBulletin.
 
It may not be down to the core vBulletin product but could be one of the plugins (free or commercial) and also down to how the file system and server configuration is setup. It could be a combination of factors.
 
I'm also being vague(ish) as I don't want to talk about specific security holes on an open forum.
 
A couple of things to note:

1. The last exploit that caused the change in privileges was a combinations of factors - including being able to get poisoned images onto the server and use that to execute code. It was a number of factors and products involved.

2. I'm about to post to let everyone know that user privileges have been restored for all members who qualify as full registered members after an initial period as a newly registered member. All normal full members have signature, avatar and image posting rights.
 
DeeperBlue.com - The Worlds Largest Community Dedicated To Freediving, Scuba Diving and Spearfishing

ABOUT US

ISSN 1469-865X | Copyright © 1996 - 2024 deeperblue.net limited.

DeeperBlue.com is the World's Largest Community dedicated to Freediving, Scuba Diving, Ocean Advocacy and Diving Travel.

We've been dedicated to bringing you the freshest news, features and discussions from around the underwater world since 1996.

ADVERT