email spammers hijacking blog mail mechanism

[edgeless]

I'm unsure if this has been covered in the v4 discussion area before. I was able to find a thread in the v3 area that basically advised to do the same thing I'm showing below. But the code in the template has seemingly changed between v3.x and v4.x. Please understand that I'm merely posting this in case it may help someone who is experiencing the same issue with v4.x.

Here's the issue:
Email spammers were able to use the Email Blog Entry to a fiend mechanism to send mass spam messages out from my forum site in Guest mode. The message count total reached about 1500 before I resolved the issue. This occurred within a 24-hour period.

What didn't work:
I first tried disabling all guest and member email functions (both in the usergroup area and the email settings area). But none of that changed anything.

What did work:
I used iftop in the server's root terminal to pinpoint the IP sending the traffic...

65.xxx.xxx.xxx:http => 122.52.73.206:28249 68.1Kb 13.6Kb 3.41Kb
<= 4.66Kb 954b 239b
65.xxx.xxx.xxx:http => 122.52.73.206:28213 0b 9.65Kb 2.41Kb
<= 0b 794b 199b
65.xxx.xxx.xxx:http => 122.52.73.206:29200 160b 10.8Kb 2.71Kb
<= 736b 970b 243b
65.xxx.xxx.xxx:http => 122.52.73.206:29199 2.50Kb 551b 138b
<= 12.1Kb 2.48Kb 636b


On the Who's Online display, I then searched for and located the spamming IP (122.52.73.206) among the connected users...

Guest 11:04 AM /entry.php?7-blog-entry-6-from-The-Cobalt-Foundation&amp;do=sendtofriend Sending Blog Entry to a Friend 122.52.73.206
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .N


Take note that the forum location item is: "Sending Blog Entry to a Friend".

Next, from the admin cp, I edited the blog_show_entry template to remove the following code...

<vb:if condition="$show['emailentry']">
<li><a href="{vb:link entry, {vb:raw bloginfo}, {vb:raw pageinfo_sf}}"><img src="{vb:stylevar imgdir_misc}/blog/email_go.png" class="inlineimg" alt="{vb:rawphrase email_blog_entry}" /> {vb:rawphrase email_blog_entry}</a></li>
<vb:if condition="$show['member']">
<li class="separator">|</li>
</vb:if>
</vb:if>


Problem solved.

As an extra precaution, I blocked IP range 122.52.73.0/24 (which shows to be based in the Philippines) at server level within my filter rules.

One thing that I don't quite understand is why vB does not offer a toggle to disable the 'email blog entry to a fiend' function. That seems like a no brainer to me.

[MarkFL]

If you want to continue to allow registered users to email blog entries, but prevent guests from this feature, then change the block of template code to:

<vb:if condition="$show['emailentry'] AND $show['member']">
<li><a href="{vb:link entry, {vb:raw bloginfo}, {vb:raw pageinfo_sf}}"><img src="{vb:stylevar imgdir_misc}/blog/email_go.png" class="inlineimg" alt="{vb:rawphrase email_blog_entry}" /> {vb:rawphrase email_blog_entry}</a></li>
<li class="separator">|</li>
</vb:if>

[edgeless]

Good information. Thank you for that!

[edgeless]

Well, contrary to what I reported above, the problem wasn't resolved after all. But it is now. As it turns out, removing the mentioned code from the blog_show_entry template only had the effect of eliminating the "Email blog entry" links from blog entries. When I decided to test my fix by temporarily removing my IP filter blocking strings I was disturbed to find that the spammer was still able to commandeer the vB blog email provision to send huge amounts of spam through my forum. So I set the IP filtering again - I have been blocking the entire subnets btw. But the spammer eventually changed subnets and resumed. And he did this over and over. I would block a subnet and the spammer would in turn change the subnet he was using to send the spam messages. This happened 4 times... each of the 4 octets were entirely different every time he came back. And it was easy to tell it was the same guy because each subnet was owned by the same Internet company from the Philippines and the outgoing spam messages were identical.

Surprisingly, there seems to be little about this vB blog vulnerability on the searchable Internet (that I've found, at least). But by just looking over the blog templates, the fix seemed obvious to me. And I will tell you, I was very much hoping that what seemed might be the answer would in fact solve the problem! Thankfully it did :)

So here's the confirmed fix:

1. Go ahead and do that first part I posted about by editing the blog_show_entry template and removing the following code:

<vb:if condition="$show['emailentry']">
<li><a href="{vb:link entry, {vb:raw bloginfo}, {vb:raw pageinfo_sf}}"><img src="{vb:stylevar imgdir_misc}/blog/email_go.png" class="inlineimg" alt="{vb:rawphrase email_blog_entry}" /> {vb:rawphrase email_blog_entry}</a></li>
<vb:if condition="$show['member']">
<li class="separator">|</li>
</vb:if>
</vb:if>


2. Now edit the blog_send_to_friend template and delete its entire contents, then save your changes. <- That's the part that I considered an obvious thing to try.

3. Perform steps 1 and 2 on every style that is active on your vB forum site.

So performing the above simple steps really seems to do the trick. It entirely disables email for the blog component, including the vulnerability. I've removed all of my filter blocks for the spammer's IP ranges and everything seems quite secure now.

One thing I don't understand is how this vulnerability allows spammers to hijack a forum site's mail sending mechanism through the vB blog component. I enabled human verification and it worked fine at members level for access to the 'Email blog entry' function. But the spammer was somehow still able to send spam messages like mad through the system. It would have been nice if vB had detected this vulnerability and mitigated it when they were still focusing on vB 4.x.x. But short of that, it would have been nice if they had included an easy option to toggle off email functionality within the blog component. But they clearly did neither.

I wonder how much of this issue is affecting forum owners who may not be aware why the email BL reputation of the IP they send their mail from is diminishing. If admins don't watch for this they may not even know it's happening. I happen to be someone who closely monitors my outgoing mail, so thankfully I noticed when it hit and I began trying to find a way to resolve it.

Again, I hope this thread helps someone at some point.

[ForceHSS]

Why not just change group permissions

[edgeless]

Why not just change group permissionsI guess I didn't think of it and no one recommended it. Do you mean set the usergroup permission for Unregistered/Not logged in for the blog section to 'no' at "Can use Email to Friend"? It seems like it should work... but then they were somehow able to bypass the human verification system. So I'm not sure what they are doing or injecting, or where. Definitely something to try, though.

EDIT:
Actually I did try that and it did nothing. When I wrote my reply above I was somehow thinking there was a permission control item for the vB blog under Usergroups > Forum Permissions... but there's not. What I had already tried was setting Usergroups > Usergroup Manager > Unregistered/Not Logged In (and each of the other usergroups) > "Can Use Email to Friend" to 'no" but it had absolutely no effect on the spammer's ability to access the system and send his messages. In fact, that permissions change is one of the first things I tried. I'm sorry about my confusion there for a minute about the Forum Permissions list. So the only thing that has worked is what I have detailed above.

[Dan Druff]

To truly solve this for certain, you need to go into blog.php and comment out all of the functionality of the "start sendtofriend" routines (there are two of them in vB4).

That is, find these two if blocks:

if ($_POST['do'] == 'dosendtofriend')
{
}
and
if ($_REQUEST['do'] == 'sendtofriend')
{
}

... and just comment all of the code out within each block.

The staff of VBulletin has been very dismissive of this issue, claiming it's just a problem on super-obsolete VB3. That's not true. The problem persists in VB4, as well. They need to patch this.

[ForceHSS]

I guess I didn't think of it and no one recommended it. Do you mean set the usergroup permission for Unregistered/Not logged in for the blog section to 'no' at "Can use Email to Friend"? It seems like it should work... but then they were somehow able to bypass the human verification system. So I'm not sure what they are doing or injecting, or where. Definitely something to try, though.

EDIT:
Actually I did try that and it did nothing. When I wrote my reply above I was somehow thinking there was a permission control item for the vB blog under Usergroups > Forum Permissions... but there's not. What I had already tried was setting Usergroups > Usergroup Manager > Unregistered/Not Logged In (and each of the other usergroups) > "Can Use Email to Friend" to 'no" but it had absolutely no effect on the spammer's ability to access the system and send his messages. In fact, that permissions change is one of the first things I tried. I'm sorry about my confusion there for a minute about the Forum Permissions list. So the only thing that has worked is what I have detailed above.
for Unregistered / Not Logged

Blog General Permissions
Put all settings to no

Blog Entry Permissions
Leave this setting to Yes
Follow Blog Moderation Setting
The rest put all to No

Blog Comment Permissions
Leave this setting to Yes
Follow Blog Comment Moderation Setting
The rest put all to No

[edgeless]

Okay. So there are now 3 methods described in this thread for precluding the vB blog sendtofriend exploit. And that tends to raise some questions... at least for me.

Those questions (in no particular order):

1. Has the blog permissions solution been tested against this precise threat?

2. Why didn't vBulletin include an optional permission within the blog permissions section to simply render the "Email Blog Entry" mechanism inaccessible to everyone (effectively turning it off)?

3. Since I know that the blog.php edit solution works (because Dan Druff implemented it back in 2014 and in so doing he has entirely eliminated the exploit from his blog component), and because my method of simply rendering the blog_send_to_friend template inoperative has absolutely and immediately worked for me to stop this remote spamming process cold, I would like to know the following:

a) Is one of the above solutions better than the other.. and if so, why?

b) Am I likely to encounter some negatives (i.e., functionality problems etc.) down the road stemming from my blog_send_to_friend template edit solution, which I would avoid by using the blog.php edit solution instead?

Here's why I'd like answers to the above questions. First, my template edit is currently in place and I've already proven that it's working perfectly to keep the spammers out. So is there a compelling reason for me to change solutions? And next, the remote spam sending campaigns that utilize this vulnerability can be quite few and far between. So it's not that easy to confirm that a replaced solution is actually working. Therefore, changing solutions may leave me wondering indefinitely. Whereas right now I have peace of mind that I have precluded the problem. But again, if there's a negative side-effect from my method that I'm unaware of, that may be a game changer.

Any comments will be appreciated.

[Dan Druff]

for Unregistered / Not Logged

Blog General Permissions
Put all settings to no

Blog Entry Permissions
Leave this setting to Yes
Follow Blog Moderation Setting
The rest put all to No

Blog Comment Permissions
Leave this setting to Yes
Follow Blog Comment Moderation Setting
The rest put all to No

Even if this works to fix the problem (I'm not sure if it does or doesn't), isn't there still the issue that someone can simply register and then spam that way?

On vbulletin.com, this discussion came up regarding VB3. The vBulletin staff member acknowledged that this was an exploit and couldn't be stopped completely without a code change, but said that VB3 is too obsolete for them to be patching at this point.

So I'm going to assume that no settings would fix this problem.

I still think one is safest with the code change, as that absolutely 100% solves it (since the functionality is gone). However, the one problem with code changes is that you may lose it when you upgrade to another vBulletin version.

[ForceHSS]

Even if this works to fix the problem (I'm not sure if it does or doesn't), isn't there still the issue that someone can simply register and then spam that way?

On vbulletin.com, this discussion came up regarding VB3. The vBulletin staff member acknowledged that this was an exploit and couldn't be stopped completely without a code change, but said that VB3 is too obsolete for them to be patching at this point.

So I'm going to assume that no settings would fix this problem.

I still think one is safest with the code change, as that absolutely 100% solves it (since the functionality is gone). However, the one problem with code changes is that you may lose it when you upgrade to another vBulletin version.
No spammers can register on my site ever also to use my blog, you need to be in a special group that I put only trusted members. There are many default settings built in to vb that you can do without changing the coding