Amelia 是一個由 TMS 公司所開發的 WordPress 外掛，能夠輕鬆幫你的 WordPress 網站加上預約系統的功能，例如說診所、理髮廳或是家教等等，都很適合使用這個外掛來架一個簡單的預約系統。根據 WordPress 官方的統計，大約有 40,000 個網站都安裝了這個 plugin。
在三月初的時候我針對 Amelia 這套系統的原始碼做了一些研究，找到了三個都是敏感資訊洩露的漏洞：
CVE-2022-0720Amelia < 1.0.47 - Customer+ Arbitrary Appointments Update and Sensitive Data Disclosure (CVSS 6.3)CVE-2022-0825Amelia < 1.0.49 - Customer+ Arbitrary Appointments Status Update (CVSS 6.3)CVE-2022-0837Amelia < 1.0.48 - Customer+ SMS Service Abuse and Sensitive Data Disclosure (CVSS 5.4)
如果被攻擊者利用這些漏洞，可以取得所有消費者的資料，包括姓名、電話以及預約資訊。
底下我會簡單介紹一下 Amelia 的架構以及這三個漏洞的細節。
# Amelia 基本介紹
安裝好 Amelia 以後，你可以新增一個預約頁面，大概是長這樣：
在預約時需要提供一些基本資料，例如說姓名以及 email 等等，輸入後即可完成預約：
完成預約以後，Amelia 會幫你在 WordPress 系統裡面新增一個低權限的帳號，並且把重設密碼的連結寄到剛剛提供的信箱。帳號開通以後，就可以登入 WordPress 管理剛剛的預約：
使用方式介紹完以後，我們來看一下更技術的部分。
# WordPress 外掛與 Amelia 架構介紹
WordPress 的外掛有很多，每一個的寫法都不太一樣，但因為是外掛，所以會呼叫 WordPress 提供的函式來註冊事件。
add_action 這個函式就扮演著很重要的角色，你可以幫特定的 action 加上一個 hook，當這個 action 被觸發時，就會呼叫到你提供的函式。
其中由 wp_ajax_nopriv_ 開頭的 action，可以透過 wp-admin/admin-ajax.php 來呼叫，相關程式碼節錄如下（admin-ajax.php）：
<?php
$action = $_REQUEST['action'];
if ( is_user_logged_in() ) {
// If no action is registered, return a Bad Request response.
if ( ! has_action( "wp_ajax_{$action}" ) ) {
wp_die( '0', 400 );
}
/**
* Fires authenticated Ajax actions for logged-in users.
*
* The dynamic portion of the hook name, `$action`, refers
* to the name of the Ajax action callback being fired.
*
* @since 2.1.0
*/
do_action( "wp_ajax_{$action}" );
} else {
// If no action is registered, return a Bad Request response.
if ( ! has_action( "wp_ajax_nopriv_{$action}" ) ) {
wp_die( '0', 400 );
}
/**
* Fires non-authenticated Ajax actions for logged-out users.
*
* The dynamic portion of the hook name, `$action`, refers
* to the name of the Ajax action callback being fired.
*
* @since 2.8.0
*/
do_action( "wp_ajax_nopriv_{$action}" );
}
?>以 Amelia 來說，在 ameliabooking.php 中註冊了兩個 hook：
/** Isolate API calls */
add_action('wp_ajax_wpamelia_api', array('AmeliaBooking\Plugin', 'wpAmeliaApiCall'));
add_action('wp_ajax_nopriv_wpamelia_api', array('AmeliaBooking\Plugin', 'wpAmeliaApiCall'));有 nopriv 的代表沒有權限（未登入）也可以呼叫，沒有的代表需要登入 WordPress 系統才能呼叫，而許多的 plugin 會選擇自己處理身份驗證相關的邏輯，所以會把兩個動作都導到同一個地方。
而 wpAmeliaApiCall 這個函式則是註冊了 routes：
/**
* API Call
*
* @throws \InvalidArgumentException
*/
public static function wpAmeliaApiCall()
{
try {
/** @var Container $container */
$container = require AMELIA_PATH . '/src/Infrastructure/ContainerConfig/container.php';
$app = new App($container);
// Initialize all API routes
Routes::routes($app);
$app->run();
exit();
} catch (Exception $e) {
echo 'ERROR: ' . $e->getMessage();
}
}在 src/Infrastructure/Routes 底下有許多的資料夾跟檔案，裡面負責處理不同的路由，舉例來說，User 相關的路由在 src/Infrastructure/Routes/User/User.php，相關程式碼節錄如下：
/**
* Class User
*
* @package AmeliaBooking\Infrastructure\Routes\User
*/
class User
{
/**
* @param App $app
*/
public static function routes(App $app)
{
$app->get('/users/wp-users', GetWPUsersController::class);
$app->post('/users/authenticate', LoginCabinetController::class);
$app->post('/users/logout', LogoutCabinetController::class);
// Customers
$app->get('/users/customers/{id:[0-9]+}', GetCustomerController::class);
$app->get('/users/customers', GetCustomersController::class);
$app->post('/users/customers', AddCustomerController::class);
$app->post('/users/customers/{id:[0-9]+}', UpdateCustomerController::class);
$app->post('/users/customers/delete/{id:[0-9]+}', DeleteUserController::class);
$app->get('/users/customers/effect/{id:[0-9]+}', GetUserDeleteEffectController::class);
$app->post('/users/customers/reauthorize', ReauthorizeController::class);
// Providers
$app->get('/users/providers/{id:[0-9]+}', GetProviderController::class);
$app->get('/users/providers', GetProvidersController::class);
$app->post('/users/providers', AddProviderController::class);
$app->post('/users/providers/{id:[0-9]+}', UpdateProviderController::class);
$app->post('/users/providers/status/{id:[0-9]+}', UpdateProviderStatusController::class);
$app->post('/users/providers/delete/{id:[0-9]+}', DeleteUserController::class);
$app->get('/users/providers/effect/{id:[0-9]+}', GetUserDeleteEffectController::class);
// Current User
$app->get('/users/current', GetCurrentUserController::class);
}
}那實際上到底要怎麼呼叫到這些路由呢？在 src/Infrastructure/ContainerConfig/request.php 中，針對 request 的 query string 做了一些轉換：
<?php
use Slim\Http\Request;
use Slim\Http\Uri;
$entries['request'] = function (AmeliaBooking\Infrastructure\Common\Container $c) {
$curUri = Uri::createFromEnvironment($c->get('environment'));
// 附註：AMELIA_ACTION_SLUG = "action=wpamelia_api&call="
$newRoute = str_replace(
['XDEBUG_SESSION_START=PHPSTORM&' . AMELIA_ACTION_SLUG, AMELIA_ACTION_SLUG],
'',
$curUri->getQuery()
);
$newPath = strpos($newRoute, '&') ? substr(
$newRoute,
0,
strpos($newRoute, '&')
) : $newRoute;
$newQuery = strpos($newRoute, '&') ? substr(
$newRoute,
strpos($newRoute, '&') + 1
) : '';
$request = Request::createFromEnvironment($c->get('environment'))
->withUri(
$curUri
->withPath($newPath)
->withQuery($newQuery)
);
if (method_exists($request, 'getParam') && $request->getParam('showAmeliaErrors')) {
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
}
return $request;
};簡單來說呢，當你的 request URL 長這樣的時候：/wordpress/wp-admin/admin-ajax.php?action=wpamelia_api&call=/users/wp-users，query string 就是 action=wpamelia_api&call=/users/wp-users，符合 AMELIA_ACTION_SLUG 的地方被換成空白之後，就變成了 /users/wp-users，就對應到了上面的檔案看到的路由，重新交由 Slim 這個 PHP 框架去處理。
而 /users/wp-users 對應到的是 GetWPUsersController::class，讓我們來看一下 controller 的程式碼：
<?php
namespace AmeliaBooking\Application\Controller\User;
use AmeliaBooking\Application\Commands\User\GetWPUsersCommand;
use AmeliaBooking\Application\Controller\Controller;
use Slim\Http\Request;
/**
* Class GetWPUsersController
*
* @package AmeliaBooking\Application\Controller\User
*/
class GetWPUsersController extends Controller
{
/**
* Instantiates the Get WP Users command to hand it over to the Command Handler
*
* @param Request $request
* @param $args
*
* @return GetWPUsersCommand
* @throws \RuntimeException
*/
protected function instantiateCommand(Request $request, $args)
{
$command = new GetWPUsersCommand($args);
$command->setField('id', (int)$request->getQueryParam('id'));
$command->setField('role', $request->getQueryParam('role'));
$requestBody = $request->getParsedBody();
$this->setCommandFields($command, $requestBody);
return $command;
}
}這邊使用了設計模式中的 Command Pattern，把每一個動作都包裝成一個指令，那這個指令會被誰處理呢？每一個 controller 都繼承了 AmeliaBooking\Application\Controller\Controller，所以處理的程式碼就在裡面：
/**
* @param Request $request
* @param Response $response
* @param $args
*
* @return Response
* @throws \InvalidArgumentException
* @throws \RuntimeException
*/
public function __invoke(Request $request, Response $response, $args)
{
/** @var Command $command */
$command = $this->instantiateCommand($request, $args);
if (!wp_verify_nonce($command->getField('ameliaNonce'), 'ajax-nonce') &&
(
$command instanceof DeleteUserCommand ||
$command instanceof DeletePackageCommand ||
$command instanceof DeleteCategoryCommand ||
$command instanceof DeleteServiceCommand ||
$command instanceof DeleteExtraCommand ||
$command instanceof DeleteLocationCommand ||
$command instanceof DeleteEventCommand ||
$command instanceof DeletePaymentCommand ||
$command instanceof DeleteCouponCommand ||
$command instanceof DeleteCustomFieldCommand ||
$command instanceof DeleteAppointmentCommand ||
$command instanceof DeleteBookingCommand ||
$command instanceof DeleteEventBookingCommand ||
$command instanceof DeletePackageCustomerCommand ||
$command instanceof DeleteNotificationCommand
)
) {
return $response->withStatus(self::STATUS_INTERNAL_SERVER_ERROR);
}
/** @var CommandResult $commandResult */
$commandResult = $this->commandBus->handle($command);
if ($commandResult->getUrl() !== null) {
$this->emitSuccessEvent($this->eventBus, $commandResult);
/** @var Response $response */
$response = $response->withHeader('Location', $commandResult->getUrl());
$response = $response->withStatus(self::STATUS_REDIRECT);
return $response;
}
if ($commandResult->hasAttachment() === false) {
$responseBody = [
'message' => $commandResult->getMessage(),
'data' => $commandResult->getData()
];
$this->emitSuccessEvent($this->eventBus, $commandResult);
switch ($commandResult->getResult()) {
case (CommandResult::RESULT_SUCCESS):
$response = $response->withStatus(self::STATUS_OK);
break;
case (CommandResult::RESULT_CONFLICT):
$response = $response->withStatus(self::STATUS_CONFLICT);
break;
default:
$response = $response->withStatus(self::STATUS_INTERNAL_SERVER_ERROR);
break;
}
/** @var Response $response */
$response = $response->withHeader('Content-Type', 'application/json;charset=utf-8');
$response = $response->write(
json_encode(
$commandResult->hasDataInResponse() ?
$responseBody : array_merge($responseBody, ['data' => []])
)
);
}
return $response;
}這邊先實例化一個指令之後，再丟到 commandBus 去做處理：$this->commandBus->handle($command)，程式碼在 src/Infrastructure/ContainerConfig/command.bus.php，節錄部分：
<?php
defined('ABSPATH') or die('No script kiddies please!');
// @codingStandardsIgnoreStart
$entries['command.bus'] = function ($c) {
$commands = [
// User
User\DeleteUserCommand::class => new User\DeleteUserCommandHandler($c),
User\GetCurrentUserCommand::class => new User\GetCurrentUserCommandHandler($c),
User\GetUserDeleteEffectCommand::class => new User\GetUserDeleteEffectCommandHandler($c),
User\GetWPUsersCommand::class => new User\GetWPUsersCommandHandler($c),
// more commands...
];
return League\Tactician\Setup\QuickStart::create($commands);
};
// @codingStandardsIgnoreEnd
從中可以看出我們的 GetWPUsersCommand 會被 User\GetWPUsersCommandHandler 處理，所以主要的邏輯就在這裡面：
class GetWPUsersCommandHandler extends CommandHandler
{
/**
* @param GetWPUsersCommand $command
*
* @return CommandResult
* @throws AccessDeniedException
* @throws InvalidArgumentException
* @throws \AmeliaBooking\Infrastructure\Common\Exceptions\QueryExecutionException
* @throws \Interop\Container\Exception\ContainerException
*/
public function handle(GetWPUsersCommand $command)
{
if (!$this->getContainer()->getPermissionsService()->currentUserCanRead(Entities::EMPLOYEES)) {
throw new AccessDeniedException('You are not allowed to read employees.');
}
if (!$this->getContainer()->getPermissionsService()->currentUserCanRead(Entities::CUSTOMERS)) {
throw new AccessDeniedException('You are not allowed to read customers.');
}
$result = new CommandResult();
$this->checkMandatoryFields($command);
/** @var UserService $userService */
$userService = $this->container->get('users.service');
$adminIds = $userService->getWpUserIdsByRoles(['administrator']);
/** @var WPUserRepository $wpUserRepository */
$wpUserRepository = $this->getContainer()->get('domain.wpUsers.repository');
$result->setResult(CommandResult::RESULT_SUCCESS);
$result->setMessage('Successfully retrieved users.');
$result->setData([
Entities::USER . 's' => $wpUserRepository->getAllNonRelatedWPUsers($command->getFields(), $adminIds)
]);
return $result;
}
}可以看到業務邏輯都在 handle 這個函式裡面，裡面先檢查了權限，接著透過 userService 抓取相關資料，再來用 $result->setData 設置要回傳的資料，最後回傳結果，交給其他 infra 相關程式碼處理。
另外，在 controller 中可以看到 command 相關的權限檢查：
if (!wp_verify_nonce($command->getField('ameliaNonce'), 'ajax-nonce') &&
(
$command instanceof DeleteUserCommand ||
$command instanceof DeletePackageCommand ||
$command instanceof DeleteCategoryCommand ||
$command instanceof DeleteServiceCommand ||
$command instanceof DeleteExtraCommand ||
$command instanceof DeleteLocationCommand ||
$command instanceof DeleteEventCommand ||
$command instanceof DeletePaymentCommand ||
$command instanceof DeleteCouponCommand ||
$command instanceof DeleteCustomFieldCommand ||
$command instanceof DeleteAppointmentCommand ||
$command instanceof DeleteBookingCommand ||
$command instanceof DeleteEventBookingCommand ||
$command instanceof DeletePackageCustomerCommand ||
$command instanceof DeleteNotificationCommand
)
) {
return $response->withStatus(self::STATUS_INTERNAL_SERVER_ERROR);
}如果是這些 delete 的指令，就需要通過 wp_verify_nonce 的檢查，這是什麼東西呢？
wp_verify_nonce 是 WordPress 提供用於安全性檢查的函式，對應的函式是 wp_create_nonce，在 WordPress 後台管理頁面有這樣一行程式碼：var wpAmeliaNonce = '<?php echo wp_create_nonce('ajax-nonce'); ?>';，會產生一個名稱為 ajax-nonce 的 nonce，而這個 nonce 其實就是把一些字串 hash 過後的結果。
如果你拿不到 hash 時用的 salt，基本上不可能偽造出 nonce，因為 salt 預設都非常長，而且都是安裝時隨機產生的：
define('AUTH_KEY', ' Xakm<o xQy rw4EMsLKM-?!T+,PFF})H4lzcW57AF0U@N@< >M%G4Yt>f`z]MON');
define('SECURE_AUTH_KEY', 'LzJ}op]mr|6+![P}Ak:uNdJCJZd>(Hx.-Mh#Tz)pCIU#uGEnfFz|f ;;eU%/U^O~');
define('LOGGED_IN_KEY', '|i|Ux`9<p-h$aFf(qnT:sDO:D1P^wZ$$/Ra@miTJi9G;ddp_<q}6H1)o|a +&JCM');
define('NONCE_KEY', '%:R{[P|,s.KuMltH5}cI;/k<Gx~j!f0I)m_sIyu+&NJZ)-iO>z7X>QYR0Z_XnZ@|');
define('AUTH_SALT', 'eZyT)-Naw]F8CwA*VaW#q*|.)g@o}||wf~@C-YSt}(dh_r6EbI#A,y|nU2{B#JBW');
define('SECURE_AUTH_SALT', '!=oLUTXh,QW=H `}`L|9/^4-3 STz},T(w}W<I`.JjPi)<Bmf1v,HpGe}T1:Xt7n');
define('LOGGED_IN_SALT', '+XSqHc;@Q*K_b|Z?NC[3H!!EONbh.n<+=uKR:>*c(u`g~EJBf#8u#R{mUEZrozmm');
define('NONCE_SALT', 'h`GXHhD>SLWVfg1(1(N{;.V!MoE(SfbA_ksP@&`+AycHcAV$+?@3q+rxV{%^VyKT');因此，透過 wp_verify_nonce，我們可以確保只有已登入的使用者能使用到某些功能，因為沒登入的話拿不到 nonce。
以上就是 Amelia 的基本架構跟處理流程，是我看過的幾個 plugin 中最為漂亮的一個，東西都整理得很好，架構也切得不錯，不會出現一堆雜七雜八的程式碼，要找東西也很好找，只要去 routes 看一下網址跟對應的 controller，循線找到 command 跟 command handler 即可。
接著，就來談談開頭提到的那三個漏洞。
# CVE-2022-0720: Amelia < 1.0.47 - Customer+ Arbitrary Appointments Update and Sensitive Data Disclosure
管理訂房相關的模組有兩個，一個叫做 Appointment，另一個叫做 Booking，他們是一對多的關係，一個 Appointment 底下可以對應到多個 Booking，相關路由如下：
src/Infrastructure/Routes/Booking/Appointment/Appointment.php
class Appointment
{
/**
* @param App $app
*
* @throws \InvalidArgumentException
*/
public static function routes(App $app)
{
$app->get('/appointments', GetAppointmentsController::class);
$app->get('/appointments/{id:[0-9]+}', GetAppointmentController::class);
$app->post('/appointments', AddAppointmentController::class);
$app->post('/appointments/delete/{id:[0-9]+}', DeleteAppointmentController::class);
$app->post('/appointments/{id:[0-9]+}', UpdateAppointmentController::class);
$app->post('/appointments/status/{id:[0-9]+}', UpdateAppointmentStatusController::class);
$app->post('/appointments/time/{id:[0-9]+}', UpdateAppointmentTimeController::class);
}
}以顯示 appointment 的路由 /appointments/{id:[0-9]+} 為例，對應到 GetAppointmentController，在 controller 中會去呼叫 GetAppointmentCommandHandler，裡面有段程式碼是這樣的：
$customerAS->removeBookingsForOtherCustomers($user, new Collection([$appointment]));在回傳資料前，會把不屬於自己的 booking 全部都過濾掉，所以看不到其他人的資料，有做好權限管理。
而更新 appointment 的路由對應到的 controller 是 UpdateAppointmentController，又對應到了 UpdateAppointmentCommandHandler.php，部分程式碼如下：
try {
/** @var AbstractUser $user */
$user = $userAS->authorization(
$command->getPage() === 'cabinet' ? $command->getToken() : null,
$command->getCabinetType()
);
} catch (AuthorizationException $e) {
$result->setResult(CommandResult::RESULT_ERROR);
$result->setData(
[
'reauthorize' => true
]
);
return $result;
}
if ($userAS->isProvider($user) && !$settingsDS->getSetting('roles', 'allowWriteAppointments')) {
throw new AccessDeniedException('You are not allowed to update appointment');
}
// update appointment開頭有檢查了兩樣東西，第一樣是使用者是否登入，所以儘管沒有 nonce 也可以進來這個路由，在這邊還是會被擋下來。第二樣則是使用者的身份，如果是 provider 才會檢查有沒有權限。
在 Amelia 中基本上有幾個角色，消費者（Customer)、服務提供者（Provider）以及管理員（Admin），所以只要我們不是 provider，就可以通過這邊的檢查。
開頭有提過只要透過 Amelia 的外掛隨便預約一個服務，就可以在 WordPress 的系統中註冊一個 customer 的帳號，這組帳號可以登入 WordPress，來管理自己之前的預約。
因此，這邊的權限檢查是有漏洞的，一個 customer 身份的使用者可以通過這邊的檢查，去竄改其他人的預約。雖然看起來好像很普通，但其實使用者在前台修改自己的預約時，用的是另外一個 /bookings/{id} 的 API，這個 appointment 的 API 我猜預設是給 provider 使用的，所以才沒考慮到 customer 的狀況。
那除了修改 booking 以外，還可以幹嘛呢？我們來看一下更新完的 response：
我們可以看到 response 中有個 info 欄位，裡面有原本消費者的個人資料，包括姓名以及電話等等，這個欄位是在 src/Application/Services/Reservation/AbstractReservationService.php 中的 processBooking 時儲存的：
$appointmentData['bookings'][0]['info'] = json_encode(
[
'firstName' => $appointmentData['bookings'][0]['customer']['firstName'],
'lastName' => $appointmentData['bookings'][0]['customer']['lastName'],
'phone' => $appointmentData['bookings'][0]['customer']['phone'],
'locale' => $appointmentData['locale'],
'timeZone' => $appointmentData['timeZone'],
'urlParams' => !empty($appointmentData['urlParams']) ? $appointmentData['urlParams'] : null,
]
);總結一下，因為權限檢查沒做好，所以 customer 可以更新其他人的預約，並且看到消費者的個人資料，而 appointment 的 ID 是流水號，所以直接列舉一下，就可以把系統中所有人的個資都撈出來。
# 修復方式
在 1.0.47 版中，有做出了兩個變動，第一個是針對我回報的問題，加上了對於 customer 的權限檢查：
if ($userAS->isCustomer($user)) {
throw new AccessDeniedException('You are not allowed to update appointment');
}第二個改動則是 routes 的權限檢查，從負面表列變成正面表列，只有幾個特定的 command 不需登入：
public function validateNonce($request)
{
if ($request->getMethod() === 'POST' &&
!self::getToken() &&
!($this instanceof LoginCabinetCommand) &&
!($this instanceof AddBookingCommand) &&
!($this instanceof AddStatsCommand) &&
!($this instanceof MolliePaymentCommand) &&
!($this instanceof MolliePaymentNotifyCommand) &&
!($this instanceof PayPalPaymentCommand) &&
!($this instanceof PayPalPaymentCallbackCommand) &&
!($this instanceof RazorpayPaymentCommand) &&
!($this instanceof WooCommercePaymentCommand) &&
!($this instanceof SuccessfulBookingCommand)
) {
return wp_verify_nonce($request->getQueryParams()['ameliaNonce'], 'ajax-nonce');
}
return true;
}# CVE-2022-0825: Amelia < 1.0.49 - Customer+ Arbitrary Appointments Status Update
這個漏洞跟上一個類似，都是屬於權限管理的問題，而這個漏洞的路由是 $app->post('/appointments/status/{id:[0-9]+}', UpdateAppointmentStatusController::class);，對應到的程式碼在 src/Application/Commands/Booking/Appointment/UpdateAppointmentStatusCommandHandler.php，開頭有先做權限檢查：
if (!$this->getContainer()->getPermissionsService()->currentUserCanWriteStatus(Entities::APPOINTMENTS)) {
throw new AccessDeniedException('You are not allowed to update appointment status');
}
// update appointment我們繼續往下追，去看看 currentUserCanWriteStatus 是怎麼實作的：
public function currentUserCanWriteStatus($object)
{
return $this->userCan($this->currentUser, $object, self::WRITE_STATUS_PERMISSIONS);
}再往下追，找到 userCan：
public function userCan($user, $object, $permission)
{
if ($user instanceof Admin) {
return true;
}
return $this->permissionsChecker->checkPermissions($user, $object, $permission);
}再往下一層，在 src/Infrastructure/WP/PermissionsService/PermissionsChecker.php 中可以看到 checkPermissions 的實作：
public function checkPermissions($user, $object, $permission)
{
// Admin can do all
if ($user instanceof Admin) {
return true;
}
// Get the WP role name of the user, rollback to customer by default
$wpRoleName = $user !== null ? 'wpamelia-' . $user->getType() : 'wpamelia-customer';
// Get the wp name of capability we are looking for.
$wpCapability = "amelia_{$permission}_{$object}";
if ($user !== null && $user->getExternalId() !== null) {
return user_can($user->getExternalId()->getValue(), $wpCapability);
}
// If user is guest check does it have capability
$wpRole = get_role($wpRoleName);
return $wpRole !== null && isset($wpRole->capabilities[$wpCapability]) ?
(bool)$wpRole->capabilities[$wpCapability] : false;
}這邊有個值得注意的地方，就是如果 user 是 null 的話，會被當成 customer 來看待，而實際檢查有沒有權限要看 capabilities 這個 table，在 src/Infrastructure/WP/config/Roles.php：
// Customer
[
'name' => 'wpamelia-customer',
'label' => __('Amelia Customer', 'amelia'),
'capabilities' => [
'read' => true,
'amelia_read_menu' => true,
'amelia_read_calendar' => true,
'amelia_read_appointments' => true,
'amelia_read_events' => true,
'amelia_write_status_appointments' => true,
'amelia_write_time_appointments' => true,
]
],其中 amelia_write_status_appointments 是 true，代表 customer 有權限更新狀態。
剩下的部分就跟上一個漏洞一樣了，更新 appointment 之後資料會整包回傳，透過 info 這個欄位可以看到消費者的個人資料。另外，這個漏洞在 1.0.47 以前會是 pre-auth 的，因為 1.0.47 以前 routes 的權限檢查還沒變成正面表列，所以沒登入也可以存取到這個指令，再加上 user 是 null 的話預設是消費者身份，完成了整條攻擊鏈的串接：
# 修復方式
在 1.0.49 版中，移除了 customer 的 amelia_write_status_appointments 這個權限。
# CVE-2022-0837: Amelia < 1.0.48 - Customer+ SMS Service Abuse and Sensitive Data Disclosure
來看最後一個權限檢查相關漏洞，出問題的路由是 $app->post('/notifications/sms', SendAmeliaSmsApiRequestController::class);，對應到的是 SendAmeliaSmsApiRequestCommandHandler：
public function handle(SendAmeliaSmsApiRequestCommand $command)
{
$result = new CommandResult();
/** @var SMSAPIServiceInterface $smsApiService */
$smsApiService = $this->getContainer()->get('application.smsApi.service');
// Call method dynamically and pass data to the function. Method name is the request field.
$apiResponse = $smsApiService->{$command->getField('action')}($command->getField('data'));
$result->setResult(CommandResult::RESULT_SUCCESS);
$result->setMessage('Amelia SMS API request successful');
$result->setData($apiResponse);
return $result;
}可以看到這邊沒有做任何的權限檢查，而我們可以控制傳到這邊的參數：
$apiResponse = $smsApiService->{$command->getField('action')}($command->getField('data'));在 smsApiService 中有不少方法，而其中只有一個參數的包括可以拿到管理員個人資訊的 getUserInfo，可以拿到付款紀錄的 getPaymentHistory，以及可以發送測試簡訊的 testNotification：
public function getUserInfo()
{
$route = 'auth/info';
return $this->sendRequest($route, true);
}
public function getPaymentHistory($data)
{
$route = '/payment/history';
return $this->sendRequest($route, true, $data);
}
public function testNotification($data)
{
$route = '/sms/send';
/** @var SettingsService $settingsService */
$settingsService = $this->container->get('domain.settings.service');
/** @var EmailNotificationService $notificationService */
$notificationService = $this->container->get('application.emailNotification.service');
/** @var PlaceholderService $placeholderService */
$placeholderService = $this->container->get("application.placeholder.{$data['type']}.service");
$appointmentsSettings = $settingsService->getCategorySettings('appointments');
$notification = $notificationService->getById($data['notificationTemplate']);
$dummyData = $placeholderService->getPlaceholdersDummyData('sms');
$isForCustomer = $notification->getSendTo()->getValue() === NotificationSendTo::CUSTOMER;
$placeholderStringRec = 'recurring' . 'Placeholders' . ($isForCustomer ? 'Customer' : '') . 'Sms';
$placeholderStringPack = 'package' . 'Placeholders' . ($isForCustomer ? 'Customer' : '') . 'Sms';
$dummyData['recurring_appointments_details'] = $placeholderService->applyPlaceholders($appointmentsSettings[$placeholderStringRec], $dummyData);
$dummyData['package_appointments_details'] = $placeholderService->applyPlaceholders($appointmentsSettings[$placeholderStringPack], $dummyData);
$body = $placeholderService->applyPlaceholders(
$notification->getContent()->getValue(),
$dummyData
);
$data = [
'to' => $data['recipientPhone'],
'from' => $settingsService->getSetting('notifications', 'smsAlphaSenderId'),
'body' => $body
];
return $this->sendRequest($route, true, $data);
}實際測試截圖：
發送測試簡訊：
發送測試簡訊也是要扣錢的，我們只要一直打這個 endpoint，就會一直發送測試簡訊然後一直扣款，可以利用這個漏洞把管理員的錢燒光。
# 修復方式
在 1.0.48 版中，於 controller 內加上了權限檢查：
if (!$this->getContainer()->getPermissionsService()->currentUserCanWrite(Entities::NOTIFICATIONS)) {
throw new AccessDeniedException('You are not allowed to send test email');
}# 總結
當開發的軟體變得愈來愈複雜，開發者往往容易忽略一些基本的權限檢查，以及對於權限有著錯誤的假設。舉例來說，雖然 appointment 相關的 API 是給 provider 用的，前端的消費者看不到這些 API，但是 WordPress 外掛的程式碼都是開放的，任何人只要看了程式碼，都能找出所有的 API 路徑。
在實作各種功能時，要記得把權限檢查放在第一位，確認當前的使用者對於欲操作的資源有權限以後，才繼續後面的流程。
最後附上時間軸：
2022-02-20 透過 WPScan 回報更新預約漏洞，保留 CVE-2022-07202022-03-01 發布 1.0.47 版，修復 CVE-2022-0720，部分資訊公開於 WPScan2022-03-02 透過 WPScan 回報更新預約狀態漏洞，保留 CVE-2022-08252022-03-03 透過 WPScan 回報 SMS 相關漏洞，保留 CVE-2022-08372022-03-09 發布 1.0.48 版，修復 CVE-2022-0837，部分資訊公開於 WPScan2022-03-14 發布 1.0.49 版，修復 CVE-2022-0825，部分資訊公開於 WPScan2022-03-26 漏洞細節公開於 WPScan2022-03-30 文章發佈
Share this postTag
Recommendation
Discussion(login required)