This morning I logged onto my website and shockingly I found that it just spit out error messages and some kind of upload form was displayed. A form that basically uploads a file onto my server.
I logged into my server and had a look at the access log. It seems he accessed the function file of my wordpress theme, fully deleted the original and created an upload form out of it.
With that upload form he then uploaded the following file.
Edit: I had to copy the code to hastebin, it was too big to be posted here.
http://hastebin.com/itedinefiz.php
He named the file web-info.php. I did not run the file because I am afraid that it might do some harmful things to my site.
Could anyone tell me what this file does?
Anyway, I have restored the functions.php file of my wordpress theme and deleted that web-info.php file form the server and now it seems that the website is running again.
Oh and my guess he gained access to my website because my login credentials were very easy... very stupid of me :(
After doing a bit research this what I came up with.
The malicious file that I have posted above, was encoded using eval(gzinflate(base64_decode));
Thanks to http://ddecode.com/phpdecoder/ I was able to decoded it, here is the raw PHP file that the hacker left behind:
http://pastebin.com/fAEQn2j7
I ran the file on my local machine, holy crap! It's a full on rootkit. It has massive interface that covers pretty much anything to take over the entire server. It seems to let you browser the entire files on the server, run sql code, run php code, brutforce options, network option and so on.
I think the safest it to cancel the entire VPS that I am renting from Bluehost, a normal wordpress deinstallation won't do any good.
Related
I am testing/learning how to send info from a Gravity form to a test file on my website.
I am using a testfile.txt that I added in var/www/ which is the location of the Wordpress directory.
The command I am running updates that file and I am able to see its contents when i go to the domain: mywebsite.com/testfile.txt.
The first time I run the Gravity form, I can see the changes on the webpage. However, after updating its contents to something else, the webpage does not update despite reloading it.
To troubleshoot this, I SSH'd into the server to see if the file was being updated and indeed it was...
So, basically, the file is being updated on the server but not on my GoDaddy domain... Has anybody encountered a problem like this? And if so does anyone have a solution?
I am no Expert in this field, Beginner to be honest. When I was learning Python flask a framework for building website, I had similar issue. Maybe the problem is that, when you visit your website it loads from the cache. To solve that press 'ctrl + F5', it forces a cache refresh, and will guarantee that IF the content is changed, you will get the new content. Again, I am beginner myself.
As #Sadman said, whenever I don't see my content getting updated I do a hard refresh or delete the cookies and cache manually. Either one of these solved my problem. To make a hard refresh press ctrl+shift+r or ctrl+f5 or shift+f5 on windows. On MAC this is cmd+R. I hope this helps!
i've got an issue with website made in asp.net. A site is published and online, i've made some modifications, republished site on my computer and just uploaded a .aspx file into the server via ftp.
First time it seems to have worked after a while. But i've made a small error and want to edit it again, i did the same, but it wont change. Could it be that i need to wait some time before changes are seen? Or could it be that there needs to be a server restart or something?
If you've edited something in the aspx.cs page you will need to upload the bin directory to the remote site, or better still republish the whole site.
If it is a change to the .aspx, css or javasctipt file, the original will most likely be cached in your browser. Try a differrent browser brand or refreshing the page, ctrl-f5 does a complete refresh.
If this error was by any chance a CSS mistake, that can be easily fixed by adding a "?" at the end of the address since CSS files are normally stored in the cache of the browser and the ? tells the browser to update them. Same thing is true about JavaScripts which are kept in individual files
I'd recommend you to use the Visual Studio Publish Website under the Build instead of manually uploading the site over FTP. That built in publisher provides you many advantages of which one of them is the same issue you have faced. When you make a small change, fixing the error in host would be very faster by republishing the site that way rather than manually upping it over FTP.
I have inherited a Drupal 6 site to maintain.
I am new to Drupal so there is an element of learning as I go.
I have encountered a strange issue after attempting to set up a test site on my local machine.
All my links on my local site continue to point to the live server. So all menus, login buttons, etc. all point towards the live site.
Steps I have taken:
checked settings.php to ensure that $base_url is set to "http://localhost:456"
checked settings.php to ensure that MySQL settings are correct
Taken an SQL dump of the entire local database and searched for any references to live site URL
deleted all the local cache data from database
Checked various blocks to ensure that there was no hard coding of links
Disabled language support as that does use separate URLS for each language
I am at a total loss as to where to go from here.
I can navigate through the site locally by replacing the URL in the address bar to point to the local site, and I have even managed to change the local theme so I can see which version of the site I'm on. The fact that I could do this means that the database is set up correctly.
Totally stumped as to where to go from here. Any takers?
The problem was that in the 'variable' table there was an entry with the URL for default language pointing to live site. There is a 'language' table which holds the URLS for each language e.g. eng.example.com for english and ru.example.com for russian. I had changed the urls here to point to local server, but it seems there is also an entry in the variable table which needed to be changed.
In case anybody runs into this problem and wants to change it, you need to change the metadata for the entry as well where S22 represents a string of 22 characters, you need to change it to the length of the string that you are entering, youll see what I mean when you look in the table!
Also, you need to clear your cache after making any change.
In your local server, go to your site directory->site->default and open your settings.php file
look for the base url and comment out that line it should be around line 144
The only thing left is you need to a search for the live site url in your complete code base. See if any module is changing the base url using the code. Though I am not sure how it can be done using code.
However instead of replacing the url you can edit the hosts file and add an entry like
127.0.0.1 livesite.com
If you are using Linux the location of the file is /etc/hosts
I had this problem. I moved the entire site from the remote to the local server to work on, but whenever I loaded the site it went to the live site. I believe the problem was the .htpaccess file. I updated all the core Drupal files, but as the .htpaccess file was hidden I didn't notice it was still there.
Note that even after I removed it, it wasn't until I opened a different site on the local server and then went back that the path worked correctly.
Dear Stack Over Flow Folks,
Hi, I have built a form input page in HTML that
has an action to post to an ASP handler/processor
.asp file. The form handler/processor .asp file
contains only <% Insert VBScript Here %> and no
HTML output whatsoever.
The .asp file was never intended to be a
"web viewable" .asp file like an .asp home page
file or html file would. It's supposed to be
for my eyes only- not the public's however
it does need to take info posted by the public
and do something with it on it's end.
I have used VBScript/ASP3.0 to build the form
handler/processor file and would like to know how
to keep someone from viewing the actual VBScript
in the handler/processor .asp file. I am aware of
obfuscation but I would like to know how to keep
prying eyes from even being able to take a look
at the obfuscated code in the handler/processor
file.
I realize that the server executes the .asp file
first before outputting anything to the browser so
I guess that my main concern is mostly that someone
may could "download" the form handler/processor .asp file,
then view it's contents on their machine.
Assuming the form handler .asp file is where it is,
behind the root, and is on a windows server
(no htaccess approach) how could one protect it so that
it could never be viewed or simply pulled down via
anonymous ftp or something like that?
Is there something like "script only" permissions that
the system administrator could set up for a particular
folder? Remember, with shared hosting I can't go above
the root. If so, would the form still be able to post?
How would any of you guys go about protecting the
asp file in addition to obfuscation? Any help would
be greatly appreciated.
Thanks,
ASP Pee-Wee
Unless your code encounters an error, no one should be able to view the contents of the ASP file in the browser. (If you haven't already, add on error resume next to your code, then add some error handling to prevent leaking too much information in any error message.)
If you can (might not be available with your shared-hosting) deny FTP access to all IP addresses except those you permit.
In a hosted environment, no matter what you do to protect your code, bad administrative/security policy by the host provider is a critical point of failure.
While the question specifies a shared-hosted environment, the best bet is to get a dedicated server and secure it yourself. If the information is important enough, the cost should be justified.
I have a hyperlink to an executable like so: Run Now
I'm trying to make the download dialog box appear without the save function as it is to only run only on the user's computer.
Is there any way to manipulate the file download dialog box?
FYI: Running on Windows Server '03' - IIS.
Please no suggestions for a WCF program.
Okay I found it for anyone stumbling upon this conundrum in the future.
Add the following tag to your head section: <meta name="DownloadOptions" content="nosave" /> and the file download dialog box will not display the "save" option.
For the user to not open/run but save replace "nosave" with "noopen"
Not unless you have some control over a user's machine. If your application can run on limited resources, you might want to consider doing it in Silverlight.
IMO, having a website launching an executable is a pretty bad idea.... even worst if that website is open to the general public (not on intranet). I don't know what that app is doing but it sure is NOT, 1) cross browser, 2) cross platform, and 3) safe for your users.
If you are on intranet, you might get away with giving the full server path (on a shared drive) to the executable and change security settings on your in-house machines.
Other than that, you won't succeed in a open environment such as the Internet.
From your comments, if the user downloading the file is the issue, then there's no way to get around it, as they have to download the file in order to be able to run it.
There's any number of ways to get around whatever you could manage in browser, from proxies like Fiddler intercepting the data, or lower level things like packet sniffing. Or even simply going into the browser's temp/cache folder and copying the file out once it's running.
You could probably get around most laymen by having a program that they can download that registers a file extension with Windows. Then the file downloaded from this site would have the URL of the actual data obfuscated somehow (crypto/encoding/ROT-13/etc). The app would then go and grab the file. The initial program could even have whatever functionality provided by what you want to download, but it needs the downloaded key.
But this is moving into the area of DRM and security by obscurity. If an attacker wants your file, and it's on the Internet, they will get the file.