5 Ways to Avoid a Cryptolocker Crisis

“You are infected. If you want to use your data again, pay us 300USD.”

Cryptolocker — a ransomware developed by cyber criminals that encrypts all the files on the infected computer and demand ransom to provide the user with a decryption key, has infected hundreds and thousands of computers all around the world and has collected up to $30 million in ransom so far. What makes this code highly destructive is that the decryption key, which can be used to regain access to the encrypted files, is available only with the hackers, and once the key is lost, the encrypted data is essentially lost forever.  

So, if you don’t want your computer to get infected by this ransomware that can lock all your personal and business files and restrict your access to them until you pay a ransom to the hackers, it is important that you follow the 5 safety tips given below that minimize your vulnerability against Cryptolocker.

1.    Backup Everything

There’s no way you can retrieve your data once Cryptolocker has infected your computer. Therefore, create regular backups. Follow the 3-2-1 backup rule to mitigate data loss risk due to Cryptolocker.

The 3-2-1 backup rule suggests you to:

          3 — Have three copies of your data

          2 — Keep the backups on two different media  

          1 — Have one offsite backup

Also, make sure that the data present on your portable hard drives and USB flash drives has been backed up too because Cryptolocker can infect your portable data storage devices as well.

2.    Cleanup Your Machine

When you have no other choice than to pay off the ransom, make sure that you have taken every possible measure to prevent the spread of this highly virulent infection. Disconnect the internet connection of the infected machine, turn off cloud backup services, and remove any portable storage device connected to the computer. Don’t forget to report the cyber crime to the relevant local or federal authority.

3.    Don’t Open Suspicious Emails

No matter how strong the temptation is, never open unsolicited emails or emails that imbibe suspicion or a sense of urgency. If you have accidentally downloaded an attachment that looks dodgy, immediately run an anti-virus program to kill any destructive codes present in it before they damage your computer.

4.    Control the Access Rights of Your Employees

The BYOD culture and excessive use and sharing of encrypted data have made networks more vulnerable to different types of ransomware. Review the access rights of your employees and offer only what’s necessary. Also, educate your network users regarding best data handling practices and guide them to contact the IT security personnel if they suspect an infection.

5.    Patch to Protect

Cyber criminals are exploiting on the vulnerabilities of Microsoft and Adobe to gain access to the users’ computers and infect them. Therefore, it is advisable that you keep your systems updated with the latest virus definitions and patches.

Using these tips, you can minimize your chances of getting a Cryptolocker infection. 

Growing CyberSecurity Threats and SMEs

Cybersecurity Surveys targeted at SMEs, show that 63% of SMEs are concerned about malware, and 38% are worried regarding potential phishing scams, however 31% aren’t doing nothing to guard against such threats. While I seriously doubt that only 63% of SMEs are concerned, where a 100% of them should be worried, but statistics being statistics, it is alarming to see that 31% of these SMEs are not doing much to protect themselves. There are some surprisingly simple steps that SMEs can take to protect themselves.

Strong Robust Passwords Never use default vendor passwords. Use different passwords for different services. Use different passwords for different services. Eg: Your email password should not be the same as your recruitment portal, which should not be the same as your payroll, or any other banking sites.

Two Factor Authentication Use (2FA) 2-factor authentication for all business accounts, where possible. Gone are the days when 2FA was expensive. Economical options have flooded the market. Work with your MSSP to find the right fit for your business.

Don’t Transmit Data in cleartext Mandate encryption on all critical information — Think about Data at rest, Data in motion and don’t forget Data in processing.

Engage Employees Make security part of everyone's job. Every employee including your accountants, frontdesk, developer, administrators should understand that security is their responsibility. Failure could very well result in losing their job, as the business may have to shut down.

Don’t mix Business and Pleasure Use a dedicated device for online business banking and business financial activities. Have a separate device for personal email and social media.

Continually Assess Risk and Update Procedures On a regular basis, audit assets and valuable data warehouses to spot where your organization is most vulnerable. Cultivate a habit of questioning the security posture of your business, vendors, suppliers or partners regularly. And then, update, update, update. Use an MSSP to manage these processes for you, while you understand and oversee the overall program.

Secure Browsers Keep up with the most recent version of your preferred browser. Then, check its configuration for weakness. Again, you don’t have to be alone on this. Consult and use the services of an MSSP.

Implement time-outs Implement “time out” functions (requires re-login after a period of inactivity) for all business computers. Require robust passwords that have to be modified on a periodically.

Secure wireless web Routers Think about configuring your WiFi securely. Use the latest WPA2 technology, which currently is extremely hard to crack. Hiding the name of your SSID is not a security measure, so don’t bother. Your MSSP can help you secure your WiFi, and monitor its usage for malicious activity.

Back Up information If the recent ransomware attacks have a silver lining, it is the emphasis they have brought on BackUps. 

This list is prescriptive at best and is not comprehensive and definitely not an replacement to an professional security expert consultation. A strong MSSP partner for SMEs goes a long way in mitigating the cybersecurity risks.

Backdoors in SAP ABAP Code Part-1

ABAP Intro:

ABAP is SAP's proprietary programming language used since last 30years. Almost 90% of the Business logic and functionality were written in ABAP. SAP delivers standard Business functionality and with standard programs(Developed by SAP, Shipped during installation). Any new developments or modification to ABAP Programs are logged in the system and later moved to Production system via SAP Change And Transport System (CTS).

Modification to Standard Programs:

SAP will not allow their customers to modify Standard Programs, but instead customers can perform modifications to standard ABAP programs only after following a process called SAP Software Change Registration (SSCR). According to this registration, SAP does not guarantee that the modified programs will not be overwritten in the future SAP upgrades.

Custom Developments:

In order to meet the business requirements of their customers, SAP allows them to develop their own custom ABAP programs and custom business scenarios via builtin development environment. All the custom developments and program names will start with letters 'Y' and 'Z' (also called zprograms).

ABAP Backdoors:

Like many other application, SAP is vulnerable to backdoors. Backdoors can be used to bypass authorization checks and authentication mechanisms in an application. These backdoor can take different forms like hardcoded usernames within ABAP program, hardcoded credentials in RFC connections without use of encryption, Maintaining default User names and Password.

All the SAP standard and custom ABAP programs are stored at Database level in table "REPOSRC". Source code of all the programs exists in "DATA" field of table "REPOSRC" in compressed format.

Hard-Coded Usernames:

It's been found that many custom developed ABAP programs contain hardcoded usernames like below code snippets and were moved to Production systems. Even the SAP Standard Programs have room for hardcoded usernames, these hardcoded usernames were left by developers for testing purpose and were delivered to the SAP customers. Attacker can take advantage of these hardcoded usernames to bypass security controls and can perform critical business transactions.

Lets check the first ABAP code snippet with hardcoded Username "Dev":

...
Snippet-1
.........
TABLES: USR02.
 DATA:  YLOCK(1) TYPE X VALUE  '0', ZLOCK(1) TYPE X VALUE '64'.
 parameters: client like sy-mandt.

CHECK SY-UNAME = 'Dev'. (SY-UNAME contains the name of currently logged-on user)

      select * from usr02 client specified
       where mandt = client.
       usr02-UFLAG =  ZLOCK.
       UPDATE  USR02 client specified.
      endselect.
...

Execution Flow:

• Program checks if the current user account is "Dev" or not.
• If the current user is "Dev", system locks all the users available in the specified client.
• If the user is not "Dev", it does nothing.

Risk:

• In general, locking down all the users in an SAP system can lead to DOS(Denial Of Service) attack.
• Here an attacker can take advantage of these hard-coded checks to bypass security controls.
• In this case, if attacker creates the user account "Dev" and execute the program in Production system. All users will be locked.

Snippet-2 with hardcoded Username "DEVELOPER"

ABAP System field "SY-UNAME" in the code snippets always contains the name of currently logged-on user. ABAP developers make use of statement "AUTHORITY-CHECK" to performs the authorization checks wherever required. These checks are performed based on arguments (authorization object, field, values) passed in "AUTHORITY-CHECK" statement.

...
Snippet-2
.........
IF sy-uname <> 'DEVELOPER'. (SY-UNAME contains the name of currently logged-on user)
    AUTHORITY-CHECK OBJECT <authorization object="">
     ID <authority 1="" field=""> FIELD <field 1="" value="">. 
     ID <authority 2="" field=""> FIELD <field 2="" value="">. 
ENDIF.
...

Execution Flow:

• Above code snippet makes use of IF statement to check whether the current user is "DEVELOPER" or not.
• If current user is different from the account "DEVELOPER", then system performs the authorization checks as defined.
• If the user account is equal to "DEVELOPER", then system skips the authorization checks and continues the execution with other code.

Risk:

• Attacker can take advantage of hard-coded checks to bypass security controls.
• If the attacker doesn't have required authorization, he creates a new user account "DEVELOPER" and execute the program, which in this case if user account is "DEVELOPER" system does not perform authorization checks thereby bypasses the security check.

Countermeasures:

• Before moving ABAP developments to Production, use SAP standard report RS_ABAP_SOURCE_SCAN to search and detect dangerous ABAP code snippets.
• As recommended by SAP check and apply the security notes on regular basis.

Reference:

Onapsis

Backdoor in SAP User Master Record

SAP User master holds the information related to the User, Personal information, Assigned roles and authorizations, etc. In the world of SAP, any user with Authorization Profile "SAP_ALL" will have the highest privileges in the System.

In the previous post, we have noticed that the SAP systems store passwords in database table USR02 and can generate downwards-compatible hashes in order to communicate properly with the interconnected SAP systems (older versions) where newer hashing mechanisms are not supported.

During the logon procedure, a hash value of a password is generated by the system outside the SAP kernel and then compared with the stored password hashes in the USR02 table. This process is controlled by SAP parameter "login/password_downwards_compatibility".

As per the requirement SAP administrators can set different values-(0-5) for the parameter "login/password_downwards_compatibility". In the newer SAP Releases this parameter is delivered with a default value set to '1'.

Parameters          
------------------------------------------------------
login/password_downwards_compatibility  

Values (0-5) as below
------------------------------------------------------
0: Stores passwords in a format that systems with older kernels cannot interpret. The system only generates new (non-backward-compatible) password hash values.

1: System generates backward compatible password hash values internally, but does not evaluate these for password-based logons (to its own system). 

2: System generates backward compatible password hash values internally and checks them when logon using non-backward compatible password (newer hashes) fails. In this way, the system checks whether the logon would have been accepted with the backward compatible password (truncated after eight characters, and converted to uppercase).

3: As with 2, but the logon is regarded as successful. This setting is to allow the avoidance of backward incompatibility problems.

4: As with 3, but the system does not create an entry in the system log.

5: Full backward compatibility: the system only creates backward compatible password hash values.

SAP system supports different password hashing algorithms called Code Versions, but due to downwards-compatibility requirement newer SAP Releases are still having support for older password hash algorithms, Some SAP releases use code versions 'G'. for more info about SAP Code Versions check here.

One thing to be clear, SAP Code version 'G' is not an algorithm. But its a combination of both Code Version 'B' and 'F'. Which means when we use code version 'G' SAP generates two types of hashes and stores them in database:

• Code Version 'B' password is stored as MD5 hash (up to 8-characters, Upper case) in "BCODE" field of table USR02
• Code Version 'F' password is stored as SHA1 hash (up to 40-characters, Case insensitive) in "PASSCODE" field of table USR02

How can a attacker could gain the highest privileges (SAP_ALL)...?

• Attacker generates his own MD5 password hash for userid BASIS. 
• Replaces the BASIS user's password hash with a attacker's hash by updating the "BCODE" field in SAP table USR02. 
  

• Changes the SAP Profile parameter "login/password_downwards_compatibility" value to '4' (no SAP system log entry).
• Logs into the SAP system with the user BASIS and his own password, without knowing the legitimate user's password.
• Now the legitimate user can log into the system with his userID and password, whereas the attacker can also log into the system using the same userID (i.e. BASIS) but with different password.
• Attacker can now login to SAP system without knowing the actual password, Once getting access into the system he could assign the required permissions or can perform some database activities.

Countermeasure:

• Restrict access to all critical tables. 
• Changes to the value of profile parameters should be monitored.
• Set the parameter "login/password_downwards_compatibility" value to '0', if downwards-compatibility not required. 
• 1023437 - ABAP syst: Downwardly incompatible passwords (since NW2004s)
• 1458262 - ABAP: recommended settings for password hash algorithms

Understanding SAP password hashing Mechanism and Cracking

What is this Code Version thing?

SAP stores password hashes of all users in table "USR02" and other tables "USH02, USRPWDHISTORY" contain changed password history. ABAP systems do not save passwords in plain text, but instead calculates the hash value and saves them in database, so it cannot be read by anyone having direct access to the database tables. 

Over the time, to improve the security and performance SAP has implemented different password hashing mechanisms which generate password hashes via different algorithms called Code Version "CODVN". Most recent algorithm used is “I”, older versions are:

CODVN Description
--------------------------
A Obsolete
B Based on MD5, 8 characters, Uppercase, ASCII
C Not implemented
D Based on MD5, 8 characters, Uppercase, UTF-8
E Reserved
F Based on SHA1, 40 characters, Case Insensitive, UTF-8
G Code Version B + Code Version F (2 hashes)
H Based on SHA1, rand. salt, 40 characters, Case Insensitive, UTF-8
I Code Version B + Code Version F + Code Version H (3 hashes)

In SAP Table USR02, USH02 the password hashes are stored in different fields based on the CODVN as below:
-----------------------------------------
CODVN B hashes - BCODE field
CODVN F hashes - PASSCODE field
CODVN G stores both the hashes of CODVN-B and F (i.e, BCODE, PASSCODE fields)
CODVN H hashes - PWDSALTEDHASH field
CODVN I similar to CODVN-G and stores the CODVN-H in PWDSALTEDHASH field


How does this cracking work?

As stated above, as of SAP NetWeaver 7.0 system supports new password hashing Mechanism that can generate password consisting of up to 40 characters and are case-sensitive (CODVN: F). It is also possible to use any Unicode characters. But with the older releases of SAP, system generates password consisting up to eight characters and system itself converts them from lowercase to uppercase case letters (CODVN: B,D).

Unfortunately, the above improvements were not backward compatible. which means the passwords stored as hash values in USR02, USH02 are not backward compatible with older releases of SAP or other connected system. 

If you are using an SAP system together with other SAP systems that only support backward compatible password hash values, then there is a need to activate the SAP system profile "login/password_downwards_compatibility". With Downward Compatibility SAP can generate all the possible hash values and uses them wherever required while accessing other SAP systems.

In general we shouldn't be able to retrieve the plain text password from the hash value. But there are some famous password cracking tools like Hash-cat, John the Ripper that are loaded with modules for cracking two of the SAP hash algorithms (CODVN B & F/G). 

Lets say SAP system uses the CODVN-G, which is combination of CODVN-B and CODVN-F. So if we crack the CODVN-B first (MD5,8-characters,Uppercase,ASCII) we get to know 8-characters of the password used within CODNV-G.  In CODVN-B SAP password hashes are salted only with the username. Then using those 8-characters, we can create a password dictionary (using known 8-character as prefix) with all possible characters to crack the remaining character of the password with CODVN-G.

Prevention:

• Protect access to the hash values in tables like USR02, USH02, USRPWDHISTORY.
• Use the most recent password hashing algorithm, see parameter login/password_hash_algorithm.
• Set parameter login/password_downwards_compatibility = 0 (this might break communication with systems older than 7.0, check carefully).
• Delete old hashes, see ABAP report CLEANUP_PASSWORD_HASH_VALUES.
• Restrict direct access to the SAP databases via transaction code DBACOCKPIT (SQL prompt) or OS level.
• Choose strong passwords (enforce them via policies) via the password parameters.

      login/min_password_lng
      login/min_password_letters
      login/min_password_digits
      login/min_password_lowercase
      login/min_password_uppercase
      login/min_password_specials
      login/password_max_idle_productive
      login/password_max_idle_initial
      login/password_history_size
      login/password_expiration_time     Other Parameters

Reference:
1237762 - ABAP systems: Protection against password hash attacks
1458262 - ABAP: recommended settings for password hash algorithms
862989 - New password rules as of SAP NetWeaver 2004s (NW ABAP 7.0)
http://www.daniel-berlin.de/

SAP NetWeaver code injection via TH_GREP Functional Module

TH_GREP is functional module used by several other SAP programs to search for required string. Function Module TH_GREP contains a vulnerable code that permits the execution of operating system commands remotely, allowing the malicious user to take control of the SAP system by escalating privileges without having a valid credentials.


We can invoke this:
     Vulnerable code via transaction Code "SE37" using function module "TH_GREP"

GREP command utility is used to search a string from within transaction "SM51" screen, which can be misused to trigger the backend vulnerable code as below:

Using remote RFC call "TH_GREP"
Using SOAP RFC call "TH_GREP" via web


  Reference:
http://erpscan.com/

  Prevention:
Restrict access to critical transactions and RFC functions.
        Implement SAP Notes 1580017, 1433101

SAP Web Attacks and Countermeasures

This article focus on:

• Different SAP web Application Servers
• Fingerprint SAP web applications
• Countermeasures

Different SAP web Application Servers:

Internet Transaction Server (ITS)

• SAP introduced ITS (Internet Transaction Server), its initial approach to enable internal access to SAP Servers. ITS acts as a middleware that is capable of translating SAP Dynpros (Dynamic Programs) into HTML Pages. ITS was integrated in WAS 6.40 (Web Application Server).
• ITS is composed of two major components AGate (application gateway) which links the ITS to the SAP System by receiving Web browser requests from the WGate (Web gateway) via the Web server and communicating with the application server using the DIAG or RFC protocol.

URL syntax to access ITS web service:

http://<server>:<port>/<path_to_wgate>/<service_name>/!?<optional_params>

Internet Communication Manager (ICM)

• ICM (Internet Communication Manager) ensures that communication between the SAP Web Application Server and the outside world via HTTP, HTTPS and SMTP protocols works properly. 
• ICM is a component of the SAP NetWeaver Application Server. ICM web requests are handled by ICF (Internet Communication Framework), which provides the service based on arriving URLs, by default ICF services are inactive. ICM Parameters to configure the SAP Server for HTTP, HTTPS, and SMTP.

# Definition of the ports 
icm/server_port_0 = PROT=HTTP, PORT=1080 
icm/server_port_1 = PROT=HTTPS, PORT=1443 
icm/server_port_2 = PROT=SMTP, PORT=1025  

# Parameters for SSL support 
sec/libsapsecu = $(DIR_EXECUTABLE)/libsapcrypto.so 
ssl/ssl_lib = $(DIR_EXECUTABLE)/libsapcrypto.so 

# Parameter for ICM Security Log [Parameters MAXSIZEKB=<max size in KB>, SWITCHTF=<options>, FILEWRAP=on]
icm/security_log = LOGFILE=<file name>, LEVEL=<security level>

# Parameter for ICM logging [Parameters LOGFORMAT=<format>, FILTER=<filter>, MAXSIZEKB=<size in kbytes>, SWITCHTF=<options>, FILEWRAP=on]
icm/HTTP/logging_00 =  PREFIX=<URL prefix>, LOGFILE=<log file name>  

SAP Enterprise Portal (EP)

• Portal provides single point of access to organization’s SAP and non-SAP information sources, enterprise applications, databases and services across organizational via web-based interface.
• It’s a complex Java application running on J2EE engine, providing role-based access to enterprise information and applications.

Enterprise Portal Ports
HTTP 5xx00
HTTPS 5xx01
Where xx is the Java instance number (JCxx).

Fingerprint SAP web applications

• It’s common to have the SAP application to be accessed via Internet. Which makes it easier for anonymous users to find and fingerprint SAP Systems. A simply means of finding SAP system connected to Internet is via Search Engine like Google, Shodan, etc. 
• Once the attacker identifies the SAP systems on the web, attacker can gather version information of the SAP components “ITS, ICM, J2EE Engine (EP)” easily by sending simple HTTP requests to SAP web server, which responds back with sensitive information (send to attacker). 
• Exploring through Enterprise Portal error messages, we can identify the version of enterprise portal installed as below (In the case Enterprise Portal version: 7.00)

• Exploring through ICM error messages, we can gather SAP System information like SAP Server Hostname: sapides, System ID: IDS, Instance Number: 00

• There are more than 1500 standard ICM services within SAP ECC and each service is used to access the application data. In some SAP installations few of those services are active by default, which may lead to sensitive information disclosure as below. 
• Access to ICM Service “/sap/public/info”, can be used to gather sensitive information like SAP System ID, Hostname, Database Type, SAP Release, Patch level, SAP kernel version, OS type, etc.

In ICM there are two types of services Public and Private. Public services can be executed directly whereas Private services requires initial authentication and later based on the SAP ICF (Internet Communication Framework) authorization objects that were assigned to the user, he/she can execute the required ICM service.

Reference:          

  https://help.sap.com/saphelp_nw73/helpdata/en/48/3d14a6b08c72d1e10000000a42189c/content.htm