Jak przetestować bezpieczeństwo własnej aplikacji i serwera

Często w sieci trafiamy na pytanie “w jaki sposób przetestować bezpieczeństwo mojej aplikacji/mojego serwera”,  na co chętnie odpowiadamy zarywając kolejną noc i pisząc kolejny esej.

Z esejami w branży security jest tak, że o ile fantastycznie pomagają nam podbudować ego, to niewiele rzeczywiście wartości wnoszą do życia osoby, której wydawało nam się, że chcemy pomóc.  Cenię sobie każdego kto ma dobre intencje i poświęca swój czas by pomóc innym, ale po wielu latach w infosec, trzeba przeprowadzić reality check i spojrzeć prawdzie w oczy.

I ta prawda trochę w oczy zapiecze, bo okazuje się, że często nasze działania mijają się z celem. Zamiast dostarczyć komuś narzędzi za pomocą których osiągnie swój cel, to zarzucamy ludzi mnóstwem informacji, które same w sobie są wartościowe, lecz większość programistów/sysadminów po prostu nie ma czasu na analizowanie tak głębokich wypowiedzi.

W większości sytuacji, dobra rada to taka, która pozwoli komuś skutecznie rozwiązać problem, a wszystko dodatkowe to tylko szum.

Jeśli jesteś osobą zainteresowaną rozwojem w branży bezpieczeństwa IT, to śmiało rzuć okiem na moje długie artykuły/podcasty/szkolenia online w których obszernie wyjaśniam wiele tematów.  Natomiast jeśli nie chcesz zmieniać całej swojej kariery w kierunku infosec i chcesz po prostu sprawdzić podstawowe zabezpieczenia w swojej aplikacji, to na pytanie:

Jakie narzędzia automatyczne pomogą mi przetestować moją prostą aplikację na localhost+XAMPP?

odpowiem:

 Jeśli to localhost i chcesz się pobawić, to pobierz sobie Armitage i puść Hail Mary z agresywnymi exploitami z metasploita żeby Ci napsuł tyle ile się da.
Do tego z narzędzi, które są point & shoot to 99% tego czego potrzebujesz załatwi Ci:
OpenVas (opensource alternatywa Nessusa, tj. bezpieczeństwo sieci/hosta + znane podatności oprogramowania zainstalowanego na hostach – wliczając webappki)
OWASP ZAP – do dynamicznego testowania bezpieczeństwa aplikacji webowej

Zarówno w Armitage, OpenVas i ZAPie daj im dane logowania do hosta z najwyższymi uprawnieniami, tak żeby mogły przeorać wszystko co możliwe.

Z w/w narzędziami przeprowadzisz atak na >98% świata, XAMPPA wliczając 🙂 Pobierz narzędzia, pobaw się, daj znać gdy pojawią się pytania.


Enjoy 🙂

A gdy pojawią się jakieś pytania, to najprawdopodobniej ktoś już kiedyś wpadł na podobne pytanie i odpowiedzi na nie znajdziesz już dostępne w sieci, więc spróbuj najpierw pogooglować i pobawić się samemu. O ile generalnie rzeczywiście zaoszczędzisz trochę czasu w danej chwili jeśli spytasz kogoś o radę na tematy które były już poruszane setki tysięcy razy, o tyle długoterminowo lepiej będzie dla Ciebie jeśli przyłożysz się do własnego researchu i praktycznego dotknięcia tych wszystkich narzędzi/systemów.

Krąży po świecie taki ładny cytat, który przez swoją ponadczasową mądrość jest przypisywany wielu wielkim – od Konfucjusza, przez Lincolna po Franklina. Więc przytoczę go też i w tym blogpoście, bo niewiele w życiu prawd jest tak aktualnych jak właśnie ta:

 

“Tell me and I forget,

teach me and I may remember,

involve me and I learn.”

Do roboty! 🙂

13 basic steps to start a practical implementation of DevSecOps at your organisation

Hello Friends,

I want to share with you a blogpost I created as an attempt to bring some more clarity to the concepts that are [finally] getting more attention of the public.
I’m a solid believer that the potential of the tribe can be tapped into it’s full extent only if all the members of the community are able to communicate freely with each other and exchange the ideas. Same way we can’t solve a problem if we don’t know if there is a problem or what is the problem, I believe for us to innovate and bring our ideas to fruition we need to our language and simplify the overcomplicated terminology. But that’s just me being me with my lengthy intros to what’s about to come next, so let’s cut it short this time and get to the specifics.

Secure SDLC requires multiple steps to be completed in order to secure whole software delivery cycle, although each step alone significantly contributes to overall security posture of an organisation. Implementation of Secure SDLC in AgileDevelopment requires transformation of traditional collaboration workflows, where security teams worked as an independent consultancy offering their support on demand basis, whenever needed by software engineers. With Agile development where speed is the most important variable, there is a need for shifting security to the left of SDLC, minimizing exposure in later SDLC phases and decreasing the costs of remediation of security issues when they’re discovered. Besides the decreased total cost of software development, DevSecOps brings a concept of servant leadership to the security ecosystem, improving the overall culture of the organisation and reducing the friction between security operations and all other employees.

I like to explain the practical difference between Secure SDLC and DevSecOps in the following way:

 

SSDLC is meant to answer the technicalities of the vital questions in any transformation process, i.e. “what”, “when”, “where”, “how”, and “why” and in this particular context it’s pretty much meant to address what’s been known since 2002 as Microsoft’s SDL. You can read it as processes, procedures, tools etc. which you plug into your SDLC workflow to ensure that each phase of SDLC has a corresponding security instrument initiating some sort of activity meant to reduce the security exposure created by/in the final product.
DevSecOps is then a cultural movement meant to ensure everyone across the whole organisation understand the answer to “why” well enough to actually want to care about all those security things.
To follow SSDLC is to prepare an environment which just makes your products and organisation safer. To advocate DevSecOps is to encourage people to put in use all the great things you’ve prepared for them with SSDLC setup and to not despise the additional burden – rather to enjoy the vision of being able of supporting the common effort to ship safer products which support the bottom line of the company which in turn takes care of its employees.

To me, it’s all about using all the instruments available to create a win-win environment, and that requires a willingness to work on bringing everyone on the same page with the cultural transformation of your organisation.
If you as a security professional aren’t willing to believe that you can manage collaborating with other people at your organisation(be it engineering, sales, helpdesk, the board and all in between) you won’t be able to bring a meaningful change. We know how this story goes, because for the past few decades we’ve tried to convince other people to do something just for the sake of doing it and we see where it got us, so it’s about time to try another approach. And that DevSecOps is what I call an empathetic and result-oriented approach of tackling the security challenges of the modern software-related companies.

Although this explanation seemingly ignores a significant amount of details and may be looked upon by experts as over-simplistic, it just gets the job done. If you’d like to learn more about the effective means to use a language as a tool for getting your job done, you may want to take a read of the following article: https://www.peerlyst.com/posts/learn-how-to-speak-business-language-or-effective-security-management-part-3-dawid-balut
And here is a list of 13 specifics that I like to use as an initial outline of the attempt to analyze the scope of the transformation:

  1. Create a roadmap for an education of all technical stakeholders such as software engineers, QA testers, product owners and engineering managers on secure software engineering. Education process should include trainings/workshops meant to increase the technical skills related to secure programming as well as making employees aware of corporate securitypolicies, procedures, processes and best practices. The later provides employees an opportunity to obtain a wider perspective enabling them to come up with their own ideas on how to build a contextual defense mechanisms linked to the feature they’re developing at the moment.
    Security training should be conducted in a form of interactive workshops, to create a personal bonds between security staff and other employees and to increase the odds of personnel remembering the entertaining learning experience. Going forward, employees should have access to comprehensive knowledge-base e.g. in a form of automated learning platform that allows access on ad-hoc basis when they need to learn about safety of currently developed software module.
  2. Educating all business units on how security should be instilled into SDLC and day to day work of their teams. Approach top to bottom helps ensure that the management actually provide employees needed resources to do their work securely.
  3. Creating a culture of collaboration between security and all other departments in the spirit of DevSecOps, which emphasised empathetic and servant leadership. Security team should be deemed an indispensable member of each department, sharing their knowledge as well as acting as Subject Matter Expert in their domain of expertise – as opposed to an external silo which receives a cold requests to perform security testing of an already developed product.
  4. Deploying systems and code auditing tools to ensure higher coverage of security assurance. This includes involvement of automated scanning technologies across the whole technology stack used by an organisation. Implementation of those tools not only helps to identify security issues, but also by delegating remediation to a person that introduced a security flaw, enables practical education process where employees understand what they should do better in the future.
  5. Defining explicit minimum security requirements for each new application, where software engineers understand how things should be ran at the organisation in compliance with security-related departments. In Agile world, each back-and-forth with security team is a waste of time, which is why all documentation must be prepared upfront and delivered to relevant stakeholders.
  6. Creating quality bars that define on which risk levels it’s feasible to fail the build and not allow software to reach production, based on the assessment performed by automated systems for code scanning, dynamic application scanning, config auditing as well as manual testing.
  7. Incorporating one-time manual and automated threat modeling and design reviews. Reviewing software design at earliest and final phase of SDLC enables you to provide contextual guidelines for development teams, as well as to prepare security department for risks associated with development of very specific software so that all entities are prepared for reverification of mission critical components. Training product owners and systems architects how to create threat modelsallows to perform risk analysis at lower cost without direct involvement of a security team.
  8. Defining automated tools, benchmarks, security checks and baseline which explicitly enforces usage of specific security safeguards. Think of always enforced compilation flags on a build server, where security is bolt-in by default.
  9. Deprecating unsafe software and dead code. Automated analysing software for dead code as well as insecure and outdated dependencies significantly lowers the risk profile of an organisation and developer software. If automated systems are in place to achieve this, then software engineer can immediately react to an alert about insecure dependencyand upgrade the library in subject to secure minor version with security patches without significant impact on systems stability. Not upgrading libraries often leads to situation when there is too big difference between version used and expected, which may introduce too many changes to the system, which in turn increases the costs of software development by requiring additional testing performed by manual QA engineers .
  10. Performing Static Application Security Testing. SAST tools are should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system – such as each new commit to Version ControlSystem – and periodically, independent of release schedule.
    Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  11. Performing Dynamic Application Security Testing. DAST tools should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system and periodically, despite release schedule. Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  12. Performing Fuzz Testing, which is sending to an application unexpected types of random data that helps undiscover security issues that may be affecting whole CIA-triad(Confidentiality, Integrity, Availability). Fuzz testing is important to mention here, because while most of the automated systems are meant to ensure company’s compliance with certain standards and security baselines, fuzz testing is meant to expose unexpected security flaws that may have went under the radar of automated tools and software engineers.
  13. Performing manual review of tools and documentation output pre-release, to ensure high quality review with involvement of a human element.

In any case, I hope this article comes useful to you – whether you’re trying to gain a bit of an infield perspective into the world of Secure SDLC & DevSecOps, or if you’re a security professional looking for some basic steps to kick-off the process of trying it out at your organisation.

Have a great weekend Y’all and I’m looking forward to your feedback!

Dawid

PS. More content on this subjects coming out soon 🙂

Własny LAB do nauki pentestów – jak zacząć

Niedawno na Facebookowej grupie “Testowanie Oprogramowania” pojawiło się ciekawe pytanie:

Próbuję się przekwalifikować z testera manualnego na pen testera. Zmieniłam teraz pracę i jako pierwsze zadanie jako nowy penetration tester zostało mi polecone zbudowanie laba. Narazie nie wiem jak zabardzo to ugryźć.

Ogólnie dopiero formujemy security team więc wszystko jest jeszcze bardzo płynne. Docelowo lab ma służyc do werifikowania security vulnerabilities w naszym produkcie. Plus narazie mamy firmę która raz w roku robi nam pen testy ale chcemy to zacząć robić sami, więc to ma też być pewnego rodzaju playground

Na które jako tako udało mi się odpowiedzieć, więc wrzucam też na bloga dla potomnych:

 

1) Jeśli pytasz o LAB w kontekście środowiska gdzie możesz się uczyć testować bezpieczeństwo, to ten artykuł opisuje praktycznie wszystko co jest Ci potrzebne żeby wystartować i mieć czym się zająć najbliższy rok (jest stack webowy do testowania webówki, i jest też metasploitable do wdrożenia w pentesty infrastruktury).
https://resources.infosecinstitute.com/how-to-make-your…/
Masz tam też wypisane informacje odnośnie narzędzi, które powinnaś wykorzystywać jako swoje środowisko pracy do przeprowadzania testów, tj. wszystko począwszy od local proxy, przez automatyczne skany podatności, po nasłuchiwanie ruchu sieciowego.
Kilka innych zasobów, które pomogą Ci zbudować LAB w obrębie kontekstu, którym jest piaskownica w której możesz się bawić i rozwijać swoje umiejętności.
https://resources.infosecinstitute.com/building-your-own…/
https://medium.com/…/basic-penetration-testing-lab-1…
Przyda Ci się też książka Georgii Weidman, która mimo że jest już trochę przedawniona, to w bardzo ustrukturyzowany sposób przeprowadzi Cię przez to jak profesjonaliści infosec tworzą środowiska do samorozwoju:
https://nostarch.com/pentesting

2) Jeśli pytasz o konkretne narzędzia i to jak zrobić LAB do samorozwoju na większą skalę, to po prostu przyłóż się do OSCP. Napisałaś, że robisz OSCP, a Laby PWK to jedno z najlepszych środowisk na świecie z których wyciągniesz zarówno konkretne umiejętności techniczne jak i zobaczysz w jaki sposób zbudowane są LABy składające się z kilkudziesięciu hostów.
Po OSCP jeśli interesują Cię desktop appy, to nie popełnisz błędu idąc w kierunkcu OSCE.
Niedawno Offensive Security wypuściło jako kurs online szkolenie i certyfikację dla pentestów webowych, tj. Advanced Web Attacks and Exploitation (AWAE) + OSWE

3) Czytając jednak Twoje komentarze, odnoszę wrażenie że firma chce żebyś zbudowała środowisko typu piaskownica służące do testowania bezpieczeństwa produktów które wytwarzacie. Tutaj rocket science nie będzie, bo potrzebne jest zwyczajne środowisko z jakiego korzysta do testów Dev/QA w Twojej firmie. Natomiast jeśli chodzi o drugą część tego środowiska, tj. podpięcie narzędzi do ciągłego zapewniania wysokiego standardu bezpieczeństwa produkowanego oprogramowania to odsyłam Cię do zasobów opisujących praktyczną implementację Secure SDLC:
https://www.microsoft.com/…/securityengin…/sdl/practices

Przykładowe narzędzia masz opisane tutaj:
https://www.devsecops.org/blog/2016/5/20/-security

A do aplikacji desktopowych powinnaś zapoznać się z fuzzerami jak np. American fuzzy lop oraz narzędziami do statycznej analizy kodu, tzw SAST, np. OpenStack Bandit.
Listę tego typu narzędzi znajdziesz tutaj:
https://github.com/mre/awesome-static-analysis

Tak więc powodzenia i trzymam kciuki za Twój dalszy rozwój kariery – jest co robić! 🙂