XMPP Service Operators - 2020-09-21

new spmamer

jessieb@draugr.de

fcrazytapok@conversations.im OTR spam

I've noticed a pattern too

They send two roster requests over several days before sending the OTR spam

You don't have to accept them

interesting

any other visible patterns?

The names

random letter + wordlist item?

They appear to be (although I haven't had enough spam to tell for sure if this is definitive or not yet) ascii constisting of a word and a couple random letters

But always US-ASCII

And at least one word

Well, most JIDs consist of US-ASCII

Yeah but the spam is in RU/EN

Are there any pattern that can be used to differentiate them from real users?

So you'd think they'd also have a cyrllic name

I have many russian users on my server, but most of them also use latin names

I don't think I can give you any more differentiateable patterns yet Ge0rG

I'd also take raw XML ;)

Oh

Unfortunately, the spammers didn't spam me yet.

Well I'll be sure to capture that next time

I prefer cooked XML over raw

But

jonas’: watch out, or I'll serve you some vegan JSON

Ge0rG, JSON can’t be vegan

too much suffering associated with JSON

When I send out the abuse reports to other operators, it's usually the case I hear back random IPs opened thousands of accounts a while ago

And just now started becoming active

tom: that's the usual pattern.

And the operator is able to remove the accounts based on a bunch being registered in a timeframe

tom: https://yaxim.org/blog/2020/05/12/new-anti-spam-measures/ has helped significantly

I prefer beef and onion json

which is less suffery than the vegan json i,ve eaten

Well if that's the case maybe we could look at honeypotting new accounts after they dramticlly exceed normal new user rates

As in

Don't cancel them just capture the XML and pretend success

I prefer not to silently blackhole new accounts, as there can always be false positives.

Ge0rG: can you add my jid as a member to the yax.im spamfighting chat?

I tried joinging but it was members only

I need an invite

Ge0rG: do you know what kind of captcha the spammer is talking about?

The one he claims he can bypass

Bypassing google recaptcha is hella easy and there are services for that

But I was wondering if maybe there was a monoculture of captchas in the XMPP fedisphere

And that's why bypassing was so effective, or he/she was talking out of their ass

» ** 2020-09-21 » [02:47:01] <fcrazytapok@conversations.im> Реклама по Jabber / Advert on » Jabber » » [RU] Представляем новый сервис рекламы по Jabber! » Вы увидели это сообщение? Значит и десятки тысяч других пользователей » увидят ваше! » » Более 500 000 АКТИВНЫХ пользователей в базе: » - из открытых тем на форумах » - из дампов форумов всех тематик » » Собственное ПО для рассылки: » - обход капчи на стороне клиента и сервера » - поддержка OTR шифрования клиента и сервера » » Более детально здесь: http://gg.gg/m3a3u » » ---------------------------------------------------------- » » [EN] Introducing a new Jabber advertising service! » Did you see this message? This means that tens of thousands of other » users will see yours! » » More than 500,000 ACTIVE users in the database: » - from open topics on forums » - from forums' dumps » » Own software for mailing: » - bypass captcha on client and server side » - OTR client and server encryption support » » More details here: http://gg.gg/m3a3u »

You know

This same message is repeating every time

How resistant exactly is OTR to crypanalysis

very

Well

What about size

size?

you need to do a full OTR handshake before message contents are exchanged

If you have a known plaintext can you infer if the ciphertext is the plaintext by looking at the size of the packet?

for the handshake to succeed, you’d have to have key material which can recover the plaintext anyways

No i'm not talking about reading the message

but messages will not be sent before you could read them

The spammer send the EXACT same message every time

you cannot send (useful) OTR messages before the handshake is complete

I'm wondering if you looked at the SIZE of the OTR ciphertext, if it was very similar or the same each time this message is sent

for that you’d first need actual cipheretxt

to get actual ciphertext, the handshake must have succeeded

the "same" message you’re seeing is probably just the first message of the handshake

I've seen encrypted voice systems fall over because people could pretty accurately guess words by looking at the packet size of an encrypted compressed VoIP stream

(looking at your SiLK codec)

classic compression-before-encryption problem.

but that’s also completely unrelated to OTR