923 Dunlap st
Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard.
__Wε__Nεεd__Yσμr__Shiρmeηt__Infσrmatiσηs__
Click_Here
923 Dunlap st
Yeah, this particular message looks like classic spam (headers
available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ).
When the spam was getting through, I checked some of the headers and
most were coming from Gmail users. See, for example,
http://pastebin.com/hRAtRt7S. That particular message likely had its
spam score lowered because of the DKIM signing.
I was also contacted offlist for the spam I was sending. I saw the
headers on two of the messages, and they clearly were from me and
submitted through Google's web interface. They looked just like the
headers in http://pastebin.com/hRAtRt7S. I did not send them, and they
did not show up in my Outbox.
Its the reason I'm guessing Google services had a vulnerability that
was silently patched.
i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to recognized sandbox sites or -- much better -- to an openssl-operated one.
moreover, as i pointed out in a pm to Steve, this is a real security issue for openssl's list in that such a breach (if it is one) opens the names and email contact info of a broad range of security-responsible people that will invariably include some in the upper regions of the perm chain. these people are the very people that are targeted by malicious attempts (and some startling successes) to breach much more than an organization's email system.You are now going way outside anything discussed previously,
Posts by others indicate that the *spoofing* activity
yes, this person has seemingly stopped with postings, but i am hearing no assurance that they have even been eliminated from the subscription database. just being able to listen will garner a wealth of sensitive info obtainable re a most desirable crowd of people/victims.
even the most simplistic listserv app has the ability to withhold subscriber email addr's and still provide a secure pm capability. now that it is apparent|perceived that the list is vulnerable, i believe the prudent route to go is to keep those addr's and subscriber real-world names out of the "limelight". i see no reason why a sanitized subscriber profile available from a link within the person's public handle would not be adequate for identification purposes and would actually become an enhancement to the listserv app's usefulness to subscribers. this would certainly shield the subscriber in a reliably meaningful way, serve to protect a subscriber's own email system, and enhance the security of openssl's own listserv ops.The issue that the FROM addresses of OpenSSL e-mail list posters
original anchor description (100% of the message content): Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard. __Wε__Nεεd__Yσμr__ShiÏ meηt__Infσrmatiσηs__ Click_Here
On 2016.Apr.04 09:08, Jeffrey Walton wrote:
And anyway, this seems to be a case where the genuine operator of an e-mail domain is failing to correctly authenticate submissions by their own users, which no amount of 3rd party automation (other than blacklisting the failing provider, in this case gmail) could stop.Yeah, I'm guessing there was a vulnerability in one of the other Google services, and that Google service was allowed to make web-based email submissions on behalf of the user. Classic injection and failure to validate sessions or parameters... I'm also guessing Google fixed it because it has stopped.
Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Not in this thread on openssl-users as far as I can tell.
> '/maybe the spoofed From address happened to be a subscriber/'
> is it possible that openssl still does not know if the email addr is a
> real subscriber?
>
I have no way of knowing since I am not one of the list admins.
> '/maybe there is a bug in the list management software or configuration/'
> yes, i surely hope someone is looking into this possibility.
>
> further, not only was owenevans98 able to post an original message (the
> subject of this thread), but there was a subsequent posting in reply to
> another thread. thus, the conclusion that owenevans98 was not only able
> to post but was|is receiving the listserv mailings is self-evident. the
> fact that this two-way comm path came into existence means that the
> listserv database was corrupted and that the original posting was not
> some slip-up in permitting an un-authorized one-time posting.
Which other thread was that?
>
> jakob, i appreciate your taking of the time to detail some of openssl's
> listserv practices and view-points. perhaps it is best to set forth the
> synopses of my views:
I am not a list admin or other official team member, I am just an
active list member who wants to avoid the list admins following bad
advice from people like you and Ben Humpert.
>
> 1. make certain ' owenevans98' and any other illegitimate posters are
> not receiving listserv mailings;
Question is if owenevans97 is an illegitimate poster or a legitimate
poster whose e-mail address was spoofed.
Anyway, the OpenSSL mailings are all being indexed on the world wide
web by multiple organizations, where anyone can read them.
> 2. stop publishing the subscriber's protected PII in the clear; and
Again, I see no sign this is happening other than the age-old inclusion
of original from and reply addresses in postings (which is limited to
those who post, and doesn't affect those who only subscribe).
> 3. control postings of anchors.
>
I disagree. A number of e-mail clients (MUAs) automatically turn
textual URLs into anchors and make it very difficult (if not
impossible) for the posting user to avoid this. And people
professional enough to understand most of the stuff on OpenSSL mailing
list also know not to click on links in strange e-mails and forum posts.
> according to your comment quoted, supra, it seems that the step
> indicated in Item 1 has yet to be taken.
I wouldn't know.
>
> Item 2 can be implemented by inaugurating a subscriber-managed profile
> and merely publishing a user handle linked thereto. thus, you can shift
> the onus to the subscriber to reveal whatever info they wish rather than
> arbitrarily exposing to the world a subscriber's personal name, email
> addr, and work-force association.
Did you read and understand any of that which I wrote, or
are you just trolling?
>
> in the case of Item 3, i understand all of the reasons for having links
> (not html anchors) in postings. it is a very minor inconvenience for
> someone who has a burning interest in viewing a link to copy the
> clear-text link into a browser versus clicking on an anchor description
> which could lead the subscriber far astray from what the description
> says. it also enhances the subscriber experience to visually see where
> the link is going instead of having the actual target obscured by a
> description that may be deceptive, merely misleading, or non-apparent
> (i.e., 'click here').
>
> jakob, you also mention concern re MTA operators having some issues with
> changes you may make to the listserv ops. please note: none of the three
> (3) items, supra, i have suggested have any impact on other MTA
> operators as they are totally internal-control enhancement proc's.
I am an MTA operator, I am not a listserv op. I was posting concerns I
have as an MTA operator and list member with stupid changes suggested
by you and Ben Humpert.
>
> i cannot understand why openssl's filtering missed the fact that the
> posting that is subject of this thread predominated in symbols and
> control characters, contained no actual message text, and still went
> through. hopefully, someone is also looking into why this happened.
>
Did you read the brief but very clear message posted on 2016-04-02
15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
access to the listserv configuration details not published to avoid
helping spammers)?
P.S.
Please don't CC list members on replies to the list, it causes
duplicate copies to reach them (since list membership is required to
post to the list anyway).
>
> On 2016.Apr.04 15:36, Jakob Bohm wrote:
>> On 04/04/2016 22:28, Johann v. Preußen wrote:
>>> i am not certain i understand how it is google's fault that this
>>> owenevans98|Dawn was able to slip into the listserv database. this
>>> is, of course, assuming that this was not done via a simple sign-up.
>>> i also do not understand how prohibiting a posting (content, infra)
>>> that obfuscates a message within a host of symbols with a net zero
>>> percent of prose and 100% anchor description is responding to some
>>> sort of a "fad". this list is re problems and solutions that can only
>>> be conveyed in prose ... no prose == no message. and permitting
>>> private anchors is also a questionable security practice. it does not
>>> seem unreasonable to require anchors to be to _recognized_ sandbox
>>> *original anchor description (100% of the message content):*
>>> Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard.
>>>
>>> __Wε__Nεεd__Yσμr__ShiÏ meηt__Infσrmatiσηs__
>>>
>>> Click_Here
>>>
>>> On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>>>>> And anyway, this seems to be a case where the genuine
>>>>> operator of an e-mail domain is failing to correctly
>>>>> authenticate submissions by their own users, which no
>>>>> amount of 3rd party automation (other than blacklisting
>>>>> the failing provider, in this case gmail) could stop.
>>>> Yeah, I'm guessing there was a vulnerability in one of the other
>>>> Google services, and that Google service was allowed to make web-based
>>>> email submissions on behalf of the user. Classic injection and failure
>>>> to validate sessions or parameters...
>>>>
>>>> I'm also guessing Google fixed it because it has stopped.
>>
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Take it up with the list admins directly?