terça-feira, 30 de outubro de 2012

Administre seu servidor com inteligência, use o Screen


Já tem um tempão que gostaria de postar algo sobre o comando screen, acho que chegou a hora. Essa ferramneta é indispensável para qualquer administrador de servidores *UNIX like*. Para ajudar a entender a importancia desse comando segue uma rápida história que acontece muito na vida de quem administra um servidor unix ou linux.

Um belo dia você é acionado pelo sobreaviso da empresa onde trabalha ou presta serviço e precisa acessar o servidor WEB de forma remota, claro você usa o SSH para isso, até ai tudo bem. No decorrer da sua análise para descobrir o que esta acontecendo com o serviço WEB você executa algum tipo de ferramente de análise e precisa de outra aba do terminal para executar o tcpdump, o que você faz? Inicia outra sessão SSH para isso, agora você tem duas sessões SSH uma em cada aba do terminal.

Depois de algum tempo sua conexão com a internet cai, você perde todas as suas conexões antes estabelecidas, inclusive a do SSH. É isso mesmo você perdeu todo seu trabalho realizado até aquele momento. Infelizmente você precisa acessar o servidor novamente e começar tudo de novo.

É ai que entra o comando screen, pense nele como se fosse aquelas abas do firefox com isso basta apenas uma conexão SSH com o servidor, e mesmo que sua internet caia não tem problema, com o screen você pode recuperar a conexão que estava usando antes de perder o acesso a internet, não perdendo nada do que estava fazendo. Vamos ao que interessa.

Instale o screen:
apt-get install screen

Um pouco do básico, para usar basta digitar screen e apertar enter:

Apartir desse momento você já esta no prompt do screen, onde você pode usar "Ctrl+A" para enviar comandos para o screen, como exercicio aperte "Ctrl+A" e depois ? para ver uma tela de ajuda mostrando os comandos que podem ser usados juntos com o "Ctrl+A": 

O comando "Ctrl+A" "c" serve para abrir outra janela dentro do screen, assim você pode rodar dois comandos ao mesmo tempo em uma conexão SSH e sem precisar colocar um dos comandos em background. Para os nossos testes não será necessário acessar nenhuma máquina de forma remota, basta abrir um terminal local. Vamos fazer um exercício para entendermos como o "Ctrl+A" "c" funciona, para esse exercicio precisamos saber que o comando "Ctrl+A" "n" serve para acessar as janelas que foram criadas. Abra um terminal, digite screen e crie mais duas janelas apertando duas vezes "Ctrl+A" "c". Agora execute o comando "top" e depois vá para a outra janela do screen com o comando "Ctrl+A" "n" e execute o comando "watch ls", execute novamente "Ctrl+A" "n" e execute o comando "netstat". Agora para você ver os comandos digitados basta ir para as suas respectivas janelas com o comando "Ctrl+A" "n". Perceba que em apenas um terminal você pode executar três comandos diferentes sem precisar colocar em background.

Você pode fechar uma das janelas criadas executando "exit" ou "Ctrl+A" "k", se você quiser apenas fechar a janela mas deixar o processo rodando execute "Ctrl+A" "d" (d=detach). Faça esse teste em uma das janelas criadas, execute "Ctrl+A" "d", agora liste as sessões do screen com o comando "screen -ls", depois de achar a sessão que você tinha feito o detach é só reestabelecer com o comando "screen -r nome-da-sessão": 


Você também pode dar nomes a sua sessão e executar o comando junto com o comando screen, neste exemplo vamos criar uma sessão dando um nome e executando o comando: 

$screen -S NomeSessao-LS ls /tmp

Agora posso executar o comando "Ctrl+A" "n" e depois listar "screen -ls" e se precisar recuperar a sessão que executei meu comando ou script "screen -r nome-da-sesao".

Dica tirada do viva o linux: 

Que tal agora compartilhar essa sessão com um amigo seu? Dá para fazer isso?
Sim! Peça para seu amigo acessar a sua máquina via ssh com o mesmo usuário que você esta logado, assim que ele logar peça para executar "screen -x", com este comando ele se conectará à mesma sessão que você esta e desta forma tudo o que você e ele fizerem serão vistos pelos dois. 


segunda-feira, 29 de outubro de 2012

SERVIÇOS DE REDE EM SERVIDORES LINUX

Esse é um curso de nível intermediário que ministrei já alguns meses, mas vale a pena da uma olhada. Segue abaixo o que foi ministrado e logo em seguida o link para download do PDF.


DHCP

1.1. Objetivos
1.2. Introdução
1.3 Configurando um servidor DHCP
1.4 Configurando clientes DHCP
1.5 Fixar IP no DHCP

APACHE com WebDav e PHP

2.1 Objetivos
2.2 Introdução
2.3 Instalação a partir de pacotes binários
2.4 Maneiras de Iniciar, parar e reiniciar o Apache
2.5 Arquivo de configuração
2.6 Criando Domínios Virtuais
2.7 Suporte a PHP
2.8 Habilitando WebDav
2.8.1 Carregando os módulos necessários
2.8.2 Habilitando WebDav
2.9 Habilitando suporte UTF8

Servidor SSH

3.1 Objetivos
3.2 Introdução
3.3 Instalando SSHD
3.4 Usando cliente SSH

Samba

4.1 Objetivos
4.2 Introdução
4.3 Portas Utilizadas
4.4 Instalando o Samba
4.5 Entendo o básico do smb.conf
4.6 Modo de trabalho
4.7 Criando um Compartilhamento
4.8 Criando um Compartilhamento Oculto

Link: http://www.4shared.com/office/qySx22Qf/Osvaldo_-Servidores_em_Ambient.html

Bom Proveito.

quinta-feira, 11 de outubro de 2012

Some Android App Security Problems



Link to publishers apps here. I just randomly stumbled into one of the apps, recognized it and noticed that the publisher wasn't who it was supposed to be.
Super Guitar Solo for example is originally Guitar Solo Lite. I downloaded two of the apps and extracted the APK's, they both contain what seems to be the "rageagainstthecage" root exploit - binary contains string "CVE-2010-EASY Android local root exploit (C) 2010 by 743C". Don't know what the apps actually do, but can't be good.
I appreciate being able to publish an update to an app and the update going live instantly, but this is a bit scary. Some sort of moderation, or at least quicker reaction to malware complaints would be nice.
After some dexing and jaxing (where did I get these terms..) decompiling the code (with dex2jar and JD-GUI), the apps seem to be at least posting the IMEI and IMSI codes to http://184.105.245.17:8080/GMServer/GMServlet, which seems to be located in Fremont, CA.
The apps are also installing another embedded app (hidden as assets/sqlite.db), "DownloadProvidersManager.apk". Not sure what it does yet on top of monitoring what apps the user installs.
According to Android Police's analysis, the installed app can download and install more code.
Note, that Google has apparently started pulling at least some of the apps.
EDIT: The developer account and the apps have been removed from the market, and the links to the apps above do not work anymore. The app details are still available at Appbrain, also check this and this on Android Police, and this post by Lookout Mobile Security for a list of additional malicious apps they found on the market. Also I'd like to give credit to the devs at Teazel for helping in identifying the exploit yesterday.
EDIT2: According to Lookout Mobile Security these malicious apps were published on two additional dev accounts on top of the one I originally spotted. Appbrain links: MyournetKingmall2010 and we20090202. Kingmall2010's account seems to be the oldest of the bunch, according to Appbrain it started publishing around Feb 11th (so older than the four days). The other two around Feb 23rd.
Looking at the download counts for all three accounts on Appbrain. They're lagging behind the real counts, as they don't update daily, so when the Market's real download counts for Myournet on tuesday totalled at 50k-200k, Appbrain is only totalling to 10k to 35k. Even so, adding Kingmall2010's download counts from Appbrain (48k to 224k) to those I nabbed from myournet's account on Market yesterday brings the total downloads to 98k to 424k. And that estimate is probably on the low side.
Symantec on recognizing if you're infected: "If users feel that they may have installed one of these apps, they should also check com.android.providers.downloadsmanager (DownloadManageService) in the “running services“ settings of the phone"


Bom proveito.

quarta-feira, 3 de outubro de 2012

Aplicação WEB: O que explorar?

Veja o que pode ser explorado em uma aplicação WEB:

* Client-side validation — Checks may not be replicated on the server

* Database interaction — SQL injection

* File uploading and downloading — Path traversal vulnerabilities, stored cross-site scripting

* Display of user-supplied data — Cross-site scripting

* Dynamic redirects — Redirection and header injection attacks

* Social networking features — username enumeration, stored cross-site scripting

* Login — Username enumeration, weak passwords, ability to use brute force

* Multistage login — Logic flaws

* Session state — Predictable tokens, insecure handling of tokens

* Access controls — Horizontal and vertical privilege escalation

* User impersonation functions — Privilege escalation

* Use of cleartext communications — Session hijacking, capture of credentials and other sensitive data

* Off-site links — Leakage of query string parameters in the Referer header

* Interfaces to external systems — Shortcuts in the handling of sessions and/or access controls

* Error messages — Information leakage

* E-mail interaction — E-mail and/or command injection

* Native code components or interaction — Buffer overflows

* Use of third-party application components — Known vulnerabilities

* Identifiable web server software — Common configuration weaknesses, known software bugs


Bom Proveito.

segunda-feira, 1 de outubro de 2012

Desafio XSS filter

Muito interessante essa questão. Participe do desafio.

INGLES

An input validation mechanism designed to block cross-site scripting
attacks performs the following sequence of steps on an item of input:

1. Strip any <script> expressions that appear.
2. Truncate the input to 50 characters.
3. Remove any quotation marks within the input.
4. URL-decode the input.
5. If any items were deleted, return to step 1.

Can you bypass this validation mechanism to smuggle the following data
past it?

“><script>alert(“foo”)</script>

PORTUGUÊS

Um mecanismo de validação de entrada é projetado para bloquear um ataque de cross-site scripting realizando a seguinte seqüência de etapas quando o usuário fornece uma informação como entrada:

1. Tira as expressões <script> que aparecem.
2. Truncar a entrada em 50 caracteres.
3. Remove todas as aspas.
4. Usa o URL-decode para decodificar a entrada.
5. Se todos os itens foram excluídos, voltar ao passo 1.

Você pode burlar este mecanismo de validação para que a expressão abaixo seja aceita?

“><script>alert(“foo”)</script> 

Lançado o desafio.

Bom Proveito.

Unix Admin Horror Story

É sempre bom aprender com os erros dos outros é essa a ideia do "Unix Admin. Horror Story Summary, version 1.0". Segue abaixo uma história que chamou muito minha atenção:

Management told us to email a security notice to every user on the our
system (at that time, around 3000 users).  A certain novice administrator
on our system wanted to do it, so I instructed them to extract a list of
users from /etc/passwd, write a simple shell loop to do the job, and
throw it in the background.  Here's what they wrote (bourne shell)...

       for USER in `cat user.list`; do
          mail $USER 
 
Conclusão: Aprenda e Teste teste teste teste teste teste bastante
antes de executar no servidor de produção.
 
Bom Proveito.