lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20050210014736.GL1938@feynman>
Date: Wed, 9 Feb 2005 18:47:36 -0700
From: Neal McBurnett <neal@....boulder.co.us>
To: bugtraq@...urityfocus.com
Subject: secure-roster script to address mailman email harvester


For the unfortunate mailman list administrators out there that were
caught unprepared by this hastily-released vulnerability posting....

You probably want to go to the "Privacy Options" configuration page
and change the "private_roster" config setting to "list admin only".

You really want to do that if it is set to "anyone" now.  If it is set
to "list members", that may be ok if the list is set up to require
approval for new subscribers.

I'm no mailman or python guru, but here is a quick hack that helped us
identify lists that fit these characteristics, and can optionally
automatically change them from the command line on the mailman host.
Your mileage may vary....

Cheers.

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Example usage:

 cd /usr/local/mailman/lists
 for i in *; do
   /usr/local/mailman/bin/config_list -i $HOME/secure-roster $i
 done

---- secure-roster ----

# this script attempts to help address lists that are vulnerable to
#  harvesting of subscriber email addresses by spamers.  See
#  vulnerability noted on bugtraq: "mailman email harvester"
#  Neal McBurnett http://bcn.boulder.co.us/~neal/

# Usage: mailman/bin/config_list -i secure-roster mailinglist
# This will just tell you what needs to change.

# If you want to actually change the lists, uncomment the lines
# below which assign to the global variable "private_roster"

# Note that the config_list program looks for global variables
# after this executes, and if it finds them, and they match
# an mlist variable, it assigns them and saves the new config.

# if roster is available to everyone
if mlist.private_roster == 0:
 print mlist.real_name, "- you really should change private_roster to 2"
 #private_roster = 2

# if subscriptions do not require approval 
if mlist.subscribe_policy < 2:
 # if roster is available to subscribers
 if mlist.private_roster == 1:
  print mlist.real_name, "- you should change private_roster to 2"
  #private_roster = 2

----

On Mon, Feb 07, 2005 at 11:48:44PM +0100, Bernhard Kuemel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi!
> 
> Tons of email addresses from mailman mailing lists are vulnerable to
> be collected by spammers.
> 
> They are "protected" by obfuscation (user@...mple.com -> user at
> example.com) and access to the subscriber list can be restricted to
> subscribers. The obfuscation is trivially reversed and harvester
> scripts can subscribe to gain access to restricted lists.
> 
> I suggested a graphical turing test that would bar scripts but the
> mailman developers argued spammers might hire a couple of temps that
> would solve the test as it already happened for the creation of
> email accounts. The only solution would be not to have the desired
> information available. This is already an option by restricting
> access to the member list to the list administrator.
> 
> However, still many lists either have the member list openly
> published, or available to the list members. To raise awareness to
> this issue I wrote a script that collects addresses from openly
> accessible lists. It stops after processing 1000 (the maximum
> allowed) search results from google and collects 76772 email
> addresses (61124 unique). It is attached as mmxp1.
> 
> An improved version that collects addresses that are restricted to
> subscribers, processes more lists and works more parallelized is
> planned.
> 
> Bye, Bernhard


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ