OXID eShop two vulnerability analysis-vulnerability warning-the black bar safety net

2019-07-31T00:00:00
ID MYHACK58:62201995295
Type myhack58
Reporter 佚名
Modified 2019-07-31T00:00:00

Description

RIPS in the OXID eShop software was detected in a high-risk vulnerability, an unauthorized attacker could exploit the vulnerability in a few seconds the remote take over using the default configuration of the target site. In addition the admin panel there is also another vulnerability, an attacker can use this vulnerability to gain server remote code execution RCE)permission. It is recommended that the user as soon as possible to upgrade to the latest version. OXID eShop is derived from the German set of e-Commerce content management systems, many leading companies such as Mercedes, BitBurger and Edeka are using the enterprise edition of OXID eShop it. In this article we will analyze how the default configuration of the latest version OXID eShop(6.3.4 in order to not authorize the attacker's identity to gain remote code execution privileges. The attack process can be reference here to the video, you can visit here to access the RIPS system analysis results.

0x01 SQL injectionvulnerability This e-Commerce software in the presence of aSQL injectionvulnerability, by unauthorized remote session use, the use of the process without relying on the target end of the special configuration. Whenever the user is viewing a product, the service end will be through the _getVendorSelect()method constructs a SQL query statement sent to the underlying database. Source file: source/Application/Model/ArticleList.php protected function _getVendorSelect($sVendorId) { ⋮ if ($this->_sCustomSorting) { $sSelect .= "ORDER BY {$this->_sCustomSorting} "; // line 1087 } return $sSelect; } And the service end will be in before the code calls setCustomSorting()method, set the _sCustomSorting property, through the property to construct the ORDER BY SQL statement of the above code section 1087 rows, then this will become an attacker of an injection point. Source file: source/Application/Component/Locator.php $oIdList->setCustomSorting($oLocatorTarget->getSortingSql( // line 131 $oLocatorTarget->getSortIdent())); In the above code fragment 131st line, the custom sort property values will be set to getSortingSql()method's return value, and the service end will be in the FrontendController class getSorting()method call getSavedSorting()method to set this value. Source file: source/Application/Controller/FrontendController.php public function getSorting($sortIdent) { ⋮ if ($sorting = $this->getUserSelectedSorting()) { /.../ } elseif (!$ sorting = $this->getSavedSorting($sortIdent)) { // line 1424 $sorting = $this->getDefaultSorting(); } /.../ public function getSavedSorting($sortIdent) { $sorting = \OxidEsales\Eshop\Core\Registry::getSession() // line 1430 ->getVariable('aSorting'); /.../ return $sorting[$sortIdent]; } From the code we can see, the getSavedSorting()method will access the OXID of the internal session object, the 1430 line, extract aSorting value: this line of code does the equivalent of directly reading the PHP session variable$_SESSION[‘aSorting’] is. An attacker can control this variable, and the variable it is the exploitability of the vulnerability of the critical point. The value of the variable will be written to 1430 rows of the$sorting variable through the call stack to return, and eventually passed as parameters to the previously mentioned setCustomSorting()method. Source file: source/Application/Component/Widget/ArticleDetails.php protected function _setSortingParameters() { $sSortingParameters = $this->getViewParameter('sorting'); /.../ list($sSortBy, $sSortDir) = explode('|', $sSortingParameters); $this->setItemSorting($this->getSortIdent(), $sSortBy, $sSortDir); } /.../ public function setItemSorting($sortIdent, $sortBy, $sortDir = null) { /.../ $sorting[$sortIdent]['sortby'] = $sortBy; $sorting[$sortIdent]['sortdir'] = $sortDir ? $sortDir : null; \OxidEsales\Eshop\Core\Registry::getSession() // line 912 ->setVariable('aSorting', $sorting); Next, we analyze the attacker how to control the variables: in the SQL query statement structure is completed and sent to the database, the attacker can through the user input data to overwrite the$_SESSION[‘aSorting’]variable. This task by calling the _setSortingParameters()method to complete the method in the source code section 901 to obtain the user can control the sorting parameters, and then in 904 line calls setItemSorting()function, in this function call getSession()->setVariable()function of the 912 line, eventually the malicious user's input data is stored to the$_SESSION[‘aSorting’]variable.

[1] [2] next