PC AUDIT

Hi FanJ

1. I don't use FileChangeAlarm or something of the kind but I think it would not prevent the leak as PC Audit does not modify anything.

2. I did not disassembled PC Audit, so I cannot say how it works exactely but it does not modify a*dll : it works like a launcher, trying to start different applications having a valid access to the W3.

Rgds,

JacK

 

OK, Thanks JacK

Cheers, Jan.

 

I'm sort of jumping into this in mid-stream, so I may have overlooked something previously said, however, . . . .

Actually, Paul, at one time AV software did run checksums -- specifically Central Point Anti-Virus (a part of Central Point's PC Tools for Windows for Win 3x) included CRC-32 checksumming. If the Checksum, the file date (I forget which one), or the file size changed, CPAV would alert the user. In other words, they relied on considerably more than just a virus signature or heuristics. Indeed, I believe KAV Inspector still does this.

So, it's certainly doable and in fact has been done. Unfortunately, that's of little solace in the context of this vulnerability demonstrator. As you note, this is not (as far as I can tell) a virus-like application, it doesn't modify any existing files; it appears to simply hook into anything with an internet connection. I haven't had the time to download and run PC Audit, but I suspect it dynamically links at runtime. If I'm correct, then something like Dependency Walker wouldn't pick this up (HandleEx would, however).

Furthermore, one would need a massive database of checksums, dates, file sizes, etc., to authenticate such a file. We ain't got this in Windows environments (and I doubt we'll get it either).

Using something like NIS File Check (regularly, very regularly) could alert one to having a new file on their box. But that still begs the question of what you're going to do about it.

There's an even more exotic exploit possible. This was first discussed (publicly) by someone publishing as EmilioG in the old GRC newsgroups some time back (apparently not the same EmilioG as is now sometimes seen on the DSLR forums). This was also referred to as DLL injection, but involved injection into the work space of an authentic DLL in RAM. Well, dear hearts, file authentication ain't gonna do you much good in this case! The legitimate DLL on disk would remain unchanged; only the DLL in RAM would be changed. And, in essence, this is what CRv1 did. Indeed, in CRv1, there wasn't any file on disk to authenticate -- sucker went straight into RAM.

I could ramble on for a while on this subject, but it would probably be best if I start at the beginning and read through the thread in its entirety first.

 

Hi Joseph,

I would like to thank you so much for your posting !!!

Thanks, Jan.

 

Mickey,
I just got here and this query goes all the way back to the very beginnings of the thread where you said:

Again, I haven't had the time to check this out yet, but if this is a crucial component of the vulnerability being demonstrated, it would seem that AtGuard, NIS, and NPF(?) have a capability to block this exploit.
From the relevant Help page in NIS 3.0x:

So, would that solve the problem with PC Audit?

 

Hi Joseph,

Somewhere in the thread I posted that I was able to keep my UA "hided" at the privacy net test, after changing a setting.
The change that I made, was exactly the one you are referring to: the one in my NIS1.0 to block User Agent.

BTW: until now I have not checked the PC Audit test myself.
I guess that the fact that I'm able to block my UA, doesn't have to mean that I am not vulnerable in general to the kind of exploits that PC Audit tries to point at.

 

Pete,
Going all the way back to your posting on or about 7:37 AM on 5 August:

Ah, yessss, . . . the registry hack! Interesting story about that. Goes back to when MS decided to shut off support to guys still running Win 3X (now why would they want to do that, I wonder? ) Well, they did at any rate. Unfortunately, there were others then running Win 95 or Win 98 and they noticed that the web pages were still present; it was just that guys running Win 3X couldn't reach 'em. Puzzling that. . . . Turned out that MS was deliberately blocking users trying to access the pages, but still using Win 3x. Simple solution: Change the User-Agent information to indicate the user was using Win 9X -- problem solved! (I believe that, at one point, MS did something similar to keep people using Netscape from being able to access web pages on the MS website.)

Well, that was sort of an interesting anecdote: The more important point is that this information is stored somewhere in the registry -- and PCAUDIT apparently uses a DLL to do what it does. Consequently, there's a possibility that simply blocking User-Agent in AG/NIS/NPF won't make much difference (I think that only applies to the header field sent by the browser itself.) The DLL can simply extract the information from the registry. At that point, it could

• start up the browser indicated in the registry (which is almost invariably going to be in its default location) and PERMITted Internet Access and then pass its message to the PCAUDIT site or
• using any Internet-enabled application it chooses -- presumably as long as such an application doesn't allow fine-tuning of what destination port/IP addresses are being accessed--do precisely the same thing.

Now, that would be a PITA. (But it does also indicate the scope of what such an exploit could do rather well.)

 

OK,

I did the test.
I was running the very strange setting with NIS1.0 and ZAF 2.6.362 running in tandem while doing the test.
UA was blocked in NIS1.0.
ZA asked me three times whether an app was allowed to outbound access, I said no.
I succeeded in the test:
"Your computer is well protected.
To uninstall pcAudit you must re-start your computer".

I'm going to run ADinf32 Pro now to see whether indeed there is no strange file left on the system; and some other scanners

 

Snowman, from your posting of 5:49 PM on 5 August:

Well, not exactly . . . . the devil is in the details, you see. First, when you 'authenticate' a DLL (or an OCX or a VXD or a SYS or a ...), you're actually authenticating the file image as it exists on disk. Specifically, you're not authenticating the file image as it exists in RAM. (Nor are you going to, I might add, because that image changes constantly as in-RAM data space is used -- those pesky buffer overflows and all that.) So, there are two obvious ways for that download from PCAUDIT to accomplish this:

• It can 'inject' itself into the RAM-resident image of the DLL (or whatever), presumably in some of the data buffer space, or
• it can simply dynamically link to one of the DLLs used by Internet-enabled applications.

Neither of these alternatives would have any noticeable impact when you run file authentication utilities (real-time or non-real-time).

So, ahhh, . . . . just how many of these 'common' DLLs are there? Well, over in microsoft.public.security, you'll see an interchange between 'tack' and me in which something on the order of 14 DLLs common to both MSIE and Opera are identified. And most of these DLLs will be called by just about any Internet-enabled application. Infect or dynamically link to any of these (only in RAM, for that matter) and game over.

In other words, this isn't the mechanism that appears to be being used by PCAUDIT (well, it certainly doesn't need to be the mechanism in use).

 

I agree completely. Like most exploit demonstrators, PCAUDIT does something benign; but its ramifications are far more complex.

Heheheh!!! You musta missed gwion's distress when he found that the last exploit demonstrator revealed a hole in TPF/KPF (I forget exactly which one) that relied on precisely that mechanism!

 

Excellent double negative. (Careful or we'll make an Englishman out of you yet.)

You are correct. A lot of people missed the point with Gibson's initial Leaktest. They got carried away with blocking the specific implementation. The point, of course, was that it represented an entire category of potential vulnerabilities (especially in Win 9X or Win ME boxes). Similarly, the technique invoked by PC Audit could be used to do just about anything it might desire. Indeed, it would be much more dangerous than the currently popular versions of RATs and keyloggers.

 

Out of curiosity, I wonder if there's a way to feed your browser a false (and falsified) copy of the registry?

Hmm...

 

Out of curiosity, what were the apps that ZA queried about? Is it like Paul said -- it simply started cycling through Internet-enabled applications?

 

Out of curiosity, do great minds start sentences alike?

 

Well, errr, no ... great minds don't.

 

Hello,

Did you run the test with IE open ?

If IE was not open, it's normal your succeed the test if Explorer is not allowed to access the W3.

Regards,

JacK

 

Thanks, thanks JacK !!!

Did the test again, I failed.

Stupid, stupid me; aaargggghh; back to where I belong........


My apologies to all of you!
Sorry, Jan.

 

Joe

as always it was a pleasure reading your very enlightening post. the following is presented as questions:

this "exploit" appears to use the VxD service hooking to insert itself into the call chain of the #'s registry functions in the win95 kernel (virtual machine manager) please correct if I am in-correct here...
first: can virtual machine manager be disabled ?(I am alittle confused in understanding between "virtual machine" and "virtual machine Manager) Second: if it can...how would that effect the os? Third: would that prevent such exploits
Joe in our last discussion we somewhat kicked around this subject of monitoring....an you may recall I mentioned one program.......you also mentioned one..
just a matter of being curious on my part Joe...so please if you are busy ignor the questions.

snowman

 

Joe

just thought to save you some time....I have located the answer to my question......thanks

snowman

 

JUST FOR INFORMATION ONLY:::::::::



The file Microsoft msgsrv32.exe or msgsrv32.dll is a file located in the C:\WINDOWS\SYSTEM directory placed on the computer during the Windows installation. The description of this file is "Windows 32-bit VxD Message Server" and is responsible for such Windows tasks as:

Handle Plug and Play messages between various parts of the operating system.
Handle responses to and from setup programs.
Display the initial logon dialog box if a network is present or profiles are enabled.
Play the system startup and shutdown sounds.
Load the Windows drivers at startup and then unload them at shutdown.
Run the shell program.

 

Joe.....and others

say is this "exploit" the same as used by trojans such as:

COMA

Frenzy

HVL-RAT


snowman

 

Whoa!!! Wait!!

First, like some of the others here, I'm not downloading this thing to find out what it does. I learned my lesson on that with YALTA. Obviously, that means I haven't torn this thing apart.

For the precise details of how it works, you want input from someone who's done precisely that (and that's far beyond my area of expertise).

I'm simply extrapolating from the information provided here by people like Mickey and JacK, who have fiddled with it. This was a relatively easy call based on their observations and symptoms described. And, again, I track this kind of exploit all the way back to those seminal postings by EmilioG on the old GRC newsgroups.

In one sense, the details of exactly how PCAudit does this aren't terribly important; there are many possibilities of how it can be accomplished. In this sense, it's apparently just another later-generation Leaktest demonstrator. (And a lot of people got too caught up in the details of Leaktest and missed the larger implications.)

Let me give you a practical illustration: Here are the 13 files common to both Opera and MSIE. And, if you look closer, you'll very quickly recognize that almost all of these are going to also be called by just about any Windows-based Internet-enabled application out there.

Normally, I would be reluctant to post this list, but I already have (in another context) and long before this particular kind of exploit came to my attention -- so it ain't no big secret any more.
C:\WINDOWS\SYSTEM\NETBIOS.DLL
C:\WINDOWS\SYSTEM\NETAPI32.DLL
C:\WINDOWS\SYSTEM\COMCTL32.DLL
C:\WINDOWS\SYSTEM\WININET.DLL
C:\WINDOWS\SYSTEM\MSVCRT.DLL
C:\WINDOWS\SYSTEM\OLE32.DLL
C:\WINDOWS\SYSTEM\RPCRT4.DLL
C:\WINDOWS\SYSTEM\SHFOLDER.DLL
C:\WINDOWS\SYSTEM\SHLWAPI.DLL
C:\WINDOWS\SYSTEM\ADVAPI32.DLL
C:\WINDOWS\SYSTEM\GDI32.DLL
C:\WINDOWS\SYSTEM\KERNEL32.DLL
C:\WINDOWS\SYSTEM\USER32.DLL
C:\WINDOWS\SYSTEM\VERSION.DLL

I can only address the last question and my response is tentative even in that case. No, it would not necessarily.

Sure, remember that well. File authentication and monitoring (e.g., registry monitoring) are all parts of an effective suite of security utilities -- but both functions don't need to be in the same utility and they don't solve all the problems out there. Specifically, I don't think they'll solve this one.
In one sense I believe in security through diversity. I like having multiple vendors for multiple specialized utilities. And I would actually encourage people to use different vendors for different utilities. With the existing emphasis on code re-use, it's quite likely that if one utility provided by a vendor has a vulnerability, so will others. But it's far less likely that that 'common' vulnerability will be present in different kinds of utilities provided by different vendors. And it makes it a bit more difficult for the bad guys.

 

Joe

LOL...no I wont download this either.....

hey much thanks for your response....as mention this is merely a matter of being curious on my part.......at first just something to do on a rainy afternoon......I certainly haven't the knowledge to tear these things apart......curious yes...but not that curious...LOL
wishing a great day......

respectfully
snowman

 

Hello

New address for pcAudit http://www.pcinternetpatrol.com/products/index.php?product=audit.

 

I would like to know. Why would you let a program like this run on you system? (not saying this program is bad) I mean If you allow this program to run (SSM users) you're defeating the the point of using SSM. The whole point of using SSM is to block silly little programs like this. I think PG might even flag this program and ask if you want to allow it to run. I doubt a webpage can get into your computer and see what's on it and if they do well that's what encyrption is for. I know this thread is there to help people understand this type of thing but I feel that if you don't know what you're downloading, well don't download it. Practice safe computing and be happy.