Vulnerability in Sugarcrm

[Rajesh Patel]

Application is working fine and i was supposed to implement the application in our company, but before implementing we had to go for Penetration testing and we have found 1 high risk and 5 medium risk i have to solve all the issue otherwise my IT team will not allow me to implement the sugarcrm. Please find below the List of vulnerabilities

High Risk
1 ) An advesary can use a logged in user as a session for sensitive operation via CSRF attack

Medium Risk
2 ) An advesary can steal sensitive application data by sniffing clear text traffic -
3 ) An advesary can upload malicious files to the server
4 ) A local advesary can steal password from the Autocomplete feature of the browser
5 ) A local advesary can hijack session as session token is not changed on login
6 ) A local advesary can steal password from the browser memory

Please suggest on the same.how to solve the issue as i want to implement sugarcrm in our company.

[salesagility]

What version are you working on?

Secunia does not have any of these issues logged.

Can you be more specific about these exploits ...

High Risk
1 ) An advesary can use a logged in user as a session for sensitive operation via CSRF attack - was dealt with in 5.2(j) (I think) patch

Medium Risk
2 ) An advesary can steal sensitive application data by sniffing clear text traffic - use HTTPS - not specific to Sugar .. applies to any application over http
3 ) An advesary can upload malicious files to the server - file types defined in config
4 ) A local advesary can steal password from the Autocomplete feature of the browser ... please define ... what browser ... is this Sugar or browser issue
5 ) A local advesary can hijack session as session token is not changed on login ... please define
6 ) A local advesary can steal password from the browser memory - see above

[Rajesh Patel]

Please find the detail step below

1. An adversary can use a logged in userâ'™s
session for sensitive operation via a CSRF attack
Important features of this application do not contain any token in the request thus the
application is vulnerable to Cross Site Request Forgery (CSRF) attack. This is how the attack
works - an adversary tricks the user to visit a special page he has created while the user is
logged on to the application i.e. to add new contact. This special page triggers a request to the
application with the user's session information. The request is forged to look like a valid request
to add new contact. When the request is sent from the victim's machine, the valid cookies with
the session information are also sent. The application misunderstands that the request is valid,
as it contains the cookies. So, the action is performed without the user's knowledge.

The special page is quite easy to create. It could be a simple HTML page for POST request
with the action pointing to the important page.

Step 1: Login to the application http:/sugarcrmURL/sugarcrm as "pentest". Go to Home enter the Contact details and click save.

Step 2: Capture and copy the request using any web proxy editor tool (burp). Now, drop this
request so that the request does not reach the server.

Step 3: Create a HTML page using above captured URL and parameters to delete instance

Step 4: Open the crafted HTML page in a new tab on the same browser where the user is logged in.Press the “Submit option displayed on the page.

Step 5: When the logged in user clicks the Submit button, the request to add new contact is
sent to the server without the user's knowledge. Browser also sends the logged in user's cookie
with the request

Step 6: the contact "rajesh" has been added through CSRF attack.

2 ) . A local adversary can steal password from the
Autocomplete feature of the browser
Browsers have a feature to remember the recently typed web addresses, web form entries,
usernames and passwords. When a user starts typing, the browser suggests possible matches.
This feature is known as Autocomplete in IE and "Remember Passwords" in Firefox. If a
browser is configured for "AutoComplete settings/Remember Passwords" to remember
username and password, then every time a user logs into the application, browser asks user to
remember the password. If the user had accidentally or intentionally clicked 'Yes', then a local
adversary can login with the "remembered" password of the previous user.

The browser also stores the saved password either in Clear Text or in a form which is easily
reversible by an adversary.

Step 1: Enter the Username & password on the Login page and click on "Remember" button
when the browser prompts the user to save his password

Step 2: The saved password can be viewed by clicking on Tools->options->security->saved
passwords

3 ) . A local adversary can hijack session as session
token is not changed on login

The application assigns a session token when the login page is accessed. When a user logs in,
the same token is being bound to the username to identify the user for the session. An
adversary, who has noted this session token on the login page and left the browser window
open, can hijack the legitimate user's session who logs into the application using the open
window. The adversary has the valid session token which is now assigned to the user.

Step 1: Enter the url "http://sugarcrmurl/sugarcrm" in a web browser and see the
session id in a web proxy tool

Step 2: Login as a valid user and again see the session id in a web proxy tool. The following
screenshot shows the value of the session cookie has not changed.

[salesagility]

Number 2 is a browser issue and could relate to any application where the browser remembers the password including salesforce, netsuite, microsoft webmail .... the list is endless.

[salesagility]

Number 1 may have been fixed ... 2 things ... comments by sugarcrm would be appreciated and secondly ... you do not answer what version you are using.

Number 3 ... answers from SugarCRM may help ... as it's critical that:

1. If there are issues, they are addressed quickly
2. If there are no issues and this is FUD, that it is diffused as soon as possible.

[Rajesh Patel]

I am using 5.2j version

[wdroush]

Doesn't #1 require the attack to come from the same domain that the CRM resides on (being as it needs to gather cookie data on the login), if you have people injecting websites on your servers you got greater issues I would think.

And these require man in the middle attacks (web proxy scraping), which over HTTP, is going to be pretty much make every request a security hole, correct? Under HTTPS all session scraping becomes extremely difficult, pretty much impossible (minus compromising the machine itself).

[mvngti]

I agree, the so-called vulnerabilities in this thread is hugely exaggerated and not related to SugarCRM at all but rather to sloppy setup.

ANY web based app run over http will suffer from these same issues and even no 3 can be prevented by simply setting the verify ip address option in the system settings to on. Session ID + client IP mist be unique and verified for any web app to be secure.

With https connections and veify ip address on, none of these issues will exists on a (proper) SugarCRM installation. This is all FUD.

M