zer0qs/cve-2021-35042Uma análise básica sobre CVE-2021-35942. Injeção de SQL no Django.
Django é um framework de aplicações web de código aberto, escrito em Python, construído seguindo o modelo MVC (Model - View - Controller). Inicialmente, foi criado para gerenciar sites de conteúdo de notícias pertencentes ao grupo editorial Lawrence, como um software CMS (Content Management System).
As versões 3.1.x -> 3.1.13 e 3.2.x -> 3.2.5 do Django apresentam uma vulnerabilidade de injeção de SQL.
A causa desta vulnerabilidade é que a função de filtragem de dados de entrada controlados pelo usuário em QuerySet.order_by() não é suficiente para prevenir ataques de injeção de SQL. Esta vulnerabilidade pode ser explorada para permitir que um atacante execute ações não autorizadas, levando ao vazamento de dados sensíveis.
| CVE - ID | CVE-2021-35042 |
|---|
| Severidade | 9.8 - CRÍTICA |
| CWE - ID | CWE-89: Neutralização Incorreta de Elementos Especiais usados em um Comando SQL ('Injeção de SQL') |
| Data de Publicação da Vulnerabilidade | 01/07/2021 |
| Software Afetado | 3.1.x < 3.1.13, 3.2.x < 3.2.5 |
| Requer Autenticação | Não requerido |
No Django, a criação de tabelas e a definição dos campos no banco de dados são feitas declarando uma classe de model no arquivo models.py. Neste exemplo, declaramos uma tabela chamada Wolf e um campo chamado name.
O framework ORM integrado no Django é usado para manipular o banco de dados, e o resultado da consulta é um conjunto, este conjunto é um QuerySet.
order_by(fields)
Por padrão, order_by() retorna um QuerySet ordenado de acordo com a ordem especificada na opção ordering no Meta do Model. Podemos sobrescrever a condição order_by em cada consulta usando o método order_by().
Exemplo
wolves = Wolf.objects.order_by('-name', 'id')
O resultado da consulta acima será ordenado em ordem decrescente pelo campo name e, em seguida, em ordem crescente por id. O sinal de menos antes do nome do campo name indica que o resultado é ordenado em ordem decrescente.
O exemplo a seguir ordena o resultado retornado pelo campo recebido do usuário; se nenhum valor for passado, ele ordena pelo campo
id.
Resultado
Nas versões 3.1 e 3.2, o Django permite combinar o método de consulta com o nome da tabela na consulta order_by. Esta é também a principal causa desta vulnerabilidade.
Passar um nome de tabela nos dá o mesmo resultado que passar um nome de campo normalmente
cve202135042_wolf é o nome da tabela
Primeiro, a aplicação chama diretamente a função order_by(); o trecho de código que processa a função order_by() está definido em:
django/db/models/query.py
A função order_by() faz duas coisas
- Remove todos os métodos atuais chamados por order_by() e remove o parâmetro padrão passado quando order_by recebe um valor diferente.
- Passa o parâmetro para order_by. A função
add_ordering()faz isso
def add_ordering(self, *ordering):
"""
Add items from the 'ordering' sequence to the query's "order by"
clause. These items are either field names (not column names) --
possibly with a direction prefix ('-' or '?') -- or OrderBy
expressions.
If 'ordering' is empty, clear all ordering from the query.
"""
errors = []
for item in ordering:
if isinstance(item, str):
if '.' in item:
warnings.warn(
'Passing column raw column aliases to order_by() is '
'deprecated. Wrap %r in a RawSQL expression before '
'passing it to order_by().' % item,
category=RemovedInDjango40Warning,
stacklevel=3,
)
continue
if item == '?':
continue
if item.startswith('-'):
item = item[1:]
if item in self.annotations:
continue
if self.extra and item in self.extra:
continue
# names_to_path() validates the lookup. A descriptive
# FieldError will be raise if it's not.
self.names_to_path(item.split(LOOKUP_SEP), self.model._meta)
elif not hasattr(item, 'resolve_expression'):
errors.append(item)
if getattr(item, 'contains_aggregate', False):
raise FieldError(
'Using an aggregate in order_by() without also including '
'it in annotate() is not allowed: %s' % item
)
if errors:
raise FieldError('Invalid order_by arguments: %s' % errors)
if ordering:
self.order_by += ordering
else:
self.default_ordering = False
O parâmetro passado para add_ordering() é um array.
Por exemplo, quando o parâmetro é passado da seguinte forma:
wolves = Wolf.objects.order_by( 'name' , 'id' )Nesse caso, a aplicação converterá isso na seguinte consulta SQL:
SELECT "cve202135042_wolf"."id", "cve202135042_wolf"."name" FROM "cve202135042_wolf" ORDER BY "cve202135042_wolf"."name" ASC, "cve202135042_wolf"."id" ASC
Quando passado, a função add_ordering verifica cada elemento do array; se for uma string, ela é verificada nos 5 casos a seguir:
if '.' in item:Verifica se é uma consulta com nome de coluna e se essa coluna tem um nome de tabela especificado na instrução SQL. Se sim, emite um aviso econtinue.if item == '?':Se o valor do elemento for o caractere '?', o resultado da saída será ordenado aleatoriamente,continue.if item.startswith('-'):Se o item começar com o caractere '-', o resultado da consulta será ordenado em DESC (decrescente).if item in self.annotations:Verifica se contém uma anotação; se sim,continue.if self.extra and item in self.extra:Determina se há extras e, se sim,continue.
Após as 5 verificações, o parâmetro é passado para a função self.names_to_path(item.split(LOOKUP_SEP), self.model._meta) para verificar se é um nome de coluna válido; em seguida, se for válido, é adicionado a self.ordering da classe Query para processamento posterior.
O ORM do Django filtra os dados inseridos na consulta de forma muito rigorosa, mas esta mudança no código-fonte que leva à injeção de SQL ocorreu porque o autor levantou a hipótese de que, se o nome da coluna fosse uma coluna UUID (Universal Unique Identifier), a consulta order_by não poderia ser executada.
Ou seja, se os dados passados fossem xxx-xxx-xxx-xxx (formato UUID), a consulta não poderia ser executada.
Trecho de código antes da mudança
# django/db/models/sql/constants.py
ORDER_PATTERN = _lazy_re_compile ( r '\?|[-+]?[.\w]+$' )
# django/db/models/sql/query.py
def add_ordering ( self , * ordering ):
errors = []
for item in ordering :
if isinstance ( item , str ) and ORDER_PATTERN . match ( item ):
if '.' in item :
warnings . warn (
'Passing column raw column aliases to order_by() is '
'deprecated. Wrap %r in a RawSQL expression before '
'passing it to order_by().' % item ,
category = RemovedInDjango40Warning ,
stacklevel = 3 ,
)
elif not hasattr ( item , 'resolve_expression' ):
errors . append ( item )
if getattr ( item , 'contains_aggregate' , False ):
raise FieldError (
'Using an aggregate in order_by() without also including '
'it in annotate() is not allowed: %s ' % item
)
if errors :
raise FieldError ( 'Invalid order_by arguments: %s ' % errors )
if ordering :
self . order_by += ordering
else :
self . default_ordering = False
No trecho de código acima, podemos ver que, se o parâmetro corresponder a ? ou começar com - seguido de caracteres comuns ou um ponto ., a consulta é executada.
Portanto, quando o nome da coluna é um UUID, ele é um valor inválido e não pode ser passado para order_by.
A mudança no código desta parte do processamento foi aceita e foi alterada da seguinte forma:
https://github.com/charettes/django/commit/513948735b799239f3ef8c89397592445e1a0cd5
Ela passou a usar a função self.name_to_path para validar os dados de entrada.
Mas, após verificar se . está no item, ela o trata como uma consulta com nome de tabela, e o comando continue é executado, ignorando diretamente o uso da função self.name_to_path para verificar a validade dos dados.
O trecho de código que processa o ponto . na função get_order_by é o seguinte:
django/db/models/sql/compiler.py
if '.' in field :
table , col = col . split ( '.' , 1 )
order_by . append ((
OrderBy (
RawSQL ( ' %s . %s ' % (
self . quote_name_unless_alias ( table ), col ), [ ]),
descending = descending
), False ))
continue
A função self.quote_name_unless_alias processa o nome da tabela, filtra nomes de tabela válidos e ignora a filtragem do nome da coluna; portanto, podemos inserir uma instrução de injeção de SQL.
Na versão atual do Django 4.0, a consulta por nome de tabela usando o ponto . foi removida e não é mais suportada; o patch foi lançado para as versões 3.1 e 3.2. As versões 3.2 -> 3.2.4 e 3.1 -> 3.1.12 são afetadas.
3.2.x Fixed CVE-2021-35042 -- Prevented SQL injection in QuerySet.o…
A correção é muito simples: a verificação de dados com a antiga ReGex foi restaurada.
Atualize o Django para uma versão não afetada.
Docker & Docker-compose
git clone https://github.com/WynSon/CVE-2021-35042.git./setup.sh para a configuração inicialsudo docker-compose up --buildsudo docker exec -it cve-2021-35042_web_1 python manage.py makemigrations cve202135042sudo docker exec -it cve-2021-35042_web_1 python manage.py migratehttp://localhost:8000/wolves/?order_by=nameTela após a instalação concluída
Condição: Para explorar, precisamos saber o nome da tabela de alguma forma :))
Ao injetar a instrução, precisamos saber o nome da tabela para poder executar a instrução SQLi.
Ao inserir um nome de tabela incorreto
Ao inserir o nome de tabela correto, a consulta orderby é executada normalmente.
A instrução neste momento será
SELECT "cve202135042_wolf"."id", "cve202135042_wolf"."name" FROM "cve202135042_wolf" ORDER BY ("cve202135042_wolf"."name") ASC
Neste momento, podemos encerrar a instrução order_by anterior e inserir uma instrução SQL para explorar.
SELECT "cve202135042_wolf"."id", "cve202135042_wolf"."name" FROM "cve202135042_wolf" ORDER BY ("cve202135042_wolf"."name"); SELECT * from cve202135042_wolf where id =1; --) ASC