An ancient twice-infested OS/2'er has cometh.

As passed down via the virus news, if what it says is correct, the new Bugbear.A virus could be a problem to OS/2 users based on bitter experience here in the past.

Per what I have read, it is a reportedly well written Visual C creation which uses NETBIOS over TCP/IP in a cascaded Port 137 and Port 139 TCP romp to infect
boxes connected to an IP. It is looking for GUEST accounts with no password or
ADMIN rights with no password, both focused on the WIN world earlier mass installations of NETBIOS in penetratable fashion.

NETBIOS was written specifically to make machines talk files with other machines over the LAN, as best this pure novice at all this understands it. That means that if the boxen know NETBIOS standards, it doesn't make any difference what operating system is involved .... ;)

Per my VERY well documented two runs I took when NIMDA.A first appeared with a variation on this scenario, an OS/2 box connected in an unprotected way to the IP world ... *CAN* ... be penetrated. It is possible to at least download files to the remote OS/2 box. The earlier attacks were able to place at least one or more files in each and every directory on the hard disk partition found here .. hundreds of READ.ME and other contaminated files appeared here when this erupted. The infector box in this case was a neighboring box on the COX cable modem network here.

The current new virus variation is reportedly also using the Port 137/138 and thence TCP use of Port 139 to pentetrate boxen with a GUEST account with no password or other way of ADMIN use of boxes with such permissions with no password protection. That's the default, as I think I learned, for most of the
early WIN world. Apparently the creator wants to prove that most WIN boxen are
still un-fixed and un-protected for safe hex.

Our OS/2 world also has that possibility in the standard installations for boxen with GUEST user accounts in that there is no default password installed for them either. Based on the research for the two earlier runs which infected
my box twice with tons of files, I have some question about the GUEST and no password in that GUEST in this case *WAS* passworded... However, I wasn't informed enough and waiting with the IP trace tools to catch the first penetration traffic so we could study that claim. Nor do I care to be a honey pot bee for this either with all else I've got to do.

If what I read is correct, this new one raises another very well able to pentrate your box deal, if you have NETBIOS over TCP/IP intalled on your connected machine. It is especially important, one would think, if you have left a GUEST account in there with no password. That's the default for at least PEER installation in OS/2.

I've since, somewhat wiser, I hope, gone to a better command over what Port 137/138 and Port 139 can do on my connected boxen, regardless of what GUEST(s) are or are not allowed in my OS/2 hotel.

Those of you who haven't thought about this may ought to. Sure, the installed junk can't run on OS/2 at this point. But cleaning up the mess it leaves does
take a virus help utility. I ASSURE you, twice my NORMAN which has been here in use all this time got a real workout.

Since upgrading to NORMAN 5.2(Now 10), I suspect it would have caught this on-line, but I ain't seen no evidence of that behind the new XyXel I installed ahead of everything as well .. after the first rounds.

Samuel Taylor (perhaps on Laudenum, grin) said it best?

"A sadder but a wiser man he woke the morrow morn."

Both my two earlier experiences with NIMDA.A came while the below was very much
happening.. with NETBIOS over TCP/IP...

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hi Mike,

Replying to a message of Mike Luther to All:

Per what I have read, it is a reportedly well written Visual C
creation which uses NETBIOS over TCP/IP in a cascaded Port 137 and
Port 139 TCP romp to infect boxes connected to an IP.

The report I read about Bugbear was on the BBC's Web site:

http://news.bbc.co.uk/1/hi/technology/2290153.stm

According to that report, the virus requires M$ Lookout (or a user who is as brain-dead as Lookout) to be activated, as it is transported as a mail attachment. The mail message is the Trojan, I suppose. The size of the executable attachment is always 50,688 bytes. [A "virus" the size of an elephant!]

Unless you are running Lookout, there should be no real threat to an OS/2 box. [Assuming the BBC is correct.]

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Yes Dave..

According to that report, the virus requires M$ Lookout (or a user who
is as brain-dead as Lookout) to be activated, as it is
transported as a mail attachment. The mail message is
the Trojan, I suppose. The size of the executable
attachment is always 50,688 bytes. [A "virus" the size
of an elephant!]

Unless you are running Lookout, there should be no
real threat to an OS/2 box. [Assuming the BBC is
correct.]

I understand that the virus cannot be ACTIVATED. What I also saw with this same port 137 and 139 port ramp up with NIMDA.A here is different, in a way. The inbound probes to look for a penetratable box on the port 137/139 sequence *CAN* result in dropping file onto the OS/2 box from afar *IF* the NETBIOS over
OS/2 protocol is installed on the system and *IF* the initial probe is able to establish how to write to a shared resource on it.

I absolutely agree that the virus cannot, as we understand it is recorded to operate, execute on the OS/2 box at all.

The point is that NIMDA.A, a similar sort of approach, before the entire attack
profile of the creation was propagated, *WAS* able to download READ.ME and so on actually into the OS/2 box into various directories.

The fact that it is transported as a mail attachment isn't all of the story as in the above. George Vandervort's Fido post for his protective vendor outlined
more of the story than is noted by either you or Peter. It was the one which made the comparison on the Port 137/139 Netbios access method and the previous NIMDA.A use of the same techniques.

In that I've personally seen that approach compromise an OS/2 only box to the extent that it loaded the required files remotely onto it not once but twice, I
posted the original message.

I've further seen this same approach here, when the penetration attempt also adds JAVA to the messaging mechanism, actually start a message window in an attempt on an OS/2 box to execute the Trojan. But of course, the Trojan won't run in OS/2. The way the loaded message deal works is that the screen placement for the pure white 'empty' box for that message is made very tiny in size. In this case, it was deliberately skewed down to the very lower right corner of my OS/2 desktop. Only the tiny upper left hand corner of the bogus message opening JAVA attempt could be seen, the little close me box button you usually see to close the window. It simply got stuck there,in that it couldn't
execute the payload. But it was able to TRY to do so,even in OS/2.

If you will think a little bit about the possibility of being able to even just
upload a file to any OS/2 box, it ought to give you pause to ponder. At that point any executable which will execute in DOS can be a problem, or any in OS/2, or any FAMILY mode program as well. OS/2 is not at all free of potential problems under this approach.

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Mike Luther saw fit to emit the following to David Noon
on 10-03-02 23:40 about Bugbear.A virus notes...

Yes Dave..

According to that report, the virus requires M$ Lookout (or a user who
is as brain-dead as Lookout) to be activated, as it is
transported as a mail attachment. The mail message is
the Trojan, I suppose. The size of the executable
attachment is always 50,688 bytes. [A "virus" the size
of an elephant!]

Unless you are running Lookout, there should be no
real threat to an OS/2 box. [Assuming the BBC is
correct.]

[snip]

The point is that NIMDA.A, a similar sort of approach, before the
entire attack profile of the creation was propagated, *WAS* able to download READ.ME and so on actually into the OS/2 box into various directories.

[snip]

The GUEST account has no access to any shares in OS/2 unless you explicitly grant it access. In other words, there's no vulnerability unless you take specific actions to create one.

Mike Ruskai
thanny@netcarrier.com


... Humor is the ability to laugh at ourselves.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: FidoTel & QWK on the Web! www.fidotel.com (1:275/311)

But in this case, Mike ..

The GUEST account has no access to any shares in OS/2
unless you explicitly
grant it access. In other words, there's no
vulnerability unless you take
specific actions to create one.

I used GUEST ... with a password. It was used for planned access, but passworded. In theory, it shouldn't have been compromiseable but somehow was.
I only got two passes at this to research. The first one was complete surprise. The second one I missed just the very start of the attack with the trace, so we didn't learn exactly what the first few packets were like,

It would have been nice to know exactly where the hole was. But with time so fleeting and no spare equipment to set up a 'pot', I opted to just get rid of Netbios over TCP/IP that wasn't needed on the box at that point.

If you have any theory on how this might have taken place passworded, I'd like to know your thoughts. Several others spent a good period of research time looking at the packet trace and so on. Far more informed that I'll ever be at networking. They came away puzzled as well in that there appeared to be no PW crack run or whatever associated with the incidents.

One other part of the puzzle might be useful. In this case the passworded GUEST account had been used prior to the attack(s). I'm not sure about what the status of the connection being active at these starting point, whether the share was actually in use or not.

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Mike Luther saw fit to emit the following to Mike Ruskai
on 10-14-02 08:42 about Bugbear.A virus notes...

But in this case, Mike ..

The GUEST account has no access to any shares in OS/2
unless you explicitly
grant it access. In other words, there's no
vulnerability unless you take
specific actions to create one.

I used GUEST ... with a password. It was used for planned access, but passworded. In theory, it shouldn't have been compromiseable but
somehow was. I only got two passes at this to research. The first one was complete surprise. The second one I missed just the very start of
the attack with the trace, so we didn't learn exactly what the first
few packets were like,
It would have been nice to know exactly where the hole was. But with
time so fleeting and no spare equipment to set up a 'pot', I opted to
just get rid of Netbios over TCP/IP that wasn't needed on the box at
that point.
If you have any theory on how this might have taken place passworded,
I'd like to know your thoughts. Several others spent a good period of research time looking at the packet trace and so on. Far more informed that I'll ever be at networking. They came away puzzled as well in
that there appeared to be no PW crack run or whatever associated with
the incidents.
One other part of the puzzle might be useful. In this case the
passworded GUEST account had been used prior to the attack(s). I'm not sure about what the status of the connection being active at these starting point, whether the share was actually in use or not.

All I can think of, without knowing the details, is that you left the
password as optional (which is the default for the user GUEST).

Overall, I'd say GUEST should remain a no-password account, and given
rights appropriate for that lack of security.

If you want a password-protected user account, create one.

Mike Ruskai
thanny@netcarrier.com


... A cat will always sit on whatever it is you're trying to read or copy.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: FidoTel & QWK on the Web! www.fidotel.com (1:275/311)

*** Quoting Mike Ruskai to Mike Luther dated 10-14-02 ***

All I can think of, without knowing the details, is that you left the password as optional (which is the default for the user GUEST).

Mike,

How would you change the password to required??
I would have thought even if it was optional -and- a valid password was entered
then trying to logon with a blank password should fail.

Rich
I-Net turtil@frontiernet.net


... **FLASH** Energizer bunny arrested, charged with battery
---
* Origin: Turtil's Pond BBS. Monroe NY 845-783-2106 (1:2624/50)

Rich Wonneberger saw fit to emit the following to Mike Ruskai
on 10-15-02 20:12 about Bugbear.A virus notes...

*** Quoting Mike Ruskai to Mike Luther dated 10-14-02 ***

All I can think of, without knowing the details, is that you left the password as optional (which is the default for the user GUEST).

Mike,

How would you change the password to required??
I would have thought even if it was optional -and- a valid password
was entered then trying to logon with a blank password should fail.

The user management screen has a set of radio buttons for making the
password optional or required. It defaults to optional for the GUEST
account. It defaults to required for all new accounts.

I'm not sure if there are any command-line use management programs

Basically, one should leave the GUEST account as is, and create new ones
for password-protected access to resources.

Mike Ruskai
thanny@netcarrier.com


... I AM serious. And stop calling me Shirley.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: FidoTel & QWK on the Web! www.fidotel.com (1:275/311)

Mike ..

The user management screen has a set of radio buttons for making the password optional or required. It defaults to optional for the GUEST account. It defaults to required for all new accounts.

I'm not sure if there are any command-line use management programs

Basically, one should leave the GUEST account as is, and create new ones for password-protected access to resources.

There is such a button combination, including the 'expire password' check box in the Shared Resources setup folder. However in this case, when the two attacks managed to get in, this was firmly set so the the GUEST required a password. It was not optional at all.

And in this case it only had USER rights checked.

I haven't got my notes in front of me, but from reading the Usegroups, I know that there is a utility tool for command line use which will, I think I recall it right, create a new user with ADMIN rights from the get go at command prompt
level. Further I think I recall that you can also copy over the NET.ACC account from the install directory into the appropriate place in the operations
game. That will restore the standard OPERATOR - PASSWORD and GUEST with no password game to get you back in if you can't remember this and that.

But doing this on a bust in Port 136/7 - 139 romp? If that happened, my customized access profiles would then be gone too and they hadn't changed at all in re what had been set, despite the escapades. No new goodes shown there at all from what was there earlier. Nor did the LAN register anyone logged in when it was happening ...

As we noted in the discussion, OS/2 doesn't have any three strikes and you are out or such password pranging block. You can mash on it en mass trying to break in. And, in both cases, I wasn't around when it started. But if there wasn't anyone logged in when it was happeing in the logout, yet it was happening, something had to be grossly wrong. And we never found out what it was that was bad.

As I think I recall all the discourse that went on at the time, NIMDA.A was seeking the use of boxes with NETBIOS over TCP/IP which had a GUEST account with no password, or an ADMIN account with no password, or a box on which the pest could establish adminitrative rights and create shares on the fly via this
or that attack mode for what it wanted.

I even thought about the possibility that even though you might have had a GUEST with no password, and created shared resources for it with read/write capability, you could have then gotten rid of GUEST in LAN/UPM. But you might have still left GUEST defined in the shared resources folder and so on I think you are citing here. I can vizualize how that might get you into hot water with NB over TCP/IP and far places. However that wasn't the case here either and the install admin plus password was gone too.

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)