Re: File Upload - Security Issues

From: Roland Hall (nobody_at_nowhere)
Date: 10/20/04 

Date: Tue, 19 Oct 2004 20:00:45 -0500

"Azz" <Azz@azz.com> wrote in message
news:u5X4B5btEHA.160@TK2MSFTNGP11.phx.gbl...
: "Roland Hall" <nobody@nowhere> wrote in message
: news:<OWX0JEYtEHA.3572@tk2msftngp13.phx.gbl>...
: > "Azz" wrote in message news:%23OLf10StEHA.2244@TK2MSFTNGP10.phx.gbl...
: > : I've been faced with a bit of a pickle and was wondering if anyone
here
: > : would be able to help me out clear up a few points. I am wanting to
: upload
: > a
: > : file (unspecified type as of this moment, but could be MS Word,
Access,
: > : Excel etc).
: >
: > You're kidding, right? You want to upload a file for what reason and
you
: do
: > not know what type? One would think your goal would be defined first
and
: > then you would try to determine what the best solution would be. I'm
sure
: > your agument may be that but the difference in non-executable file types
: > doesn't factor in.
:
: How can this be possible? I have a list of files that potentially be
: uploaded and the user could upload any or all of these in theory. Maybe
you
: misunderstood, or maybe I mis-explained. "unspecified" was intended to
mean
: that I don't say what files people must upload. I simply limit their
choice.
: I can't believe a big list of the applications will be required for this
: point.

Both. It was unclear and I misunderstood. A big list of applications is
not required but rather the file type, i.e. data (txt files, doc files
[allowing scripting], source code [script, compilable], image, audio, video,
executable binaries, etc.

: My goal is very well defined, but I tried to keep my problem explanation
: brief so the fact people wouldn't have to read 4 pages of crap before they
: arrived at my question.

We appreciate that.

: > : We've spoken to a number of people including our tech team who
: > : are concerned about uploading these files to our Windows 2000 (or NT)
: box
: > : running IIS using ASP.
: >
: > And those are?
:
: To be honest, I'm not too sure. I ask the question to our technical
support
: team and they gave me the answer that from past experience, this was not
the
: way to go. Microsoft Word/etc documents can contain Macro's which can,
from
: my memory contain viruses. I am told therefore, if placed on a Unix box,
: these viruses have less chance of being able to execute (even if succeeded
: to attempt to do it) than if on a Windows box.

In a client/server environment the running process happens locally, not
remotely unless there is a remote connection, i.e. terminal services, remote
control software, etc.

If your system is already compromised, the data on it is the least of your
worries unless it's of course payload or utilities but in reality that point
is now moot since they can upload whatever they want. An attacker may take
a quick look to see if a tool already exists but generally by the time they
capture the flag, their plan is already being executed which will mostly
likely include utilities being uploaded.

: > : So we've had to come up with an alternative solution
: > : and we have a few ideas on ways around it.
: >
: > Perhaps the purpose of locating the file on the web server and which
type
: of
: > file and what pitfalls you see re: security might be helpful on this
end?!
:
: The process is:
: * Mr Joe public wants to tell us some information, and possibly attach a
: document which details more information, a presentation, results of some
: kind, blah blah blah! It's worth noting that Mr Joe Public is exactly
that:
: any member of the general public.
: * He then fills in our form and uploads his files.

If you allow Joe Public to fill in a form and access your site without
verification of who they are, then the types of files they send you is the
least of your worries. How do you determine that Joe Public is not Ev71
H4x0r?

: * These files are then saved to the file system, virus scanned, and then
: accessed by someone inside my organisation.

Accessed how? How does the internal user access the files on the system?
Where is the system located in reference to the internal user?

: > : Firstly I guess I should ask; Should I be worried about uploading MS
: > Office
: > : files to an IIS server that doesn't have MS Office actually installed?
: >
: > What are you worried about? How does your data file present a problem
to
: > security?
:
: Macro's can contain malicious code. MS Office documents can contain macros
: and viruses.

...when they are run in Microsoft Office and when macros are enabled in
Microsoft Office. I have tons of virii binaries/worms on one my systems and
I'm not infected. I have to make sure my antivirus doesn't scan that area
or everything will be quarantined [lesson learned] but I am not at risk by
any of those files unless someone compromised the system and executed one of
them in local memory but my antivirus agent is familiar with all of them and
they would then be quarantined. So, first they would have to disable my
antivirus and other utilities, not to mention getting passed my IDS, IPS,
NAT/Firewall, personal firewall, registry protection, memory protection,
application protection, etc. At this point, if they could do that, the
files on my system are the least of my worries. Is it possible? Sure.
Probable, not likely, especially considering those capable do not see my
system as interesting. Can they do it without my knowledge? Nope and who
is to say they haven't hit my Honeypot running on a CD?

Network security is an ongoing process and requires multiple layers to be
effective. There is no one product that can give you 100% security,
especially not an OS or web server.

: > : I am
: > : told, and therefore expect that this is not a good security
situation...
: > so
: > : I look at other ways around.
: >
: > And, I repeat, that is?
:
: Because it's feared that these files could be opened, causing some
malicious
: code to execute.

Code doesn't execute in local memory space unless remote user has rights in
that space. Like I said, it's too late at that point. If your question was
which do you think can be compromised easier, I'd say it depends on the
layers of security you have in place and the person on the other end. At
IOWargames, the only system not compromised was the Windows box.

: > : This leaves me with the option of palming the file off to PHP/Unix box
&
: > : scripting where it will be quite a bit safer.
: >
: > How is it safer?
:
: MS Office isn't native to Unix boxes, neither does the filesystem work the
: same.

You don't have Microsoft Office installed anyway? Is your worry based
solely on macros embedded in MS Office documents?

: > : One way that appears to be a
: > : possible solution is to do it as follows:
: > :
: > : 1* HTML displayed with a form (multipart/form-data enctype) and a file
: > input
: > : box.
: > :
: > : 2* Upon submit this is submitted to an ASP page that then (using the
XML
: > : object in ASP) effictively "posts" the information directly to the PHP
: > page.
: > : 3* This PHP page then takes the file and saves it to the Unix
: filesystem,
: > : and then, completes it's processing and sends XML information of the
: file
: > : back to the ASP page.
: > :
: > : 4* The ASP finishes parsing and displays the next bit of HTML
displaying
: > : whatever.
: > :
: > : We have successfully set up a XML submit to the PHP that retains all
the
: > : Request.Form post information as well as the multipart binary file.
: > :
: > : The problem I foresee (and basically my main question):
: > :
: > : * The IIS, when sending the multipart information, I presume it must
be
: > : storing the file in a binary temporary file somewhere? If so, is this
: > : something that could be run?
: >
: > Run? It's a data file. How can it be run if you are referring to being
: > executed? Surely you do not think a temp data file is executable?!
:
: Ok, open. And once open the Macro's/Virus runs it's evil code.

You don't have MS Office installed on the server. How does the code run?
The user doesn't know where you're storing the files, which should not be in
an area underneath the web root nor having execute rights.

: > : Therefore kinda making this process pointless.
: >
: > Still looking for the point.
:
: Yeah, it appears to have been lost. I want to know if I should be worrying
: about having Microsoft Office files on the Windows server and whether they
: could indeed be run by a clever attacker. And also, if doing it the way I
: proposed in anyway reduces this risk. Note that if question one returns an
: answer similar to "there is no risk", then question two would'nt really be
: an issue obviously.

Without an engine on the server, there is no risk. What would be more at
risk, to me, would be a script file, but again, it cannot be executed on the
server unless the script engine on the server is being called locally or by
someone remotely having local access, i.e. terminal services, et al...

: > : We are trying to avoid using PHP in great chunks as there is only
myself
: > and
: > : one other in our office that have had any hefty experience of it, and
: > : therefore, it would make it largely unmaintainable!
: >
: > A file upload process requires a lot of maintenance? No matter what you
: > choose, if that becomes part of your infrastructure, people will have to
: > brought up to speed or replaced with those that have or are willing to
: learn
: > the knowledge required to maintain it.
: >
: > : I hope this makes sense,
: >
: > Not really. So far, all I've seen is unsubstantiated claims that one
web
: > server/technology is greater than another. You're referring to security
: yet
: > you have to shown any reference to SSL, certificates, VPN, etc. We also
: do
: > not know your network design so we do not know where the [target] server
: > resides or any information regarding your security model. If your
server
: is
: > outside your control [hosted] then it's important to know that and if
it's
: > not, why not just make a network connection on the LAN?
:
: My "claim" is that one web server is built upon the same technology and
: backbone as some of the files I potentially upload. Therefore I ask, "is
: this safe"?

No OS or web server is safe. They all are at risk. Unless you are
competent enough to protect and test your network security, you will never
know how secure you really are until someone, who is capable tests it for
you. Sure, if you put code on a system that is not supported and it gets
compromised, you are at risk of it being run. However, at this point, it's
moot. They're already in!

: SSL? How would that help this situation? That would stop third parties
: taking part in transactions.

SSL involves a secure connection via remote connectivity to your server.

: Certificates? For everyone in the world?

The user accepts the certificate when the connect. Of course you would want
to use a trusted certificate source i.e. Thawte, Verisign, etc.

: VPN? That allows me to "dial-in" to the network. I don't think giving
: general public this would be something we'd consider doing in a great
rush.

Ya', probably not good for Joe Public but how about that internal user?
Also, what about using SSH?

: > : Any pointers on the above? Or as importantly, any pointers on things
we
: > have
: > : missed from our logic?
: >
: > No pointers to offer yet. Still need a lot more information. It
appears
: > you're looking for a vote, one way or another, regarding IIS/ASP vs
: *nix/PHP
: > and that is too limited to answer since neither, in itself, has anything
: to
: > do with security. And, no matter how one differs from the other, your
: > developer(s) can also render either/both of them completely insecure.
:
: Yes, it's possible the developers could do. But we're not up to that stage
: yet, we are still trying to work out how it works, and if what we are
doing
: is in the correct direction.

I would definitely say you're moving in the right direction. You're
investigating first before committing to an unknown process. I'm a firm
believer in "Fail to plan. Plan to fail." I think it is good you show a
true interest in your security of your network. It is difficult to provide
specific information regarding your project due to the narrow focus you have
shown here.

If your developers/engineers have more knowledge with IIS/ASP, then I would
use that. If they have more knowledge with *nix/PHP, then I would use that.
Both have good technologies, both have security vulnerabilities. Both will
have vulnerabilities in the future they may or may not be known now. Why do
you hear more about Microsoft? Well, why do you only hear about the US
deaths in Iraq? The fact is, if the person attacking your system is more
apt with *nix, your *nix box is more at risk. It is a variable a lot of
people do not factor in. Getting in is one thing. Knowing what to do once
you're in is something else and covering your tracks is impossible if the
network has a good security model in place.

I'm currently waiting for two systems that have allegedly been compromised
to perform forensics analysis on. The information I got was "it was an
inside job." Social Engineering will always be the easiest hack on the
planet. The biggest risk to network security is the internal user. Why?
They have access. And, if social engineering is the easiest hack, a
compromised internal user is a nightmare looking for a place to happen.
It's even worse when they're a participant.

Some things I would consider putting in place would be which should be
normal practices:

1. You should be protected against SQL injection.
2. You should be protected against cross-site scripting.
3. Uploaded files should not be stored beneath the web root or with execute
rights for any user, including administrators.
4. Users should be validated prior to being able to upload files. I have
written code that allows me to verify anyone even wanting to contact me via
form-based messaging. A separate process that visitors do not have access
to checks for validation and any message not validated within 24 hours is
removed automatically. Yours could be similar, allowing them to upload only
is validated otherwise restricted.
5. All files should be scanned for infection or file type violations.
6. Another possibility would be to add a specific prefix, extension to the
filenames of all files uploaded, making sure the are not executable. I used
to use a spam filter that did this to all attachments by default. If I
approved the message, the files were named back as before.

HTH... 

-- 
Roland Hall
/* This information is distributed in the hope that it will be useful, but 
without any warranty; without even the implied warranty of merchantability 
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

Relevant Pages

  • Re: File Upload - Security Issues
    ... uploaded and the user could upload any or all of these in theory. ... There is no one product that can give you 100% security, ... > Code doesn't execute in local memory space unless remote user has rights ... > You don't have MS Office installed on the server. ...
    (microsoft.public.scripting.vbscript)
  • Re: File Upload - Security Issues
    ... You want to upload a file for what reason and you do ... file and what pitfalls you see re: security might be helpful on this end?! ... files to an IIS server that doesn't have MS Office actually installed? ... 2* Upon submit this is submitted to an ASP page that then (using the XML ...
    (microsoft.public.scripting.vbscript)
  • [NEWS] Multiple Vulnerabilities in BEA WebLogic Server (Un-authenticated File Uploading)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... web server contents, load servlets, etc. ... The process in charge of managing the file upload validates the user ... ConnectionFilter will filter connections based on the request source ...
    (Securiteam)
  • MS and security: good effort but no cigar
    ... build upon the progress it's already made in security. ... The low-hanging fruit of millions of insecure Windows machines ... Then there's the issue of poorly secured server applications. ... and execute external virus and filtering ...
    (microsoft.public.windowsxp.general)
  • Re: File Upload - Security Issues
    ... You want to upload a file for what reason and you ... these viruses have less chance of being able to execute (even if succeeded ... > file and what pitfalls you see re: security might be helpful on this end?! ... files to an IIS server that doesn't have MS Office actually installed? ...
    (microsoft.public.scripting.vbscript)