This project is read-only.

Compromised Blog

Jan 5, 2016 at 9:57 PM
Edited Jan 6, 2016 at 4:19 PM
So I just visited my blog today and noticed that a prompt comes up asking for a username/password.

I haven't really changed anything in my blog for months, so I started investigating. I noticed the following script showing up in the post headers:
// EDIT: Removed script since it exposed a flaw
I only spent a few min on this and couldn't find exactly where the code was coming from. I did notice that in the be_Profiles table, the "displayname" for my user ends with an "</a>", so that was most likely altered my someone...

In any case, the code is being injected in the following in my PostView.ascx:
<span class="author">by <a href="<%=VirtualPathUtility.ToAbsolute("~/") + "author/" + BlogEngine.Core.Utils.RemoveIllegalCharacters(Post.Author) %>.aspx"><%=Post.AuthorProfile != null ? Post.AuthorProfile.DisplayName : Post.Author %></a></span>
I'll look into this later, but I'm wondering if anyone has come across something like this before. I tried searching around but came up empty.
Jan 6, 2016 at 2:00 AM
Edited Jan 6, 2016 at 4:31 AM
Thanks for reporting, I'll take a look at this.

Also, where have you found script tag - in the PostView.ascx markup or in the browser source view?
Jan 6, 2016 at 2:15 PM
Edited Jan 6, 2016 at 4:19 PM
The script tag was in the source view. My PostView.ascx is NOT modified in any way.

BTW, I did find where the script tag is located. The entirety of it is in the "SettingValue" column in the be_Profiles table, where the "UserName" is "filip" (my username), and the "SettingName" is "displayname". Before, I didn't realize that the script tag was there because SSMS was not displaying the entire contents of the column in results view. I was able to copy directly from the cell in SSMS, and this is what I got:
// Edit: Removed script since it exposed a flaw.
I'm still unclear on how the attackers were able to modify my "displayname" in the database. I'm guessing there is some kind of flaw which allows a remote user to update the database (or at least the be_Profile table) without being logged in. In fact, I'm pretty sure that they can't update the Users table, as it appears that they're attempting to create a User w/ the script that they injected.

I'm guessing that if I actually logged in my website as an admin, their script would be successful in creating the user. However, since I accessed my site as a guest, I got a prompt which requested my username/password.

BTW, I'm running BE 3.0 atm.
Jan 6, 2016 at 3:57 PM
Edited Jan 6, 2016 at 4:17 PM
Ok, so I figured it out (used their code against them!)

EDIT: removed since it exposes the flaw. I'm told patch will be issued in the near future.
Jan 6, 2016 at 4:09 PM
Just sent you email few minutes back :)
Jan 7, 2016 at 12:56 AM
I've just had the same issue, went to my website, authentication prompt kept popping up, did a diff on my backup and found the admin.xml compromised with a script in the display name field.

Any solution to before I start spending time trying to figure out how this was done?
Jan 7, 2016 at 2:05 AM
Jan 8, 2016 at 7:01 AM
My whole site got destroyed. Hadn't logged in in a while but I couldn't even run the updater so I did a manual upgrade and noticed that the user kept getting created. You should add notes to the patch that people will need to manually clean their profile.xml (in my case, user table if they are using a database?) or else everytime they login, the user get recreated.
Jan 8, 2016 at 2:47 PM
Edited Jan 8, 2016 at 5:29 PM
rtur wrote:
Posted here:
This link worked last night, but now it's a 404...

Never mind, seems to be working again now.
Jan 11, 2016 at 2:55 AM
By the way...

The hackers were successful in hacking my site further from the injected script (I was slow to upgrade since my auto-upgrade didn't work... turned out I had to do it manually). I must have accessed my site while being logged in and their script to create a new user was successful.

The passwords for all accounts were changed, and the hackers posted some long post. I didn't bother to read what it was about. Surprisingly, it didn't contain any links.

After cleaning up the stuff they insterted (I had to delete the user from the be_Users table, the role associations from the be_UserRoles table, and the post from the be_Posts table),I tested out the vulnerability that was there in the previous version and it appears to be patched.