Re: File Upload - Security Issues
From: Azz (Azz_at_azz.com)
Date: 10/20/04
- Next message: MartinP: "creating acces object"
- Previous message: McKirahan: "Re: How to use vbcript with MS office 97"
- In reply to: Roland Hall: "Re: File Upload - Security Issues"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 20 Oct 2004 11:51:10 +0100
Thanks for your help on this!
You have confirmed and changed some of my views and hopefully whats written
now will be as secure as it can be, paying attention of course to your 6
points at the bottom. As you say, no system can be 100% secure.... but I'd
rather be one of the strongest links, as opposed to the weakest!
Thanks greatly for your time, and yes it has helped! (If only for a greater
personal understanding)
Azz
"Roland Hall" <nobody@nowhere> wrote in message
news:<#GL48AktEHA.3572@tk2msftngp13.phx.gbl>...
> "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
>
>
- Next message: MartinP: "creating acces object"
- Previous message: McKirahan: "Re: How to use vbcript with MS office 97"
- In reply to: Roland Hall: "Re: File Upload - Security Issues"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
