119
The short answer is that many people are scanning everything most of the time.
Doing so was, some years back, considered impractical, but the combination of better networks, better tools better throughput, and more of the space being in use means that is no longer the case.
For example, Zmap claims on its front page:
ZMap is capable of performing a ...
33
These types of spurious requests are very, very common. They are either looking to see if you are already compromised, or looking to get your server to throw an error to gather info about your server (from error messages).
You aren't the only one:
http://shadow.wolvesincalifornia.org/awstats/data/awstats092014.shadow.wolvesincalifornia.org.txt
# URL with ...
14
This seems like it is just random scanners on the internet. They just roam around trying different IP adresses and looking for certain folders and files that might indicate vulnerabilities.
12
The attacker tries to find out if you have certain premade web software installed by requesting files which are typical for them.
When they find out you use, say, wordpress or phpbb or mediawiki, they can then try to use exploits specific to these applications to take over your site.
The best countermeasure against this is to avoid installing too much ...
11
Unless you have an expert in computer forensics it's gonna be very difficult to know what happened, what files were modified, and what kinds of backdoors were installed.
Since your web server is "huge" I assume you're following a good backup policy, right? Right? Once you have a breach, assume the server is compromised and restore to the most recent good ...
10
If you're using Apache for such applications, you may want to look into ModSecurity, mod_evasive and/or mod_qos. The latter two are more geared towards brute force and DoS attacks. ModSecurity though has a ton of stuff under its banner.
10
I've solved it by generating a fake certificate that doesn't reveal domain name and adding it as a default one on the start of the config:
server {
listen 443 default;
server_name _;
ssl on;
ssl_certificate /path/to/fake.crt;
ssl_certificate_key /path/to/fake.key;
return 403;
}
And yes, it requires a nginx with ...
10
Yes, those are scans.
If you Google those strings you will see that they show up in the web logs of numerous sites throughout the Internet, usually cheap webhost sites which put their logs up where Google can see them. This is sufficient indication that some tool is trolling for that URL.
There is not enough information to indicate what the scan is ...
9
Due to the nature of how SSL works, the SSL/TLS handshake is performed before the intended hostname is given to the web server. This means that the default (first) certificate is used when trying to access the site, regardless of the domain name used.
This is true with both Apache and nginx.
From the Apache Wiki:
As a rule, it is impossible to host ...
8
Absolutely absolutely pick up the Web Application Hackers Handbook by Portswigger (author of Burp), which is written as both an introduction to the concepts relevant to Web App reversing / hacking, but also as a step-by-step guide for applying those concepts with Burp Suite.
Note that the Second Edition is now available.
8
If you don't have permission to perform security testing against a target, don't do it.
In the US, you are definitely at risk of falling foul of the The Computer Fraud and Abuse Act 1986, 1994, 1996 and possibly other acts. It's easy enough to set up a test target of your own, ask a friend for permission to test their site, or use a service such as Webgoat ...
8
I actually went ahead and checked out your challenge and noticed that it required the cookie fusion_user for loading up the challenge. This can be confirmed from the BurpSuite Screenshot I have posted below:
Hence when scanning using nikto we will have to send across this cookie along with the requests.
There are two ways that I know of to do this.
Method ...
7
It is the ONLY way to be sure.
7
They can't snoop your traffic unless they are in a position of adjacency to any system in the routing chain.
When a client first connects to a server, the packet will go from their computer to their router, which then passes it on to the ISP's local routing server, which then passes it down a backbone (via a set of other large routers) and eventually to the ...
7
That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have.
A source-code disclosure vulnerability is when ...
6
I generally consider AVG to be reputable. When in doubt, you can always check against other scanning sites as well.
I don't know what to make of the "Javascript obfuscation" threat, but the Blackhole Exploit Kit is a clear sign of compromise.
Now, for the really bad news: The infected site is going to have to nuke their web server from orbit. Read the ...
6
And theres also OWASP Zed Attack Proxy: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
To quote from the home page:
"The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience and as such is ...
6
You could compare the Last-Modified HTTP headers for some static resources (e.g images, css), from each IP, and see whether they are different. If they are different I would assume the IPs are separate hosts.
You could also make a request to both IPs at the exact same moment and compare the Date HTTP header in the responses - if they are different then the ...
6
The truth is, any server with a public IP address connected to the internet will be scanned all the time. There are so many automated tools and scanners out there just looking for the low hanging, outdated, easily vulnerable servers.
You are looking for how to secure it, and that is a really important first step. You can not stop the scans. However, that ...
5
Have a look at the OWASP Top 10 Project.
OWASP has the best set of resources available online when it comes to web applications. You can learn plenty of information from there.
In addition, I would look into hardening the servers which your application run on. CIS has a good set of benchmarks you could base your audit upon.
As far as tools go - ...
5
Usually when exploiting logins you want to inject something that prevents the password field from ever validating. This can usually be accomplished by putting syntax similar to the following as your password:
myphonypassword' OR 1=1;--
This will claim that you are the admin user, terminate the string in the actual query and make the query don't care if ...
5
There is no magic test for testing for sql injection. Some applications may be vulnerable when using a certain approach and others when using another.
There is a chance that http://example.com/kb/8'/41 would not work because apostrophes are blocked by an IPS, but http://example.com/kb/7%2B/41 would display the same result as http://example.com/kb/8/41 and ...
5
You can do some automated scans with OWASP ZAP or Burp (Burp isn't free).
5
The problem is with the browser (or in the case of the linked CVE with Outlook).
The attack is as follows:
I create a file and send this file to the program with the MIME type image/png.
The browser ignores the MIME type and sniffs the content of the file (even I explicitly say that the file is of type image/png).
The browser determines (from sniffing) ...
5
If I understand you want to deny HTTP-Requests, which don't contain a Host header, even if these requests are inside a SSL connection (e.g. https-Requests). These are old-style HTTP/1.0 requests, HTTP/1.1 requires a Host header but also most HTTP/1.0 clients already send one. Blocking these clients can be done with:
if ( $http_host = '' ) {
...
5
Is your system publicly accessible?
Yes: Someone is probably scanning it.
No: Are you scanning the server?
Yes: Well, you've just answered your own question now haven't you?
No: It's probably not getting scanned.
I don't know: Wait... what?
I don't know: You've got bigger problems. And yes, you're probably getting scanned.
5
Configure your browser to point to Burp's proxy details (e.g. 127.0.0.1:8080) and then configure Burp to use an upstream HTTP proxy for all target hosts (* as the destination):
However, if the upstream proxy is SOCKS, not HTTP, you need to configure it underneath (under the SOCKS Proxy heading) instead. This causes everything to be fed through the proxy. At ...
5
Those log entries look like normal scanning activity.
You can also notice that the scanner did not target your setup specifically, because multiple versions and directories are tried. And as you said, none of those actually exist in your setup.
What I don't understand is, why does he use // rather than /
That's likely a bug in their scanning software (...
5
The idea of fuzzing is to send data to the interface with not much intelligence: garbage, random input and so on. When you are using a vulnerability scanner, you usually test for well known problems. In the case of web applications: injections and so on. It is possible that a vulnerability scanner can include some sort of fuzzing as one of the tests it ...
Only top voted, non community-wiki answers of a minimum length are eligible
