Архив рубрики: Без рубрики

Which shell is on my Linux?

Команда «echo $0» — самый простой способ узнать, какой шелл используется в настоящее время.

В примере ниже, Kali Linux по умолчанию использует bash, но из одного сеанса можно запустить сеанс другого интерпретатора:

root@kali:/# echo $0
bash
root@kali:/# /bin/zsh
kali# echo $0
/bin/zsh

CouchDB vs. VirtualBox 5.x: битва за место

Если вы запускали сервер Faraday IPE на довольно продолжительное время (в моём случае мне хватило одной ночи), вы могли заметить через некоторое время что Linux сервер начинает дико тупить и тормозить, а кроме того сайты, которые хостятся на нём, могут быть недоступны. Проблема в движке баз данных CouchDB, который и использует Faraday для хранения данных. Не зря так прозвали эту СУБД, лёжа на диване трудно оставаться стройным 🙂

Но отбросим прелюдии. Делать-то что? Есть два пути (можно выбрать оба):

  1. Увеличить размер диска. Логично? Логично. Моя Kali Linux работает в VirtualBox и, как оказалось, разработчики VB не удосужились добавить возможность изменения диска в GUI. Но можно через консоль в VirtualBox Command Line Management Interface (подробности ниже).
  2. Понять причину и устранить её. CouchDB — прекрасная и очень удобная в работе СУБД, но за простоту приходится расплачиваться неудобствами в виде повышенной обжорливости. Периодически движок делает сжатие и бэкап существующих БД, это требует места и если его немного, то CouchDB продолжает до тех пор пока не кончится место на диске, а как закончится, вырубается, не прибрав за собой. Можно удалить эти временные файлы чтобы освободить место на диске  (подробности ниже).

Читать далее

Announce for SEI Webinar: From Secure Coding to Secure Software

sei-webinar-20160808_580px

Systems exploits, intrusions, and stolen data are more prevalent than ever. It seems there are daily headlines related to system security and privacy. Many, if not most, of these incidents could have been prevented with more secure coding practices. Software and systems are more connected than ever, often in ways that were not originally designed leading to unforeseen and unprotected attack vectors.

The CERT Secure Coding Standards are lists of rules and recommendations for developing secure software. In this webinar, we will discuss how you can improve your organization’s secure coding capabilities. We will discuss how to improve your workforce, processes, and tools to develop and verify the security of your software before it is deployed. We will also explain how the CERT Secure Coding Standards can help and how you can adopt them through training, tools, and process improvements.

Date: August 17, 2016
Time: 1:30-2:30 pm ET
Cost:  Free (prior registration is required)

Обзор сканера уязвимостей Vega

vega-transparent_200pxAuthor: Subgraph
Licence: Open Source / Free
Platforms: Windows, Linux, Mac

Vega — довольно мощный, универсальный сканер уязвимостей и сниффер пакетов. Интерфейс достаточно простой и не перегружен функционалом. Сканер позволяет проводить автоматический аудит сайта на наличие наиболее распространённых уязвимостей (OWASP Top 10), автоматически ранжирует найденные уязвимости по серьёзности и отображает исчерпывающую информацию (на какой страничке найдена уязвимость, её полное описание и используемый эксплоит, как исправить, отправленный/полученный TCP пакет). Из минусов — разработчики довольно медленно развивают продукт и на данный момент (07/2016) по-прежнему не реализована выгрузка результатов во внешние форматы (отчёты).

Vega, как любой приличный сканер, поддерживает работу с сайтами которые требуют аутентификацию и это сильно расширяет возможности сканирования, если у нас есть credentials или хотя бы cookies пользователя тестируемого сайта. Собственно, давайте начнём с того, что воспользуемся встроенным сниффером и перехватим наши же cookies для сайта-тренажёра WebGoat.

Читать далее

Обзор сканера уязвимостей OpenVAS

OpenVAS — Мощный и, что немаловажно, бесплатный сканер для тестирования защищённости веб-приложений и серверов. Обладает впечатляющим функционалом, объединяет в себе как встроенные возможности сканирования (обновляемые словари сигнатур эксплоитов NVT/SCAP/CERT), так и использование общепризнанных утилит типа nmap.

Если вы используете Kali Linux 2, OpenVAS уже входит в состав сборки, но перед первым использованием рекомендуется обновить пакеты в системе (apt-get update, apt-get dist-upgrade) и провести инициализацию сканера (Applications->Vulnerability Analysis->openvas initial setup). В консоли, где у вас будет проходить инициализация, обратите внимание на строку «User created with password..», используйте логин admin и сгенерированный пароль (который может выглядеть как длинная хеш-строка) для доступа в панель управления сканером:
OpenVAS_vulnerability_scanner_600px

Пользоваться сканером просто — в разделе Scan Management (либо на главной странице после запуска) вводите адрес сканируемого хоста и жмёте Start Scan. Можно оставить на ночь, сканер весьма неторопливый. Хм, что-то нашлось 🙂
OpenVAS_found_issues_630px

30 Day Testing Challenge, Are You In?

The Ministry of Testing just launched a 30 Day challenge for testers. Starting on 1st July, you will need to do one goal per day to pass the Challenge. Some tasks seems tricky and funny, but it’s a challenge, isn’t? 🙂 Print this list, stick it near your desk and mark the passed goals. Have fun-ctional testing!

30-Day-Challenge_500px

Обзор сканера уязвимостей Skipfish

Авторы: Google (Michael Zalewski, Niels Heinen, Sebastian Roschke, etc.)
Лицензия: Apache 2.0 (бесплатно)sf_name
Страница проекта: code.google.com/p/skipfish/
Последняя версия: 2.10b (Dec 4, 2012) / входит в сборку Kali Linux, отдельно ставить не надо.
Аналоги: Nikto, Websecurify, Netsparker, w3af, Arachni

Согласно описанию разработчика, утилита предназначена для проведения разведки на предмет защищённости тестируемого веб-приложения. Она создаёт интерактивную карту сайта с помощью рекурсивного- и основанного на словарях анализе, после чего сканер применяет к полученным элементам различные проверки защищённости (обещают, что non-disruptive, но в любом случае тестирование лучше проводить не на продакшне). По окончанию работ формируется отчёт для анализа результатов человеком.
Читать далее

7 reasons why manual testing will never die

MS_Office_2010_bug_with_font_size

OK, let’s talk about the current fad of some teams thinking they could achieve 100% coverage by their automated tests and resting on their laurels after that. And why the automated testing cannot solve all your QA needs.

  1. Robots are testing your code, but your users aren’t robots. It means if you are developing software designed to use by human, you would want to make sure it’s looking good, working stable.
  2. Automated testing could take more time to run than the manual one. Sounds ridiculous, but it is if your interfaces are often changes or your project lifecycle is relative small, you may found that more time wasted on development or maintenance your automated testing code in comparison if we would done it manually.
  3. Exploratory testing cannot be simulated. Let’s face it — our users usually don’t like reading manuals or follow formal ways as we designed software to use. Users would intuitively explore software and learn how to use it in that manner. We cannot predict all the users workflows and document them, thus we have to manually do exploratory testing.
  4. False alarms and false positive. Automated tests should be well tested itself to make sure it works as we want to. And they need to be reviewed periodically, especially if you started getting too small or too much alarms.
  5. If you use it — you know it. Testers who are manually testing its software know it better (workflows, UI, workarounds, features, etc). Remember how many times your Dev’s asked you how works the application they are developing? It’s because they are looking on the code most of the time, whilst you are on the user interface.
  6. 100% coverage is a myth. We may define tons of requirements for our app and even try cover all of them, but there is always a risk we missed something or new requirements appears after the release. Whilst this applies to both manual and automated testing, we should bear in mind that first 30% of coverage would be easy to automate, second 30% is relatively hard and I suppose 10-40% requirements cannot be automated for various reasons.
  7. Automated testing frameworks cannot predict the bugs. Or consult you about the possible bottlenecks in architecture you are going to implement. Some bugs has common reason, but appears in different places. And some of them are hard to reproduce, but easy to explain. Human may provide deep analytics based on its practice and experience.

In conclusion, although today is much less open positions required manual testing skills only and automated testing development becomes mandatory knowledge, we still need manual testing in our SDLC and we will need this as long as people will continue to use computers. Automated testing may reduce the amount of routine in our day-to-day duties, but we should still keep an human eye on what we are delivering to our customers (despite the fact that our auto-tests could indicate 100% passed rate).

p.s. On the picture displayed an issue found on MS Office 2010 — if you try to input text instead of expected number in font size field then switch to any other field — app will crash and you lose your work. This bug has been fixed in later versions of MS Office.

Announce for a ‘Lessons Learned from the Jeep Hack: How to Reduce Software Vulnerabilities in Cyber-Physical Systems’

04_11_16_Reg_Banner1_580

This event going to be quite interesting. You’re probably don’t want to miss it.
If so, go register and add a note into your calendar!

Topics to be covered 
  • Lessons Learned from Jeep — Case Study Review — Chris Valasek, Security Lead — Uber ATC
  • Secure Software Development Landscape — Mark Sherman
  • Security Requirements Engineering — Chris Alberts
  • Secure Coding Best Practices — Bob Shelia
  • Continuous Integration (Secure DevOps) — Hasan Yasar
  • Coordinated Vulnerability Disclosure — Chris King

April 11, 2016    1:00 — 4:15 pm ET

It’s online event. Reserve your seat now (free) by this link.

Android: Разработка и тестирование приложений без долгих рассуждений

На чём пишут Android приложения (языки и технологии)

В основном, на Java. Также для некоторых задач (например, 3D-графика) могут использовать C++ и даже C# (проект Xamarin). В целом, синтаксис всех трёх языков довольно схож и если вы знакомы хотя бы с одним из них, а также с принципами ООП, то проблем с чтением кода не возникнет.

 В чём пишут Android приложения (IDE)

В основном, так как мы в основном будем иметь дело с Java, используют Eclipse и Intellij IDEA. Первый бесплатный и менее удобный (зато можно бесплатно использовать в коммерческой разработке), второй — платный и более удобный (есть бесплатная версия, но она для «домашнего» использования). Для разработки под Android есть плагины к этим IDE.

Кроме того, компания Google сама распространяет IDE под названием Android Studio, основанную на IDEA и включающую также Android SDK (набор классов и инструментов для разработки) и AVD Manager (для создания и запуска виртуальных устройств Android). В настоящее время предпочтительно использовать именно её, она бесплатна и удобна в использовании.

 Где проверять работу Android приложений (устройства vs. эмуляторы)

Идеальный вариант — сочетать обе возможности. Реальные устройства дадут вам больше возможности в тестировании и покрытии приложения тестами (ведь работа мобильных приложений, в отличие от десктопных, зависит от множества факторов — уровень сигнала, смена уровня батареи, положения экрана, входящий звонок или действие «соседнего» приложения), эмулятор же интегрирован с IDE и можно быстро собрать, задеплоить и запустить приложение в эмуляторе и посмотреть как оно работает. Если вы занимаетесь функциональным или юзабилити тестированием, то лучше это делать на реальных устройствах (хотя бы на нескольких самых распространённых), если же тестированием защищённости — то лучше в эмуляторе (в нём можно контролировать и отслеживать работу приложения на системном уровне, к тому же это безопасней если мы ковыряем malware).

 Android Studio — Установка и настройка

Идём на страницу Android Studio, читаем и соглашаемся с лицензионным соглашением. Жмём Download. Установщик весит 1,2 Gb и при установке потребует 4,5 Gb на диске.

Далее запускаем инсталлятор. Ставить будем на Windows (можно на виртуалку, как вам удобней). Есть также сборки для Linux и Mac OS, но возможно там будут свои заморочки при установке 😉

Читать далее