Secops - User Agents e o user agent spoofing (PT-BR)

User Agents... agentes, mas não tão usuários.

 (EN-US) Veja os testes realizados neste post no vídeo.

Uma das informações disponíveis em registros de servidores web e registros de aplicativos do servidor web é o Agente do Usuário. 

O user agent é o software responsável pelo envio das requisições web do cliente para o servidor web.  Esta informação que diz ao servidor qual software o usuário (ou não) está usando para acessar a página da Web. Esta informação é visualizada no log de acesso do servidor, quando configurado. Aqui um simples nome de agente de usuário:

"Mozilla/5.0 (X11; x86_64 Linux; rv:60.0) Gecko/201001 Firefox/60.0"

As informações do user agent são encontradas nos registros do servidor web. Normalmente, todos os logs do servidor web terão o agente do usuário configurado. E este é um exemplo de um registro de log básico do servidor web com o user agent.

10.1.0.10 - [20/Jul/2018:13:38:10-0500] "GET /animatedcollapse.js HTTP/1.1" 304 - "http://10.2.0.101/" "Mozilla/5.0 (X11; x86_64 Linux; rv:60.0) Gecko/201001 Firefox/60.0"  (Obtenha mais informações sobre registros do servidor web  aqui).

Então,  qual é o problema dos agentes de usuário? Nenhum. Eles funcionam e são úteis na análise de log. A questão é que eles podem ser alterados ou criados durante a solicitação ao servidor web. Há muitas maneiras de fazer isso. Alterar o user agent real por outro é conhecido como "user agent spoofing". Esta é uma forma comum de evitar as regras de bloqueio básicas durante ataques.

Aqui eu vou mostrar uma  maneira  fácil de fazê-lo para comprovar esta teoria. Esta forma usa comando Linux wget. Neste exemplo, o nosso Linux tem o IP: 10.1.0.10 e o servidor web tem o IP: 10.2.0.110.

A primeira requisição usando o wget:

$wget 10.2.0.110

O servidor web irá mostrar este registro de log, destacado o user agent:

10.1.0.10 - [18/Jul/2020:10:28:07 -0400] "GET / HTTP/1.1" 200 28067 "-" "Wget/1.20.3 (linux-gnu)"

Vamos forçar o agente do usuário a mudar. Nosso user agent será: i’m a firefox browser (eu sou um navegador firefox – em tradução livre). Verifique o comando e os registros do servidor web abaixo:

$wget -U "eu sou um navegador firefox" 10.2.0.110

10.1.0.10 - [18/Jul/2020:10:28:34 -0400] "GET / HTTP/1.1" 200 28067 "-"i'm a firefox browser"

No próximo cenário usaremos um user agent comum nos navegadores Firefox. Você pode encontrar uma boa lista de user agents aqui.

$wget -U "Mozilla/5.0 (X11; x86_64 Linux; rv:68.0) Gecko/20100101 Firefox/68.0" 10.2.0.110

10.1.0.10 - [18/Jul/2020:10:29:39 -0400] "GET /favicon.ico HTTP/1.1" 200 3638 "-"Mozilla/5.0 (X11; x86_64 Linux; rv:68.0) Gecko/20100101 Firefox/68.0"

Este último user agent é o mesmo que vemos ao usar o navegador Firefox. A diferença seria o número de requisições feitas para o servidor Web. Wget só executar um GET, enquanto o navegador Firefox realizaria um GET request e tentaria baixar todo o conteúdo para mostrar a página da Web. Para entender esta diferença olhe este post.

Alguns user agents são usados por softwares conhecidos para executar tarefas automaticamente, como varreduras de vulnerabilidade. Alguns agentes de usuário de scanners de vulnerabilidade são:

-          - Nikto: "Mozilla/5.00 (Nikto/2.1.6) (Evasions:None) (Test:Port Check)"

-          - OpenVas: "Mozilla/5.0 [en] (X11, U; OpenVAS-VT 11.0.0)"

 Verifique este site  para saber mais sobre outros scanners de vulnerabilidade

Uma pergunta seria: por que alguém está escaneando minha rede?

Times de segurança ofensiva (Red Teams) e auditores costumam automatizar as varreduras de vulnerabilidades. Entretanto, atacantes também costuma utilizar ferramentas para agilizar seus ataques. Então é melhor ficar atento.

Quais são  as coisas mais importantes sobre as  informações dos agentes de usuário?

    - Se você detectar um user agent estranho, você deve investigar. Isso é verdade porque a maioria dos usuários não usa agentes estranhos.

    - Se você não detectar um user agent estranho, você deve olhar para o registro cuidadosamente. Isso pode ser uma solicitação benigna ou uma solicitação maliciosa com um falso agente de usuário.

Entender os registros durante uma investigação de incidente é realmente importante. A investigação de aplicativos web pode usar os registros do servidor web e o agente do usuário é uma informação importante. Tome cuidado com suas conclusões quando vir as informações do agente do usuário.

Veja os testes realizados neste post no vídeo.

SecOps - The user agent and user agent spoofing

User agents... agents but not so user.

(PT-BR) Check this video to see the tests used to create this post.

One of the information available on web server logs is the User Agent. What are user agents?

User agents are the software's that make requests from the client to the web server. User agent is an information that tells to the server which software the user (or not) is using to access the web page. So whenever you access a web page, the server will know with software you are using to navigate. Here a simple user agent name:

“Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”

The user agent information is found on web server logs. Usually all web server logs will have user agent on configured. And this is an example of a basic web server log with the user-agent.

10.1.0.10 - - [20/Jul/2018:13:38:10 -0500] "GET /animatedcollapse.js HTTP/1.1" 304 - "http://10.2.0.101/" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" (Get more information about web server logs here.

So, what is the problem of user agents? None. They work and are useful on log analysis.

The point is that they can be faked or crafted during the web request. There are many ways to do it. Changing the real user agent for some other is called "user agent spoofing". This is a common way to avoid basic attack detections.  Here I will show an easy way to do it. It uses Linux wget command. In this example. our Linux machine has the IP 10.1.0.10 and the web server has the IP: 10.2.0.110.

The first wget request:

$wget 10.2.0.110

The web server will show this log and the user agent from the request:

10.1.0.10 - - [18/Jul/2020:10:28:07 -0400] "GET / HTTP/1.1" 200 28067 "-" "Wget/1.20.3 (linux-gnu)"

Let’s force the user agent to change. Our user agent will be: i’m a firefox browser. Check the command and the web server logs bellow.

$wget -U "i'm a firefox browser" 10.2.0.110

10.1.0.10 - - [18/Jul/2020:10:28:34 -0400] "GET / HTTP/1.1" 200 28067 "-" "i'm a firefox browser"

The next scenario we will use a user agent that is common on Firefox browsers. You can find a good list of user agents here.

$wget -U "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0" 10.2.0.110

10.1.0.10 - - [18/Jul/2020:10:29:39 -0400] "GET /favicon.ico HTTP/1.1" 200 3638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"

This last user agent is the same of the one that we saw if using the Firefox browser. The difference would be the number of requests. Wget only perform a GET, while Firefox browser would perform a GET Request and try to download all content to show the web page. You can see this on this video.

Some user agents are used by well-known software’s to perform automatically tasks like vulnerability scan. Some user agents from vulnerability scanners are:

-          Nikto: "Mozilla/5.00 (Nikto/2.1.6) (Evasions:None) (Test:Port Check)"

-          OpenVas: "Mozilla/5.0 [en] (X11, U; OpenVAS-VT 11.0.0)"

Check this web site to learn about others vulnerability scanners

The question would be: Why someone is scanning my network? Red Teams, security auditors usually scan the web pages. Also attacker do it too. So, its better to identify. 

What are the most important things about user agent information?

-          If you see a weird user agent, you should investigate. This is true because mostly users will not use weird agents.

-          If you do not see a weird agent, you should look to the log carefully. This can be a benign request or a malicious request with a fake user agent.

Understand the logs during an incident investigation is really important. Web application investigation can use the web server logs and user agent is an important information. Take care about your conclusions when you see the user agent information.

Check this video to see the tests used to create this post.

SecOps - Apple Purchase Phishing mail Analysis - Part 2

Phishing mail analysis - Part 2

This is a SecOPS post. It will contain some technical content. This is the 3rd post about a Apple purchase phishing and SecOps part 2.

In Fast Analysis we did some basic questions that can be helpful to the most users.
In Part 1 we discussed about the web site and its suspicious functions and did some specific analysis about the domain like date of creation and reputation. This last part we will check the email message and do a analysis on the message body and header.

As we know that the email is a phishing email, lets analyze the email to identify a possibility cause that it was not identified as spam by the anti-spam protections. 

First, we need the original message with the header. Some ways how to get the header is shown here. One important header part is the Authentication-Results, as shown in the picture. We can see the real sender of the email: resolutioncenterapplesforms-billing.info and IP address:  209.85.214.100. 

Header information

As we did on Part 1, using whois let's check the domain. 

Email Sender domain information.

It's a pretty new domain too and it was created some days before the domain verifyouridentity.com. As told, new domains are suspicious and new domains from well know companies are more suspicious. Checking the original message, a little more, we see that the message is encoded with base64.

Encoding information

We should be able to read the email with the original message. Since it's encoded with base64 we can't find the body of the email. The information is that we have a txt/html encoded with base64. After "MIME-Version: 1.0" we see the Base64 data, which end with "==". Base64 it's used to send binary data as clear text over text-only transfer. Base64 it's used sometimes like when we need to send an attachment or when we add a picture directly at message body, but sending the body message as a base64 isn't a good thing. You can see the pictures and the end with "==". This base64 contains around 400 lines on notepad++.

Email body encoded (base64)

There are many ways to decode base64, I like the plugin with Notepad++ software. On pictures, we can see the real message (phrases, links,..) after the decode process.

Decoded email body.

And here the detail of the suspicious link.

Email link.

First thing to notice is that the link is different from the website link that we checked on Part 1, Also its a shorten URL website. This is common to use to bypass the anti-spam analysis. Why this works? Let's check the domain 

Virus total analysis.

So, the URL was not suspicious on last analysis day. This is one of the reasons that anti-spam would allow this file. So there is a big difference between mail URL (mysp.ac/4AQG6) and final web site (verifyyouridentity.com). One of the ways to check the redirection is using wget command on Linux systems. (you can use Developer tools from your browser too.)

wget result

If you check the wget result, you will see that there are a lot of redirects. Each 302 result is a redirect. It shows the verifyyouridentity.com website on 3rd result. On this test the verifyyouridentity redirects to another web site, this could be a protection from malicious website after identify the connection was from a wget command. If you have questions about user agent go to this post.

Here all the URLs from the result.

hxxps://mysp.ac/4AQG6
hxxp://www.bungamawaruntuktmu.igg.biz
hxxps://appleid.apple.verifyouridentity.com/?16shop
hxxps://href.li/?https://store.lilbub.com;Url

Possible root cause: The message body was encoded with base64 bypassing the anti-spam analysis. Also it had many redirects. So the email was considered clean.

IOCs to block or watch on your network:

Type	Data	Suspicious?
Email Address	REDJANG-DANCE959@APPLE.COM	Yes
IP Address	209.85.214.100	Neutral
IP Address	63.135.90.71	Yes
IP Address	78.46.211.158	Yes
IP Address	188.40.116.114	Yes
Source mail Domain	resolutioncenterapplesforms-billing.info	Yes
URL	hxxps://mysp.ac/4AQG6	Yes
URL (base64)	aHR0cHM6Ly9teXNwLmFjLzRBUUc2	Yes
URL	hxxp://www.bungamawaruntuktmu.igg.biz	Yes
URL	hxxps://appleid.apple.verifyouridentity.com/?16shop	Yes
URL	hxxps://href.li/?https://store.lilbub.com	Yes

Some useful links:

• Debugging an empty spam email
• Filtering base64 encoded spam
• About SPF,DKIM e DMARC
• Email Header Analysis
• Tool to decode base64

SecOps - Apple Purchase Phishing mail Analysis - Part 1

Phishing mail analysis - Part 1

This is a SecOPS post. It will contain some technical content. 

On this post we concluded that the bellow email is a phishing mail.

Phishing email 

So you can delete it.

 

Question: As important web mail platforms Microsoft, Google, Yahoo,.. should have great anti-spam filters. I have some free accounts and I got really few spam emails on it. So getting an phishing mail is weird, let's do some analysis on e-mail.

1. Let’s access the available links on email. 

All links are the same: hxxps://mysp.ac/4AQG6.

Going to the page, we see a page that looks like Apple website. It asks for username and password. An important detail is that the page tries to show as a secure page, it shows the locker (cryptography) close to the address. So, it's important to remember that the secure locker is to show that the information between your computer and the server where the page is hosted are protected, this doesn't mean that the page is safe and secure. Details on the picture bellow: 

Web site link from email

HTTPS detail, not so safe...

You can see that the page looks like Apple page. If you check the locker on the page, you will see that the page is using HTTPs, so this means that the traffic is encrypted.

On some computers, may a warning message can be shown, like this one:

Browser warning

The website asks for your Apple ID and the password. After entering with username and password a new error is shown. Now it tells that our account is blocked, but we have a button to unlock. Let's click on it.

New error after credential input

"Unlock Account" button redirect us to a new page. A form to fill with information like name, address and some credit card data. Again, after filling all the fields, it shows another error message.

Malicious form

Payment error message

If you input your information on this site the attacker will have your data and can buy some stuff with your credit card. Now we have two theories: 

• It's a good site and we typed wrong the data. Or it is a temporally error.
• The page is trying to get more credit cards from us.

We still believe that the website is malicious. Although It is good to have more reasons to classify the email as a phishing. Sometimes someone will ask for more proof, even if we believe that it's just a way to get more credit cards numbers. So another valid tip is about the site domain. We can use the tool called whois to get some info about the domain. The address that is shown at browser is:

     https://appleid.apple.verifyouridentity.com/?16shop, we only need the red part to check the domain.

Whois result

 

Reading the creation date (some tools can show as registration date), we can infer that this is a pretty new domain, this isn't a good signal. Apple isn't a new company (if you curious enough, check the whois info about apple.com). This first analysis concluded the same: the email is malicious. Also with the analysis we can infer that the purpose of the email is to get some personal and credit card data.

- URL: verifyyouridentity.com

New things get old. What you can do if you are seen this post after some time. 6 months later, or 1 year later or even more. You should check the reputation of the domain. For example, check virus total web site and add the domain. This is the result of this domain. 

Virustotal result

Next post. we will do the email analysis.

Phishing Mail analysis. Apple purchase - Fast Analysis.

What to do when we get an email about a purchase that we did not made?

The focus on this post is to warn end users it is classified as Daily Questions, because it is useful to everyone. If you interested on technical analysis check the SecOPS posts tags.

We will show an example of a fake email (a phishing) that I got. The email seems to be from Apple and it has a drone purchase receipt. First thing: no purchase was made. First analysis about the email. The question that everyone should do when get an email is: Is this true? 

Without technical analysis, let's enumerate some thing that can help.

• Domain @apple.com. OK
• Source e-mail with a weird name: “REDJANG-DANCE959”. Usually we expect to receive some emails like: suport@apple.com, contact@apple.com. NO-OK
• The greettins is using the same email address instead of the correct name. Dear ( email@email.com). NO-OK
• The name in the receipt and the name of the email owner are different. NO-OK
• No purchase was made. NO-OK
• The destination address is wrong. NO-OK
• Apple selling Drones. NO-OK
• The email is a reply ("Re:"). NO-OK
• The drone price is apparently right. OK
• A search on internet show another user that got the same email with few differences. Apple community site. NO-OK

Conclusion: We will consider this email as a phishing, so just delete and let's keep life going. The OK/NO-OK questions were created just to help the email classification. From 11 questions only 2 were OK. The best scenario is when all questions results in OK. Two more things to do is check your credit card to confirm that no purchase was made and check your Apple account.

If you get an e-mail like this, don't click in any of the links. If you didn't buy the item that email is talking about, so it is fake.

If you want more detail about e-mail investigation click here.