Lucene search
K

slmail.ntfs.txt

🗓️ 17 Aug 1999 00:00:00Reported by David LitchfieldType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 28 Views

By-pass of NTFS permissions in SLMail 3.2 enables unauthorized access to files remotely.

Code
`By-pass NTFS permissions on machines  
running SLMail 3.2  
  
  
Introduction  
  
This advisory if for those running SLMail version 3.2 or 3.1 with the Remote Administration Service enabled.   
Due to certain short comings of this service any user with an account on the NT machine running SLMail can   
by-pass all NTFS file system permissions to read any file on the system that hasn't already been locked by   
another process (such as the c:\winnt\system32\config\sam file). Added to this, this file can then be read   
by anyone on the Internet.   
  
Details  
  
The Remote Administration Service in SLMail allows changes to mail services to be performed using the HTTP   
protocol over TCP port 180, by default. NTLM authentication can be enabled so that only users with an account   
and corresponding password may access this service. Once authenticated however, they do not need to be an   
Administrator to make changes to the mail services and user account information. This happens because the   
service does not impersonate the logged on user and every change made is performed under the SYSTEM account.   
  
Once authenticated they can then set a user's Finger File (Plan - for the UNIX people) to any arbritary file   
on the system. They must know the path to the file they wish to access. Once these changes have been set they   
can then "finger" the user and the file's contents are returned. This works because the finger service, which   
is controlled by the slmail.exe process is running as SYSTEM which has full control to all files on the machine   
by default. Needless to say if the machine is accessible via the finger port (TCP port 79) from the Internet   
then anybody will be able to read this file. (In some cases where there are non-standard alpha-numerics in the   
file or x00 values or similar the returned data will be truncated.   
  
If the Finger service, which is controlled by the slmail.exe process has been disabled by the administrator,   
it can be re-enabled from the Remote Administration web pages.   
  
Added to this problem many variations of service denial attacks can be launched, such as changing passwords,   
stopping services, overwriting files etc etc.   
  
Solution  
  
Because of this Remote Administration should be DISABLED. If this is not viable then the only way to prevent   
an unauthorized users (those with accounts) is to remove the "Access this computer from the Network" user right   
from the "Everybody" group and give this privilege to Administrators only.   
  
Cheers, David Litchfield   
  
Thursday 25th February 1999   
  
http://www.infowar.co.uk/mnemonix/slmailntfs.htm  
  
------------------------------------------------------------------  
  
Date: Thu, 25 Feb 1999 13:04:35 -0500  
From: David LeBlanc <[email protected]>  
To: [email protected]  
Subject: Re: [NTSEC] ALERT: SLMail 3.2 (and 3.1) with the Remote Administration Service  
  
At 06:36 2/25/99 +0000, mnemonix wrote:  
  
>Solution  
>Because of this Remote Administration should be DISABLED. If this is not  
>viable then the only way to prevent an unauthorized users (those with  
>accounts) is to remove the "Access this computer from the Network" user  
>right from the "Everybody" group and give this privilege to Administrators  
>only.  
  
You may want to verify that this is truly the case. Most of the time, the  
only thing that "Log on from the network" affects is services available via  
IPC$. That's why you see services that restrict users on the basis of  
logging on locally, logging on as services, and even logging on as a batch  
file. Given that this service doesn't seem to be impersonating users, I  
would be surprised if that right actually shuts down this avenue of attack.  
If you've already verified this, my apologies.  
  
It sounds to me like disabling it may be the only really safe choice.  
  
  
-----------------------------------------------------------  
David LeBlanc  
Internet Security Systems, Inc. | Voice: (678)443-6138  
300 Embassy Row. | Fax: (678)443-6479  
6600 Peachtree-Dunwoody Road NE | E-Mail: [email protected]  
Atlanta, GA 30328 | www: http://www.iss.net/  
  
------------------------------------------------------------------  
  
Date: Thu, 25 Feb 1999 19:22:01 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
Subject: Re: [NTSEC] ALERT: SLMail 3.2 (and 3.1) with the Remote Administration Service  
  
  
>>Solution  
>>Because of this Remote Administration should be DISABLED. If this is not  
>>viable then the only way to prevent an unauthorized users (those with  
>>accounts) is to remove the "Access this computer from the Network" user  
>>right from the "Everybody" group and give this privilege to Administrators  
>>only.  
>  
>You may want to verify that this is truly the case. Most of the time, the  
>only thing that "Log on from the network" affects is services available via  
>IPC$. That's why you see services that restrict users on the basis of  
>logging on locally, logging on as services, and even logging on as a batch  
>file. Given that this service doesn't seem to be impersonating users, I  
>would be surprised if that right actually shuts down this avenue of attack.  
> If you've already verified this, my apologies.  
>  
>It sounds to me like disabling it may be the only really safe choice.  
>  
  
  
I have verified this solution and it solves the problem of non-admins being  
able to logon and change service settings. It works like IIS - Basic  
Authenticated users are logged on locally and NTLM authenticated users are  
logged on as a network user.  
  
This solution may however break other network functionality such as NetBIOS  
logons (Domain Authentication) and consequently all subsequent NetBIOS  
network operations like use of file and printer shares.  
  
Cheers,  
David Litchfield  
PS - I've updated NTInfoScan (4.2.2) to check to see if this service is  
running. I've also put in a check for the /IISADMPWD issue. More information  
about NTInfoScan can be found at http://www.infowar.co.uk/mnemonix  
  
------------------------------------------------------------------  
  
Date: Wed, 10 Mar 1999 20:04:00 GMT  
From: Lee Thompson <[email protected]>  
To: [email protected]  
Subject: SLmail 3.2 Build 3113 (Web Administration Security Fix)  
  
I have just posted SLmail 3.2 Build 3113 which contains the following fix:  
  
  
(from the Release Notes)  
  
17. Changed/Improved the Web Administration security model.  
  
REV F - 03/10/99 - BUILD 3113  
  
  
  
This is phase 1 of our new Web Administration model.   
  
This fix specifically changes the logon authentication from 'any allowed NT  
user with directory permissions' to 'only let the following names onto SLmail  
admin' [still validated by NT].   
  
This information is stored in HKLM\SOFTWARE\Seattle Lab\SLhttp\LogonName.  
(Multiple logon IDs may be separated with a semi-colon.) No passwords are  
stored in this key.  
  
Our next phase (in progress) is to impersonate the user during web  
administration.  
  
  
_  
Lee Thompson [email protected]  
Seattle Lab Inc. http://www.seattlelab.com  
Product Manager  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation