Smidgen web server discussion

[Larry Charlton]

Place holder for any discussion of the Smidgen web server found here.

[Wayne Diamond]

[edit] (All issues in my posts here have been addressed)
--

One thing I always test for in a new Windows-based webserver is whether its vulnerable to NTFS alternate data stream reading... that is, instead of http://localhost/index.php we simply go to http://localhost/index.php::$DATA
(important to note that this isn't always possible directly from your _browser URL textbox_ as these days browsers tend to 'polish' the URL before transmission, but sending it yourself over TCP with "GET /index.php::$DATA" is simple, so don't bother with browser URL textboxes when testing vulnerabilities like this, always use raw TCP).

In the case of a file needing processing such as PHP, ASP, etc, the actual source code of the file will be returned as-is rather than rendered into HTML (as it's incorrectly determining that the file extension is an unknown ".php::$DATA" instead of ".php").

I didn't test your server specifically but a quick glance at the source code didn't reveal any specific checks to prevent this. That doesn't necessarily imply it's currently vulnerable though, but you'd still want to add specific checks (very easy to do), especially in case you inadvertently make such access available later. Vulnerable webservers -- i first found this in BadBlue many many years ago -- tend to simply check if a file exists via CreateFile -- which anyfile::$DATA does, because every file has the $DATA stream (it's actually the "main" data stream not an "alternate").

Preventing ADS can be as simple as checking for ":" in the filename.

Also don't forget to add errorchecks to the file opening (i dont see any around your OPEN statement), and also check for things like "../" for directory traversal. URL manipulation is one of the easiest ways to break in.

(I know you're probably more worried about basic functionality than security at this early stage, I'm just a bit backwards like that sorry)

See http://www.forensicfocus.com/dissect...hidden-streams for related info

[edit]Just got a chance to fire it up and did a quick test -- in its current configuration it doesnt seem vulnerable for NTFS streams, mainly because you're only allowing certain filetypes and even though you're incorrectly determining the extension it's being determined as an unknown one, but it is vulnerable for directory traversal.

The following POC will dump your webserver configuration file :shhh: (which is located one directory above your hosted \files\ directory where it should be inaccessible, but is accessible via "..\" traversal):

#COMPILE EXE
#INCLUDE "win32api.inc"
 
FUNCTION GetWebpage (sServer AS STRING, sURL AS STRING) AS STRING
    LOCAL sBuf AS STRING, sPage AS STRING, hPort AS DWORD
    hPort = FREEFILE
    TCP OPEN PORT 80 AT sServer AS #hPort TIMEOUT 10000
    TCP PRINT #hPort, "GET " & sURL & " HTTP/1.0" & $CRLF & _
                      "Connection: close" & $CRLF & _
                      "User-Agent: Mozilla/5.0" & $CRLF & _
                      "Accept: text/*, text/html, */*" & $CRLF & _
                      "Accept-Encoding: none" & $CRLF & _
                      "Cache-Control: no-cache" & $CRLF & _
                      "Host: " & sServer & $CRLF & $CRLF
    DO
        TCP RECV #hPort, 4096, sBuf
        sPage = sPage & sBuf
    LOOP WHILE LEN(sBuf)
    TCP CLOSE #hPort
    FUNCTION = sPage
END FUNCTION

FUNCTION PBMAIN () AS LONG
LOCAL sPage AS STRING
sPage = GetWebpage("127.0.0.1", "../config.txt")
? "RECV: " & sPage
WAITKEY$
END FUNCTION

Also "../../../Windows/setuplog.txt" is another interesting one (etc etc) - how many "../"'s you need will vary depending on where the webserver is installed, but it'll generally only take about one to five tries and can easily be automated. How you choose to deal with traversal is up to you - perhaps you just want to drop all requests with ".." in the non-filename part of the URL, or perhaps you want to attempt to 'clean' them first ... well, you can do whatever you want, it's your server - but they're easy to handle and as a file server must be handled!

You'll also need to test your mapping technique against such tricks, although that may actually make things more difficult to exploit as you're essentially manipulating the attackers URL.

[Larry Charlton]

Thanks! Interesting stuff. I don't think it would generally be susceptible to ADS, it should report a 415. Currently it would be if a dynamic processor processed files. I'll look at fixing that. for example, create a CGI parser mapped to /perl. a URL such as /perl/default.pl:ATA would pass it through.

I'll also fix the directory traversal. I'll have to think about it a bit. I want to allow things like ../img/myimage.png.

Oddly I don't see these impacting my future use but worth fixing in case someone else uses the code.

[Wayne Diamond]

Yeah i like traversal and it is legit... only needs a tiny bit of added attention to ensure it's secure. 'Decode' the traversals out of the URL yourself for example...
sURL = "../../index.php"
... --> ...
sURL = "C:\Program Files\Webserver\files\..\..\index.php"
... --> ...
sURL = "C:\Program Files\index.php"

IF IsWithinDir(sURL, "C:\Program Files\Webserver\Files\") = 0 THEN HttpErr 403 ("Forbidden")
(or is that 401 Access Denied? tomatoes n potatoes i tell ya...)
Anyway ill shut up about security now as thats not what this thread is about - functionally it's working perfectly fine btw

[Mike Doty]

A few checks in another server:

lsFileName = UCASE$(lsFileName)
IF INSTR(lsFileName, ":") OR INSTR(lsFileName, "..") OR LEFT$(lsFileName, 1) = "\" THEN
  EXIT FUNCTION 
END IF
 'Now check for approved and not approved, password protected files/folders (partial list) 
IF lsFileName =  "TEMP\" THEN EXIT FUNCTION
IF Right$(lsFileName,4) = ".DLL" THEN EXIT FUNCTION
IF Right$(lsFilename,4) = ".EXE" THEN EXIT FUNCTION

[Larry Charlton]

Updated code. the smidgen.bas in the code post is updated. The zip file contains some extra files.

Directory transversal should be fixed. The zip file includes Wayne's test to retrieve config.txt. I used GetFullPathName to compare the resolved file to the directory tree that files can be served from.

ADS vulnerability didn't exactly exist, but removed the possibility even if someone added it as a mime type.

Added url decoding.

Out of the box, listens on 127.0.0.1 (localhost) and the IP of your box.

Some test urls:
http://localhost/test.html - should return the test page.
http://localhost/test.htm - should return 404
http://localhost/test.blue - Should return 415 unsupported media
http://localhost/test+files/test.html - Should return a test page
http://localhost/blue/gravy - Should return Test1 from test1.dll.
http://localhost/red - should return Test2 from test2.dll.

Wayne's test (TestTraversal.bas a PBCC program) returns 404

If you change mapauto to 1 in config.txt you can also get valid pages at:
http://localhost/test1
http://localhost/test2

If you change mapexact to 0, you can add additional segments to the URL's.

You add additional mappings and/or create new DLL's.

If mapauto is 1 adding new DLL's will automatically add new URL's otherwise you'll need to add one or more mappings for the DLL's.

[Larry Charlton]

Changed the tests.

test1.dll generates from 1 to 100 guids.
test2.dll generates from 1 to 100 random numbers. Optionally can be between two numbers.

Both services support named parameters or URL parameters. Both services return plain text responses.

Changed the default configuration to support automapping and url parameters (mapexact set to 0).

Added a tests.html. It has several sample URL's going to localhost.

[Larry Charlton]

Added support for built-in services (included services).
Updated sample links html page
Added an echo built-in service