@double-beep That pattern looks like it's already caught by Bad keyword in answer and Bad keyword in body; append -force if you really want to do that.
@double-beep That pattern looks like it's already caught by Bad keyword in answer and Bad keyword in body; append -force if you really want to do that.
> Pattern-matching email in body, pattern-matching email in title ---------- Pattern-matching email in body - Position 0-28: iyabiyehealinghome@gmail.com Pattern-matching email in title - Position 0-28: iyabiyehealinghome@gmail.com
[ SmokeDetector | MS ] Bad keyword in link text in answer, bad keyword with a link in answer, link at end of answer, potentially bad asn for hostname in answer, potentially problematic ns configuration in answer, +1 more (279): Add Content before footer by Allindiawatches on magento.SE
Someone posted a question on the Japanese SE with a hidden image with a link to : https://uroaapdpdfffggigugghuueeyzyrbbfpfof.000webhostapp.com/1/ ... is that something y'all can catch?
We could probably add a check to download all linked images from posts and alert if they're less than e.g. 5x5 pixels, but that would add a lot of traffic to the Smokey instances, I guess.
@Machavity I guess the question is more... if someone's doing it so that it's hidden rather than visible, is it still something that Smokey will pick up?
@Catija What Byte Commander said (not that I know what all would be involved). Smokey does regex searches for bad text. We could regex out HTML and markdown images served by *.000webhostapp.com but scanning images themselves is a whole different ball of wax
[ SmokeDetector | MS ] Bad keyword in body, bad keyword with email in body, email in body, potentially bad keyword in body (195): FINANCIAL LOAN HOME? by henry on money.SE
[ SmokeDetector | MS ] Bad keyword in body, potentially bad asn for hostname in body, potentially problematic ns configuration in body (98): Hack Mudah Super10 by CheatPasti on english.SE
@Catija @ByteCommander @Machavity It's not something that SD will pick up at the moment. I can certainly see it as a concern. As @ByteCommander has mentioned would could fetch the info for the URL pointed to by the src of each displayed image which isn't in the i.stack.imgur.com domain. I expect, the main issue with doing so is that it would add an additional wait to the process of checking a post.
I haven't looked at the code in enough detail to see how we're handling other checks which make requests from external resources. I know that at one point they were all synchronous. IIRC, there was work done to make them all async and then switch them over to a different method of handling async. If everything is async at this point, it shouldn't be too much of an issue to add a check for very small images.
In the meantime, we can add a regex check to pick up any additional images from that subdomain and/or a check for similar subdomains. For the similar subdomains, we'd need to pick what characteristics we're wanting to look for. That could be something as similar as a subdomain exceeding X characters without a -.
That, yeah... for the most part the img source and the link go to the same place... but even that the post used html instead of the markdown styling is odd.
@Catija It is all converted to HTML by SE. SD currently only looks at the HTML that is generated by SE, not the Markdown. We really should switch to looking at both, because there are some things we miss by not looking at the Markdown (they get stripped by SE when the HTML is produced). So, at the moment we can't check that it's done via actual HTML, except through there being attributes which are not available to Markdown.
@ByteCommander That is something that can be checked for. It would be significantly easier than other things that have been mentioned. My concern is that while it would catch the current instance, it won't catch the general issue of using a 1 pixel image to get viewing info. For instance, they could have had this be just a bare img without being wrapped in an <a>. Doing that is easy in either Markdown or HTML.
Anyway, the format is very similar but there's no ip crossover and the email address is really different so it's unlikely. I did hear there was something similar on info sec, though. Thanks for the link.
