Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Detectify : Hack Yourself !
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Detectify : Hack Yourself !

XiNiXXiNiX Member, Host Rep
edited July 2015 in General

What is Detectify?

The latest in security scanning through an automated, always updated tool.

Analyze your website from a hacker's perspective and provide you a report with the results. It is designed to be easy to use even for those with little or no previous knowledge of web security.

- 100+ attack vectors including OWASP Top 10
- A mix of 0-day and signature based scanning
- No install - get started in 3 min
- Frequent automatic updates
- Based on structure, not content.
- We check for malware
- Recurring functionality

https://detectify.com/

PS : I have no affiliation to this site.

Thanked by 1Anna_Parker

Comments

  • KwiceroLTDKwiceroLTD Member
    edited July 2015

    So, pretty much they make you pay to use nmap and metasploit and a basic proxy scraper for anonymity?

  • @KwiceroLTD you could apply that argument to every SaaS security scanner in existence.

  • HBAndreiHBAndrei Member, Top Host, Host Rep

    "Go hack yourself" :D
    I have mixed feelings about their slogan.

    Thanked by 1Clouvider
  • ClouviderClouvider Member, Patron Provider

    HBAndrei said: "Go hack yourself" :D I have mixed feelings about their slogan.

    Me too unfortunately :). After just the slogan I wouldn't run it on anything sensitive.

    Thanked by 2XiNiX HBAndrei
  • AnthonySmithAnthonySmith Member, Patron Provider

    KwiceroLTD said: So, pretty much they make you pay to use nmap and metasploit and a basic proxy scraper for anonymity?

    Well they do claim to have 0day stuff so perhaps not exactly the same.

  • jhjh Member

    I don't understand their pricing model. Why not just charge a flat fee per scan?

  • XiNiXXiNiX Member, Host Rep

    @Clouvider said:
    Me too unfortunately :). After just the slogan I wouldn't run it on anything sensitive.

    Same Here.

  • So really it's just detection, it doesn't do any active testing of that of a Web Application pentester...

  • Hey guys! I'm one of the founders of Detectify, and I'm the one responsible for the engineering of the scanner and the security tests made.

    @KwiceroLTD said:
    So, pretty much they make you pay to use nmap and metasploit and a basic proxy scraper for anonymity?

    This is not the case, the entire scanner is built by us from scratch. As we focus on web security explicitly, there's no point for us to integrate nmap or metasploit which is closer to the network security realm. Regarding the "proxy scraper", we run a full crawler to scope up the web apps to get as good coverage as possible. This includes the evaluation of JavaScript, sending AJAX requests etc... to find as many potential sinks as possible. Our primary focus is to spot the XSS, SQL injection, CSRF (and other flaws) that may reside in web applications.

    @HBAndrei said:
    "Go hack yourself" :D
    I have mixed feelings about their slogan.

    @Clouvider said:
    Me too unfortunately :). After just the slogan I wouldn't run it on anything sensitive.

    That's too bad. You can always try it out for free on some none-sensitive host if you want to get a feeling for what we do and what we deliver. Is the slogan too informal?

    @AnthonySmith said:
    Well they do claim to have 0day stuff so perhaps not exactly the same.

    Indeed, if you fuzz enough applications black-box you notice vulnerabilities that may or may not be known to either our clients or the vendors behind the software.

    @jhadley said:
    I don't understand their pricing model. Why not just charge a flat fee per scan?

    We've tried that, but people did not seem willing to pay before they knew what we delivered. Another aspect is that clients ran a single scan, we found vulnerabilities, the clients got satisfied and forgot about our service.

    What people tend to miss in regards to security, is that if your blog may be "secure" today, but it will not remain that way forever. New flaws turn up on a day-to-day basis and technology get deprecated quickly. Remember the heartbleed flaw? It made the whole world vulnerable from one day to another. This is why we want our clients to use our service on a recurring basis. We can keep track of plugins/themes/databases/frameworks and their quirks, so developers can focus on development.

    @eastonch said:
    So really it's just detection, it doesn't do any active testing of that of a Web Application pentester...

    We detect flaws, we don't compromise our targets using the flaws. So yes, if your goal as a pentester is to get as deep in as possible, then our service might not be completely suited for you. Although, one can use Detectify to scope up an application and get a foothold, then use our findings in complement with other tools to dig deeper.

    Feel free to shoot questions at me!

    Cheers,

  • eastoncheastonch Member
    edited July 2015

    almroot said: We detect flaws, we don't compromise our targets using the flaws. So yes, if your goal as a pentester is to get as deep in as possible, then our service might not be completely suited for you. Although, one can use Detectify to scope up an application and get a foothold, then use our findings in complement with other tools to dig deeper.

    'Compromise our targets' - Nor does a pentester, the idea is to detect, test and provide proof of concept for vulnerabilities. For instance, if the client is vulnerable to SQL Inj, it would be acceptable to dump their tables names as proof. As is providing screenshots & Proof of concept URLs for XSS.

    Could you divulge how you are using the proxy scraper to spot XSS, SQLi, CSRF, CORS?

    Does it parse and take into account wsdl files to report on endpoints in a SOAP application?

  • ClouviderClouvider Member, Patron Provider

    almroot said: Is the slogan too informal?

    Yeah, I think so. Security is a serious stuff and informal slogan doesn't give you much confidence, to be honest. At least that's what I feel about it.

    Thanked by 1HBAndrei
  • jhjh Member
    edited July 2015

    almroot said: We've tried that, but people did not seem willing to pay before they knew what we delivered. Another aspect is that clients ran a single scan, we found vulnerabilities, the clients got satisfied and forgot about our service.

    What people tend to miss in regards to security, is that if your blog may be "secure" today, but it will not remain that way forever. New flaws turn up on a day-to-day basis and technology get deprecated quickly. Remember the heartbleed flaw? It made the whole world vulnerable from one day to another. This is why we want our clients to use our service on a recurring basis. We can keep track of plugins/themes/databases/frameworks and their quirks, so developers can focus on development.

    Feel free to drop me an email if a reasonable flat fee PAYG option becomes available - we have customers that would be interested.

    Thanked by 1netomx
  • @eastonch said:
    'Compromise our targets' - Nor does a pentester, the idea is to detect, test and provide proof of concept for vulnerabilities. For instance, if the client is vulnerable to SQL Inj, it would be acceptable to dump their tables names as proof. As is providing screenshots & Proof of concept URLs for XSS.

    Yes indeed. What is acceptable or not for a proof of concept is up to the individual performing the pentest along with the organization being pentested.

    With that being said, we are not extracting any information through SQL injection but merely point of where the flaw is. Regardless, depending on the finding we will provide screenshots, URL's, graphs, snippets of HTML, etc... that will help the developer to see what we've done and how.

    Could you divulge how you are using the proxy scraper to spot XSS, SQLi, CSRF, CORS?

    Yes I can.

    Different types of payloads will naturally behave differently. We can spot reflected HTML injections by simply interpreting the responded HTML and traverse the document until we find our payload. In the case of reflected XSS, we generate a full browser model and run whatever script is in there. If the JS engine tries to call our method, then we know it's vulnerable. DOM-based XSS is even tricker, as it may require user-interaction. The engine will invoke quite a bunch of DOM-events in an attempt to exhaust all code paths. Same thing here, if the JS engine attempts to call our method then we know a vulnerability is present.

    For SQL Injections we have three kinds of probes, error-based, boolean-based and time based. Error-based simply tries to cause a verbose exception for us to catch. Boolean-based tries "AND 1=1" & "AND 1=2" payloads, and time based will simply make the server sleep for a short amount of time. Any anomalies in regards two the last two tests will cause us to make findings. These tests are customized for the most widely used databases. We do not make any out-of-bound based SQL injections.

    For CSRF, we do our best to distinguish between privileged and unprivileged actions. That means that we'll trigger on login and register-forms, but not on search-fields. If we scanned as an authenticated user, it changes. At that point we consider any "unknown"-type of form without tokens to be vulnerable.

    Does it parse and take into account wsdl files to report on endpoints in a SOAP application?

    No. API-based pentesting can of course be done in a black box fashion. But as far as I'm concerned, by only analyzing the endpoints and the corresponding WSDL files (if any are present) will not necessarily provide a good audit by plain fuzzing. API calls changes states of applications. Different states will behave differently. Therefor it's hard to get a good coverage of what we fuzz. Even more so with a REST/JSON endpoint where no WSDL is specified. We have it in mind though, we just need to do it properly.

    @Clouvider said:
    Yeah, I think so. Security is a serious stuff and informal slogan doesn't give you much confidence, to be honest. At least that's what I feel about it.

    That's a fair point. Thanks for the feedback!

  • Good idea, best of luck.

    Thanked by 2almroot ricardo
  • @almroot maybe add some ways to mitigate the risk?
    Maybe an example, or recommendation?

    Thanked by 1almroot
  • @bohdans said:
    almroot maybe add some ways to mitigate the risk?
    Maybe an example, or recommendation?

    That's an ongoing (and slow) thing to implement, but it is a work in progress! If we know a domain run PHP, and we find a SQL injection (MySQL), then it's a lot better if we can guide the clients to that specific question. I.e, point them to a blog/article addressing prepared statements in PHP using something like PDO or mysqli.

    Of course, we can give more generic recommendations as a start, and then add more directed recommendations as we go... Thanks for the feedback though! I'll try to prioritize it.

  • @linuxthefish said:
    Good idea, best of luck.

    Thank you!

  • I did the test and the only thing it found was that my website was vulnerable to the SSL BEAST attack. However, after doing some research, it seems there is no recommended fix server-side and the fix should be provided client-side. It also says I should enable DNSSEC. Well, that's out of the question as DNSSEC is just like IPv6 (it should already be fully supported but isn't) and my domain registrar doesn't support DS records either.

  • That was very useful, thanks!

    One comment: the verification e-mail is troublesome in that it doesn't work in all e-mail programs. (SquirrelMail is one) I ended up having to sign up twice and recover the password - so it took me 10 minutes to sort out that little aggravation. I'm not complaining about a free service, but it's otherwise so slick you might want to look at that. :)

  • almroot said: This is not the case, the entire scanner is built by us from scratch. As we focus on web security explicitly, there's no point for us to integrate nmap or metasploit which is closer to the network security realm. Regarding the "proxy scraper", we run a full crawler to scope up the web apps to get as good coverage as possible. This includes the evaluation of JavaScript, sending AJAX requests etc... to find as many potential sinks as possible. Our primary focus is to spot the XSS, SQL injection, CSRF (and other flaws) that may reside in web applications.

    I know you're lying, but please, continue.

  • @ub3rstar said:
    I did the test and the only thing it found was that my website was vulnerable to the SSL BEAST attack. However, after doing some research, it seems there is no recommended fix server-side and the fix should be provided client-side.

    You can reduce the impact of SSL BEAST server-side by supporting newer protocol suites such as TLS 1.1 & 1.2 for modern clients. Older clients are more troublesome and may only talk SSLv3 & TLS 1.0. The previous recommended practice was to disable cipher-suites using CBC (and hence force the usage of RC4) for SSLv3 & TLS 1.0. Do not patch it using this latter practice as more research has been made into RC4 and it's now considered broken. To be fair, the best mitigation tips will most likely be resolved from Qualys SSL Labs here: https://www.ssllabs.com/ssltest/analyze.html?d=yourdomain.com

    It also says I should enable DNSSEC. Well, that's out of the question as DNSSEC is just like IPv6 (it should already be fully supported but isn't) and my domain registrar doesn't support DS records either.

    Unfortunately that's the case internet wide. Regardless DNSSEC will harden the integrity of the records. It might be worth considering depending on who you are, and the threat model against your domain/organization. We're planning on adding an "accepted risk"-button so you can remove findings that's not applicable for you. Is this something you would use?

    @Ole_Juul said:
    That was very useful, thanks!

    Cheers! :)

    One comment: the verification e-mail is troublesome in that it doesn't work in all e-mail programs. (SquirrelMail is one) I ended up having to sign up twice and recover the password - so it took me 10 minutes to sort out that little aggravation. I'm not complaining about a free service, but it's otherwise so slick you might want to look at that. :)

    Do you know more exactly what doesn't work? Is it the format of the HTML? Is it getting stuck in spam filters or similar?

    @KwiceroLTD said:
    I know you're lying, but please, continue.

    Sorry to hear that you believe that.

  • almroot said: Sorry to hear that you believe that.

    @almroom
    You'll have to understand why I'm skeptical about you, you're expecting me to believe a guy (or "guys"), no one has ever heard of until now, have the knowledge and power and more importantly skill-set to re-event the wheel write the tools (that already exists) to exploit it? It looks like you've simply put a wrapper around metasploit and nmap and SET. A simple google of "Fredrik Nordberg Almroth" (taken from a whois search of detectify.com) returns non-conclusive results, only 3 posts on exploit-db, and a facebook, and other misc. stuff. No real hard evidence you have the knowledge to write the software you claim.

    If you can prove me wrong, I encourage you to do it. If you can't (which I suspect), then don't bother replying.

  • Furthermore, I'd love to hear the explanation for this page:
    http://ackack.net/

    "If You're Reading This, I've Already Committed Suicide"

    with a twitter that is retweeting Detectify stuff, and furthermore is the registered domain owner currently.

  • joepie91joepie91 Member, Patron Provider

    almroot said: This is not the case, the entire scanner is built by us from scratch. As we focus on web security explicitly, there's no point for us to integrate nmap or metasploit which is closer to the network security realm. Regarding the "proxy scraper", we run a full crawler to scope up the web apps to get as good coverage as possible. This includes the evaluation of JavaScript, sending AJAX requests etc... to find as many potential sinks as possible. Our primary focus is to spot the XSS, SQL injection, CSRF (and other flaws) that may reside in web applications.

    I still don't see how that's any different from any of the myriad other vulnerability scanners on the market.

    AnthonySmith said: Well they do claim to have 0day stuff so perhaps not exactly the same.

    I doubt it. Once something has become public, it is no longer an 0day - which means that any "0days" they might have would stop being one as soon as they inform the customer of it. Frankly, I think it's simply being abused here as a term, to mean something it doesn't actually mean.

    Aside from all that, this sounds exactly like every other vulnerability scanner on the market, and will likely share the same issues. This is really not a thing you should be offering as SaaS.

    Thanked by 1KwiceroLTD
  • almroot said: Do you know more exactly what doesn't work? Is it the format of the HTML? Is it getting stuck in spam filters or similar?

    It's the HTML. There's no link to click.

    I had to set up a client specially to render HTML in order to see it. Perhaps you could send both text and HTML? That would not only allow your signup to work for conservative people like me who eschew HTML in e-mail as a matter of principle, but also for some people who use mobile devices that require text.

Sign In or Register to comment.