Recon and Attack Vectors from My Logs
gist.github.com
gist.github.com
[1] https://github.com/mickael-kerjean/filestash/blob/master/ser...
Redirect to FSB then.
But the more real one would be sending something what could be executed on their side, ie some JavaScript or maybe PHP.
Most of the time it's nothign to gain there (because compromised machines or VM/jail/container) but still can be interesting, like finding out the real IP of the first machine or attempting to grab the cookies. Maybe even shellcode to get the AS info and send a note to abuse@.
I know it has zero effect, but it's more fun than a 404.
location / {
return 301 http://$remote_addr$request_uri;
access_log /var/log/nginx/spam.log;
}
- Content-Type: application/json, and body {"response"꞉ "success"} (hint: that's not an ASCII colon).
- Content-Type: application/json, and body [[[[[...]]]]] nested ten thousand times.
- Redirect to their own public IP, and at a random common port.
- Redirect to their own public IP in dotless hexadecimal notation (ping 172.217.23.110 -> ping 0xacd9176e).
- From[1], redirect to
http://example.com/;'$(gt=$(perl$IFS-E$IFS's//62/;s/62/chr/e;say');eval$IFS''cowsay$IFS''pwned$IFS$gt/dev/tty)';cowsay$IFS''pwned
- Pick a header, then insert one from [EICAR test string[2], \x00, \n] somewhere in the middle.
- Or just add a "Server:" header with a random line from the Big List of Naughty Strings[3].
- Redirect to a normal URL, but with a trailing dot in the domain name[4], like "example.com.". It's valid, but you'd be surprised how many things it breaks.
- Nested content encoding with "Content-Encoding: gzip, gzip, gzip, gzip, ...", with a random depth. The n-1 payload is "WAZAAAA".
- "Content-Type: image/jpeg" and "Content‑Encoding: gzip" with a valid gzip body... But the ‑ in "Content‑Encoding" is U+2011 NON-BREAKING HYPHEN.
- "Content-Type: image/jpeg" and "Content-Language: en-US\u000bContent‑Encoding: gzip" with a valid gzip body, where \u000b is a vertical tab.
- Spin the wheel of HTTP status codes! res.WriteHeader(rand.Intn(1000))
- Infinite loop sending a 100 (Continue) every five seconds (they might have a timeout for the TCP and TLS handshakes, and even a timeout for the next TCP segment... But did they remember to set a timeout for receiving the HTTP body?). Watch out for running out of connections.
[1] https://github.com/jwilk/url.sh
[2] https://en.wikipedia.org/wiki/EICAR_test_file
[3] https://github.com/minimaxir/big-list-of-naughty-strings
[4] https://en.wikipedia.org/wiki/Fully_qualified_domain_name
Love it.
That was a good Congress, another chap had set up a website that connected you to a random open VNC server on the internet.
I help filling in compliance excels when we get a new customer - explaining that "it does not work that way and 80% of this is not applicable to our systems" 10s of times.
Such automated tools are meant to be operated by someone who understands the technology.
That said, there is probably some API you use, they should be checking that instead.
My favorite mitigation is to reject all HTTP/1.0 requests. If they don't send HTTP/1.1 or newer, with the Hostname I'm expecting, I 404 them. This cuts down on substantially all of the random noise. (Could be 401 or other, but 404 seems to encourage a "try more but don't try harder" reaction, which is easier to handle than the converse).
Targeted attacks are more difficult. I use a WAF and path permit lists at the reverse proxy level. This is trivial, but still stops 99% of the rest.
The last and hardest thing to block is distributed brute force authorization attempts. I've built a list of hundreds of thousands of IPs that have been used in these attempts. Sometimes thousands of requests come in per second.
I use rate limiting on the auth request endpoint. Too much limiting will affect real users, so I have to be somewhat gentle here.
Known-exploited IP addresses get just one attempt before a long block. This means that real humans whose machines are part of a botnet are sometimes blocked from the service. This is not a great compromise.
especially as more and more of the world ends behind cgnat for ipv6 ip blocking will work less and less
You can also allow many more attempts from the known IP addresses for the user, as most users don't change their IP too much. Still, some do, but they will probably authenticate correctly within one or max. two requests.
But of course lots of legit authentication attempts come from new users, or new sessions. So I need to allow that case as well, and then we're back at square one.
imagine a blog with a comments section with a check box that says "bypass security check". if you click this, the admin scolds you saying "how dare you try and bypass security" and bans you. if you _dont_ click it, the admin laughs at you when you complain about too many captchas because "all you had to do was click the check box", idiot. either case can happen depending on which ideology the admin so happens to follow. thats the problem with wafs, they are ideological and opinion based but at the protocol level (but most wafs are such low quality that accidentally typing ' can get your ip banned).
If "WAF" bothers you, call it ingress/egress filtering (at the content level instead of packet level) instead.
In my architecture, the same services also perform egress filtering. It's also useful, but not the WAF or the topic of conversation.
I think people get upset about the term "WAF". It's just a new label for the longstanding practice of upper-layer ingress filtering (i.e. DPI and reverse-proxy filtering). But it's often a dedicated service now, so it needs a name of some kind.
A poorly-configured WAF breaks things, just like a poorly-configured (any other network service).
https://serverfault.com/questions/579124/what-is-http-cook-r...
Or perhaps a tool where you can check off some boxes about your setup and it generates a configuration for you?
In any event you could use a cookie.
The important part here is the list of scanned endpoints for blocking bad traffic is doing things the hard way.
I was commenting about the limitation of fail2ban and the potential for a kind of DoS if lots of users share the same IP. Then one naughty user can DoS all other users.
However, what I typically do with fail2ban is look at Nginx status codes like 4xx, 5xx and then rate limit them (e.g. ban if the rate is higher than expected in a given time). We also monitor our application logs for some errors, e.g. failed authentication or registration will also get matched and banned if over a certain threshold.
> The important part here is the list of scanned endpoints for blocking bad traffic is doing things the hard way.
Yes, I agree with you, even though there are some patterns that might be useful for placing instant bans? e.g. "../../" or if your site is not using php, then any access to a .php$ can get banned etc.
Serving a 404 is what would happen by default.
Penetration testers will raise HTTP server versions as a vulnerability, but RCE in http servers is uncommon now (most are application-level, and even then it’s less common by default).
Should we even care enough to log this level of attack anymore? I’d much rather look for application specific attacks such as direct object attacks (200 if they pass, 500 may be an IOC), etc
echo'zzzssdd';exit;
A waf is at best as good as AV, good as a catch all, but it won’t catch highly targeted stuff, and isn’t even a defensible boundary to protect the former.
The best part of a waf is the ability to add custom rules at runtime which can assist in blocking known vulnerabilities until they are remediated correctly.
I don’t think generic sql or XSS injection rules are at all effective not stop many real world attacks. I’ve also seen wafs create both an availability failure point, dos choke point, and be the most vulnerable product in the tool chain (see F5 code exec vulns).
AWS WAF would trigger a false SQL injection attack if the URL contains two "+" chars and the word "and". Or if you have a cookie with JSON in it would trigger the XSS attack rule.
Highly recommend setting up WAF logs to output some logs aggression tool (e.g Splunk) and create reports, dashboard, and alerts about WAF trigger rules & request HTTP code over a span to time and see what is going on with your requests and how WAF is evaluating the requests.
1% of WAF blocks were real attacks, my experience is with a site that had 25 million unique visitors a month (no user content). i'm not saying you shouldn't have WAF, i'm saying nothing beats good visibitily into WAF to correct it behavior over time.
There are few options on AWS marketplace such as Fortinet and F5 WAF rules. Fortinet is the better of the 2 and newer.
On the topic of mod_security in general, something like half of these are .php urls, and there's a good chance many readers aren't even running a php interpreter. Somewhere, there's a person attempting to convince the reader that that is exactly the sort of malicious traffic you need a WAF for.
its like when i tried to view a site but i was using tor and not a mainstream web browser so i had to solve 2 captchas to proceed (one for the main domain, and one for the cdn) but the captcha also takes 3 minutes to solve because its over tor and it doesnt like the speed i moved the mouse at
The parent comment might have been coming at it from the angle of having a firewall in front of your web app is helpful because it blocks a whole bunch of bad actor traffic from ever touching your app's servers.
Of which I would agree with too. A decently popular site could end up having at least 10% of its traffic being malicious. Let your app servers worry about the legit traffic and filter the rest beforehand.
In my experience, a lot of 'threat intelligence' data has a mysterious origin and is marginally useful. Yes, Tor exit nodes do bad things. Thank you, we sort of already knew that.
But I'm not sure that's really beneficial either. It would be interesting to observe trends (such as log4j) and we could see first hand how Tor exit nodes are used for abuse and maybe collect a large list of 'known bad' IPs.
Also, when we say an IP is bad (because it was observed doing a bad thing), how long do we keep it on the naughty list? 24 hours? More? Less? It may have been dynamically assigned and later some 'good' person will come along and want to use it to browse the web. If the IP is still on the bad list, that person will potentially be blocked by over zealous 'security professionals' who don't understand or don't care.
What other uses could be made of this type of log data?
> Also, when we say an IP is bad (because it was observed doing a bad thing), how long do we keep it on the naughty list? 24 hours? More? Less?
Look at GreyNoise's public feed - they provide historical data about IP's including the attacks they send. Most of the IP's end up being some kind of DC IP, not residential. Eg - https://viz.greynoise.io/ip/45.148.10.193
I agree with the questions you've raised, and think that vendors like Greynoise are helping sort out those issues.
The general trick seems to be: look at the rules of HTTP(S) and break them in fun and creative ways. Lie, break the standards, do weird networking stuff.
If they're coming from a country with an oppressive government that you don't mind risking a ban from, you may be able to get their government's firewall to get rid of them by sending forbidden texts, or HTTP 302 redirecting them to search engines with forbidden texts in their queries. For residential Chinese scanners, for example, querying for information about the Tiananmen Square massacre can cause the entire internet connection to get dropped for a short while. This may not work well with data center/server connections, but it can't hurt to try.
..or meth lab