Subject: RE: OCP message rendering

From: "Martin Stecher" <[email-masked]>
Date: Wed, 8 Oct 2003 10:59:52 +0200

> 
> I got tired from counting characters and trying to preserve correct
> spacing when typing OCP examples. Since OCP message format is strict
> and well documented for machine use, I think it is wrong for us,
> humans, to suffer from machine-level optimizations when 
> typesetting OCP
> examples irrelevant to those optimizations.
> 
> ...

I do not agree here.
People try how examples work. We will have prototype implementations that
just replay the examples from the draft and people wonder that they fail,
even more if the debugging output of a working other solution shows the
same output.
OCP is not a binary format and as being text it is easy to copy sample
messages and paste them in a telnet client, playing around with these
examples.
So, I am a strong supporter of having working examples somewhere.
And one of the best places for me is the official draft or RFC.

Line breaks are an exception, they are essential for rendering purposes,
some of those need to be removed to get working samples. An alternative
here could be to print a special character that marks those soft breaks
for rendering purposes.
That's why I'd welcome a Message Rendering Section that explains this.

I can review the examples in the draft and help to ensure correct character
counts and spaces.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 8 Oct 2003 10:46:58 -0600 (MDT)

Martin,

	I will reverse the changes and document line breaks exceptions
in the message rendering section.

	I am not sure whether it is a good idea to add a special "soft
break" character (e.g., '\' to follow C and Unix shell convention).
Using your own arguments, people may try to use those "soft break"
characters in real world and complain that they do not work.

	Anybody thinks it is a good idea to add '\' for rendering
purposes only?

	One solution would be to make SP and CRLF interchangeable, but
that complicates parsing. MIME has something like that (implied LWS
rule), but virtually no HTTP agent we tested supported it correctly!

	Finally, what do you think about indentation?  Can we still
use it for rendering purposes? Please? :-)

	{
		n1: v1
		n2: {
			n21: v21
			n22: v22
		}
	}

looks/reads much better than

	{
	n1: v1
	n2: {
	n21: v21
	n22: v22
	}
	}

Comments/opinions?

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Sat, 11 Oct 2003 19:22:32 +0200

I am sure OCP could help this guy a lot.
[for information only]

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

URL
<http://www.lurhq.com/migmaf.html>http://www.lurhq.com/migmaf.html

Release Date
July 11, 2003

In late June 2003, spam-fighters from the news.admin.net-abuse.email Usenet 
group noticed a particular spammer seemed to be able to move his websites 
around at will, minute-by-minute. This activity was also pointed out in an 
article by Richard M. Smith of 
<http://www.computerbytesman.com/>computerbytesman.com.

It appeared at first that the spammer had managed to infect thousands of 
systems with a small webserver trojan - rotating them in and out of the DNS 
for the domain names he owned every 10 minutes. It made it nearly 
impossible for ISPs to track and shut down, as the IP addresses were 
largely owned by dialup users, so ISPs would be fighting a constant battle 
to keep track of all the reports.

The sites being advertised in the emails were generally Russian porn sites, 
and Richard Smith pointed out the same servers were involved in a Paypal 
scam email he had seen.

LURHQ was able to obtain a copy of the trojan - detected from suspicious 
activity originating from a VPN user on a firewall on a network we monitor. 
What we found was the trojan was not a webserver at all, but instead: a 
reverse proxy server. Instead of hosting the content on the victim's 
computer, the spammer instead maintained a "master" webserver. We have 
dubbed this trojan "Migmaf".

Functionality of Migmaf
Someone requesting the URL core.onlycoredomains.com (among several others) 
would be directed to one of the trojaned machines, where the connection 
would be in turn relayed to the master webserver. The returned page would 
be passed back to the trojaned machine, where it was then sent back to the 
requesting user's web browser. In this way it is impossible for the user to 
tell the actual IP address of the master server - giving the spammer's real 
site refuge from being shut down by his ISP.

But that isn't the only service Migmaf offers to the spammer - it also 
listens on TCP port 81 and acts as a socks proxy server. This allows the 
spammer to bounce spam email through the trojaned machine to his target 
recipients. This means the spammer has a complete end-to-end anonymous 
system for spam, and it lends itself well to the kind of scams already 
being seen. In one scam, the spammer directs the user to enter Paypal 
information into a form on the spammer's server. Posters to the Usenet 
spam-fighting groups have also speculated that the porn sites being 
advertised by the spammer may be merely a front to steal credit card numbers.

Migmaf has some features designed to make efficient use of resources. The 
trojan reports statistics and current state information back to the master 
webserver. The trojan actually checks to see how much available bandwidth 
it has by sending several hundred kilobytes of garbage data to 
www.microsoft.com on port 80. Because this might look like a 
denial-of-service attack or an exploit attempt, the trojan code actually 
contains the following text:
"disclaimer: www.microsoft.com used for bandwith speed testing only"
The copy of Migmaf we obtained was compiled at the following time:
Tue Jul  8 13:33:57 2003
Since the trojan has obviously been around longer than that, we can safely 
assume that the author is constantly changing the code he is sending out to 
evade anti-virus detection or to perhaps direct the traffic to another 
master webserver.

Migmaf itself has no spreading capability, so we don't yet know how the 
spammer is spreading the trojan to thousands of users. It could be 
piggybacked on a virus, or could perhaps use the IE exploit the 
<file://winupdate.html>Windows-Update trojan used, or it could be spread 
via IRC or KaZaA. One interesting thing to note is the large percentage of 
AOL users that seem to be infected - this may indicate a chat or 
instant-message method of transfer. The filename of the trojan, 
"wingate.exe" has been used by the Lovgate worm, but it does not appear to 
be the same file, and thus is not believed to be related to Lovgate.

Migmaf tries to conceal the IP address of the master server by use of a 
"combination lock" algorithm. Basically it chooses each octet of the 
address to report back to by cycling through three choices per octet. So, 
the total possible combinations are 3x3x3x3 or 81. One time out of those 81 
tries it will hit the correct address. The other 80 times it will try to 
connect to other combinations, thus if you are just looking at the traffic 
for a short time, you won't know which address is the real.

In determining the origin of Migmaf, consider this: Before it does anything 
else, Migmaf checks the value of the following registry key:
Keyboard Layout\Preload
If it determines the keyboard layout indicates a Russian keyboard, it will 
exit. This suggests the authors are based in Russia, but it could be 
misdirection. Either way, the trojan will not work on Windows computers 
with a Russian keyboard.
Removal
Remove the following registry key:

Software\Microsoft\Windows\CurrentVersion\Run\Login Service = wingate.exe

Reboot the computer and remove the following file:

%windir%\system32\wingate.exe

About LURHQ Corporation
LURHQ Corporation is the trusted provider of Managed Security Services. 
Founded in 1996, LURHQ has built a strong business protecting the critical 
information assets of more than 400 customers by offering managed intrusion 
prevention and protection services. LURHQ's 24X7 Incident Handling 
capabilities enable customers to enhance their security posture while 
reducing the costs of managing their security environments. LURHQ's OPEN 
Service Delivery&trade; methodology facilitates a true partnership with 
customers by providing a real time view of the organization's security 
status via the Sherlock Enterprise Security Portal. For more information 
visit <file://index.html>http://www.lurhq.com

Copyright (c) 2003 LURHQ Corporation Permission is hereby granted for the 
redistribution of this document electronically. It is not to be altered or 
edited in any way without the express written consent of LURHQ Corporation. 
If you wish to reprint the whole or any part of this document in any other 
medium excluding electronic media, please e-mail 
<mailto:[email-masked]>[email-masked] for permission.

Disclaimer
The information within this paper may change without notice. Use of this 
information constitutes acceptance for use in an AS IS condition. There are 
NO warranties implied or otherwise with regard to this information. In no 
event shall the author be liable for any damages whatsoever arising out of 
or in connection with the use or spread of this information.

Feedback
Updates and/or comments to:
LURHQ Corporation
<file://index.html>http://www.lurhq.com/
<mailto:[email-masked]>[email-masked]

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 13 Oct 2003 18:49:13 -0600 (MDT)

On Sat, 11 Oct 2003, jfcm wrote:

> http://www.lurhq.com/migmaf.html

Could you please clarify in what way the OCP protocol would be helpful
in this context?

It seems that the reverse proxy is a better tool for his/her purpose
because there is no exchange or adaptation of non-HTTP messages? It
looks to me that the key functionality here is URL rewriting which is
what reverse proxies are good for.

Are you implying that the trojan in question could have been more
powerful and could easily "adapt" more protocols if it were using OCP?

Thanks,

Alex.