Visbot Malware is being reported from the Magento Security Scan tool on my Magento 2 store. This is malware that looks to have infected Magento 1 stores from 2016. For some reason it is being reported on my clean Magneto 2 server. The file referenced below does not exist. Has anyone else seen this?
One or more 'Visbot' malware checks failed.
media/tmp/design/file/default_luma_logo.jpg
Our hosting company Nexcess malware scanner did not pick anything up. Ecomscan didn't either. Neither did sitelock server scan.
I had same issue with Magento 2.4.2-p1.
I asked Magento and they confirmed it is a false positive.
Here is their answer :
Hi,
I've been updated that this is a false positive. Currently, the HTTP
200 response with a non-empty response body to
{/pub}/media/tmp/design/file/default_luma_logo.jpg will trigger the
alert…
The standard Magento behavior prior to 2.4.2 is to return HTTP 404
response, the 2.4.2 returns the image placeholder. As far as we see,
for any image request under ‘/media/tmp/’ this store returns an image
placeholder if the file is not available. Please restrict the access
to ‘{/pub}media/tmp/design/file/default_luma_logo.jpg’ at the
webserver level.
Thank You,
I saw this error during my weekly scan on March 28, 2021.
One or more 'Visbot' malware checks failed.
media/tmp/design/file/default_luma_logo.jpg
The file doesn't exist. I rescanned my site and the error no longer shows up. I'm thinking it's most likely a false positive / issue with Magento's scanning script.
By the way, I just moved off of Nexcess and onto Cloudways (Linode data center). Much more bang for your buck. Nexcess service and support (for Magento) is not as good since it merged with Liquid Web.
Related
Servicestack Version: 3.9.71.0
Target Framework: .NET 3.5
Program background: has been in production use for over 3.5 years
Recently due to a customer security audit items were brought to our attention. All but one have been eliminated as IIS configuration changes.
The last item identified describes a situation in which the probing software accessed an endpoint without the proper authentication. This was fine and the expected result was the 403 Forbidden. The unexpected result was that the response body is displaying certain internal information of the server.
Based on quite a few articles I have searched it seams the the response body information being returned is a result of how Servicestack my be configured.
I realize this is a fairly older version of Service Stack. My preference would be to identify an IIS setting to override a forbidden response. Aside from that an option to just return a status code of 403 without the additional information. The third would be to create and use a custom 403 response object to control what is revealed.
Any guidance or help would surely be appreciated.. Thank you in advance.
ServiceStack v3 is a very old version of ServiceStack last updated in 2013. If you need to make any changes you'll need to create a custom build from its Sources
Looking at the v3 sources for how it resolves the ForbiddenHttpHandler:
ForbiddenHttpHandler = config.GetCustomErrorHttpHandler(HttpStatusCode.Forbidden);
It looks like you'll be able to override what HttpHandler is used by overriding the CustomHttpHandlers, e.g:
EndpointHostConfig.Instance.CustomHttpHandlers[HttpStatusCode.Forbidden] = MyHandler {...}
I have searched all over the internet for an answer and although I can find a million people with the same question I cannot find an official solution to the problem im experiencing.
I always get "Cannot display preview. You can post as is, or try another link." displayed.
I've stripped a page down to only the required open graph meta tags so I know they work (run through multiple OG validators), Ive disabled any kind of robots blocking, any kind of redirects, disabled the firewall on a test server, made sure the LinkedIn bot requests are hitting the server. All I see in the browser console all the time is a status 500 being returned from LinkedIn's preview generator API.
We are hosting on Windows Server in IIS 8.5, it seems if I create a demo and host it somewhere else it works, which makes me think it is server related or IIS settings.
Reading this Linkedin post's picture doesn't appear in summary its seems like a similar issue. We are not serving over SSL so nothing to do with that.
I have already asked this question on LinkedIn's forum but having no luck, so im hoping someone on here can help or someone from LinkedIn's tech team can help.
Thanks
So we had this issue as well and it turns out parts of our system that use user generated themes were not adding the "Content-Type" header to the response.
So examine the response headers coming from your server and make absolutely sure they are correct and that they include the correct "Content-Type" (with correct encoding) and "Content-Length".
has anyone seen this before so I am getting a 502 bad gateway error on my app, the issue I have is that the detailed error information I am getting says my requested url is https://SOX:80/api however my site is configured to use https://sox.domain.com and the site largely works pulling the various JS files required
my app service name is SOX in the azure dashboard so I assume that is where it is picking up SOX from but I have no idea why it is using this.
So overall the issue had me perplexed... however with more testing I soon figured out what was going on.
my backend is Dotnet core Azure throwing the 502 bad gateway was its way of handling exceptions ultimately the problem was code based.
I am mentioning this purely so that it will help others
my first issue was based on cert handling it seems dotnet runs in a container that is specified by your app name as i mentioned above https://SOX:80
the below was causing my issues
sslPolicyErrors = X509StoreStoreHelper.ValidateSSLPolicy(cert.Thumbprint, cert);
after commenting this out for testing my problem went away(we are putting in a proper fix )
my second issue came from using an unsupported view in Azure SQL master.sys.master_files which again just threw a 502 bad gateway error referencing https://SOX:80
please note I have used https://SOX:80 as a reference to mask the real site.
hope this helps the next person.
Based on your description, I have checked your site (https://sox.azurewebsites.net/) and found that it contains three static files (index.html,generic.html,elements.html). I viewed your website in Chrome incognito window as follows:
I did not find any requests against https://SOX:80/api in your html page or JavaScript files. Please try to access your website in a new incognito window to isolate the cache issue or just press CTRL + F5 to refresh your current page to narrow this issue. Moreover, you need to check whether you have configured URL Rewrite. If you still could not solve this issue, you need to update your question with the details for us to reproduce this issue.
We've hit a problem with some forms in the admin portion of our web app. There are a handful of forms that contain a large number of fields (it can range anywhere from one input field to the hundreds).
We've found that as these forms grow, there is a point where the server will throw 500 errors when a form is posted.
After running a test, I was able to find that the server can handle forms with 100 fields in them; once 101 or more fields are used, we get the errors.
We run Coldfusion, and we have determined that Coldfusion is not throwing this error. We never see this error logged in Coldfusion, so we are assuming IIS is throwing an error even before it sends the request to the Coldfusion server.
I'm assuming there is some setting in IIS 7.5 where we can up this limit. I've searched on the web, but all I can find is how to raise the byte-size limits of this data, not any kind of limit on a number of fields that are allowed.
So, am I right in assuming that this can be changed, and if so, how can it be done?
This is an issue introduced with hotfix APSB12-06. While it is a ColdFusion error, people have reported receiving the error in Tomcat, before it supposedly hit the CF server
There is a setting in neo-runtime.xml which defines the postsizelimit - and is defaulted to 100.
The full notes are located here, but here is the short version.
This hot fix has a new setting in ColdFusion, Post Parameter Limit. This setting limits the number of parameters in a post request. The default value is 100. If a post request contains more parameters as specified, the server doesn't process the request and throws an exception. This process protects against DoS attack using Hash Collision. This setting is different from Post Size Limit (ColdFusion Administrator > Settings > Maximum size of post data). This setting isn't exposed in the ColdFusion Administrator console. But you can easily change this limit in the neo-runtime.xml file. See point 5 below.
Customers who want to change postParameterLimit, go to {ColdFusion-Home}/lib for Server Installation or {ColdFusion-Home}/WEB-INF/cfusion/lib for Multiserver or J2EE installation. Open file neo-runtime.xml, after line.
<var name='postSizeLimit'><number>100.0</number></var>
Add the line below and you can change 100 with the desired number.
<var name='postParametersLimit'><number>100.0</number></var>
CF10+ has the setting available to edit within the CF Admin Settings page under Maximum number of POST request parameters under Server Settings -> Settings.
On our 9.0.1 server, we just increased the setting up to 10000 and have seen no adverse effects.
I believe you are bumping up against a security feature of ColdFusion. What ColdFusion version are you running? In ColdFusion Security Hotfix APSB12-06 they introduced a fix to protect against DoS attack using Hash Collision. From that page:
This hotfix implements a new setting in ColdFusion, Post Parameter
Limit. This limits the number of parameters in a post request. The
default value is 100. If a post request contains more parameters as
specified, server will not process the request and throws an
exception. This is done to protect against DoS attack using Hash
Collision. This setting is different from Post Size Limit (ColdFusion
Administrator > Settings > Maximum size of post data). We are not
exposing this setting in ColdFusion Administrator console, but this
limit can be easily changed in neo-runtime.xml file. See point 5
below.
Also on that page are instructions on how to increase that limit. Basically you have to make a change in your neo-runtime.xml file.
Customers who want to change postParameterLimit, go to
{ColdFusion-Home}/lib for Server Installation or
{ColdFusion-Home}/WEB-INF/cfusion/lib for Multiserver or J2EE
installation. Open file neo-runtime.xml, after line:
<var name='postSizeLimit'><number>100.0</number></var>
add the below line and you can change 100 with desired number.
<var name='postParametersLimit'><number>100.0</number></var>
I use the Google weather API in my web site, and today I get an error that the API link doesn't return any data.
When I check the link directly I get an (Error 403).
Here is the link.
Can anyone please tell me a solution for this and provide me another link for the API?
Every now and then the API stops working for short periods of time, the last days more often a 403 is trown. For my site, last night it happened 13 times. But the site tries immediately again and the second or third time, the data loads without problems. As the API is unofficial, not sure what’s causing the 403.
Make sure you cache the data as the API will block your IP temporary when you make too much requests. In my case, I cache for 20 minutes and if no data can retrieved, the site will not try more than 10 times to reload the API. Once I forgot to turn caching on after debugging and as my site did many hundred requests (with every visitor), the IP was blocked within an hour. If a remember correct, the error was not a 403. Fortunately, the block lasts for less than a half day.
There is currently an intermittent 403 Forbidden response to the Google Weather API that you are using. See Google Weather API 403 Error
The reason for the intermittent 403 response is not known but has been a problem since the 7th of August 2012.