Howdy, Stranger!

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


Wordpress: hacked by Typical Idiot Security - Page 2
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.

Wordpress: hacked by Typical Idiot Security

2»

Comments

  • joepie91joepie91 Member, Patron Provider

    bountysite said: BountySite is a totally new approach to website security.

    What's new about it? Both backup systems and vulnerability scanners have been around forever, and only one of those generally actually works.

    bountysite said: The overall idea is simple, on every single investigation I can find the root cause and introduce security patch(looking at php) to prevent other sites on my platform from the same attack.

    Okay, so the "platform" isn't actually doing much, it's mostly just you analyzing issues and then broadly applying the fix to all customers? Or what exactly is the idea here?

    bountysite said: And also, if my malware scanner did not detect the new malware, I can add the signature to my db(yara, md5, sha256, fuzzyhash).

    There's a reason AV software companies have largely moved over to heuristics. Signature-based scanning just isn't that effective anymore, given how easy it can be to circumvent it. If you're looking for specific hashes, it will be even less effective, because a one-character change can throw it off...

    bountysite said: User passwords are stored as 20 byte long hashes(iterations of pbkdf2 algorithm with SHA512), by web2py.

    Why not argon2i or scrypt?

    bountysite said: Storage servers stores the FTP credentials in industry standard AES 256 bit encryption.

    bountysite said: All the downloaded website data is stored in AES 256 bit encryption. Meaning, if someone pulls off the hard drive, they wont be able to see data.

    So it's a good thing that you're being fairly explicit about the crypto used (what mode, though?), but what's concerning me is that you're glossing over the actual likely attack: someone compromising your storage servers while running. Encryption won't prevent this.

    Depending on situation that's not necessarily avoidable, but I would expect you to state that clearly, not squirrel it away in a statement that sounds like everything is magically encrypted and protected.

    bountysite said: Having said all this, I would just say that BountySite platform is far more secure than your hosting environment.

    Possibly, though not certainly. But the real problem here is that you're adding another environment that could be compromised (thereby increasing the attack surface), and it's not entirely clear why that would be a good idea.

    What does your service actually, concretely, provide in terms of security? "Vulnerability scans" (current-gen signature-based ones, anyway) are notoriously ineffective, and certainly don't require storing a full copy of a site on an additional system. So what's the value proposition here? What do you do that the hundreds of other vulnerability scanners can't?

    Thanked by 3jsg poisson maverickp
  • bountysitebountysite Member
    edited December 2019

    @FlamesRunner

    Appreciate your response. To be fair, my systens don't run WordPress (which axes out a lot of security vulnerabilities in itself!), and I've already taken reasonable measures to prevent a catastrophic loss of data (i.e daily backups to multiple off-site servers).

    Nice and sweet!
    BountySite would be a mere code revisioning system for such cases.

    You have addressed this partially, but I have a few more questions about your handling of FTP credentials. If someone were to compromise your backup systems, they would effectively have full control over a plethora of sites under your wing -- to me, that is a risk I simply don't feel comfortable with.

    Q: What if the FTP client connects to evil FTP server and leaves hacker reverse shell access?
    There has to be a vulnerability in python.
    Besides, the binary runs under apparmor, which gives me few layers of additional security.

    If still not convinced, I could offer with grsec. The pricing of grsec is the only factor why I did not build into storage. Once upon a time, it used to be free. I can provide customized solutions on storage based on requirements and budget.

    I did think of designing with multi user level, but even if one account is compromised it is still as bad as it gets.
    May be docker or LXC based containers is better, but it can increase complications in managing.

    Another level of mitigation wrt to hosting provider partnership, is to allowing client add only a specific set of IP addresses as owned/provided by the hosting provider. This works for partner based programs. So, can't connect to evil FTP server(just saying).
    Besides, for partner(hosting/reseller/white label) based programs we offer/accept dedicated storage servers. So, only partner's customers are stored on the node.

    There is no other attack surface on the storage nodes.

    Storage node has to be installed with vanilla Debian Stretch off iso, with openssh only. I have a script which does scanning to tell me if there is anything out of place, and need to be sent for reinstall. Also, incase of a storage server reboot, the services are not brought online till manually completing the above scan. The root OS is not encrypted and could have someone with physical access login(may be) and insert something.

    Even if you were to encrypt FTP credentials, at some point you would need to decrypt them to access customer files to take a backup. And, there will always be a moment where files are not yet encrypted on your storage systems. What have you done to protect against this?

    FTP credentials are not stored on drive, in clear text post decrypting. FTP credentials are always in encrypted format in storage. To be able to sniff it out of memory, you need root level access.

    Lastly, I did end up having a look at your product -- I think your mobile interface could use a little work with the less-than-friendly navigation menu, as well as the weird checkout page.

    I did see your sign up from disposable email address.
    I will admit that building UI is not my strength. I did start with building mobile friendly, but lost focus somewhere down the line. I agree that UI needs better hands. I am currently more focussed on the functionality and security part.
    I am a little obsessed with speed though. I have plans to cut down and make UI faster, but down the priority lane.

    Although I won't be using your services, I do wish you luck on your ventures. Part of starting a business is handling criticism, and so far I'm satisfied with your answers.

    If you don't have a problem, I dont have anything to solve.

    Your questions did put light on few things.
    Regarding Testimonials, I would never have a name with company name put out. They would be a sitting duck. I think it is a bad idea having testimonials at all, when it comes to security. I think I better knock out that section.
    I should have come out with videos on how to do things rather than just putting forth features.

    @LosPollosHermanos

    The absolute worst advice in the world, that I always read on these types of questions, is to wipe and reinstall. You learn nothing from doing that, create a bunch of unnecessary work for yourself, and usually only temporary fix the problem until it happens again and you will still not know how to fix it properly.

    Couldnt agree more on this!

    You learn a lot from tracking this stuff down and surgically removing it. I mean all of it, including the alternate backdoor stuff they sometimes put in to try get in again if you find their primary access.

    Exactly, what I am trying to accomplish with BountySite. Instead of blindly cleaning up sites, you can investigate a website hack.
    Even in the case of website restores from hosting provider or via interface, it is a mere guess work. You are only hoping that you have restored your site to pristine version. It is a trial and error method.
    Your website backup does not completely solve the security posture. In most backups, it does not tell you what files and data has changed.

    But, when you have backup websites/tables in a revision control, it gives you a nice diff and you can fetch the malware. So, you can easily make out the pristine version. So, restore is no more a guess work.

    With File/Table Change mail notification, you can fix your site before going into blacklisting mode. Getting hacked is bad, but getting blacklisted is where the real problem starts.

    @bikegremlin
    I am giving Free 1GB website backup for site owners. Users can use Backup Sync(free) to sync a copy of git archive to their own cloud(S3/B2).

    I try to wear a different hat for auditing and infact have made few additions/changes lately. Perhaps a person with no knowledge on the platform, may help. Down the line, I could get someone(legally) have a go. But my level of trust with other security vendors are low :). Its just me.

    @jsg

    I am trying, but marketing is clearly not my thing. But, I still have to promote and put forth my idea.

    web2py has over 900 issues

    These are mostly bugs. How many are security related issues? The most recent exploit found was out of admin interface. With an admin interface, you can do a lot more damage, leaving the exploit. Btw, admin interface is always disabled on live.

    Yes, I did file one for Mongodb. I didn't traverse this road and moved away as it was not well supported.

    One isn't a security guy because one has this or that sticker (eg OSCP)

    Agreed, OSCP only prooves that I am a learner. May not be the world's best certification.
    I am not saying that I am the best website security expert. BountySite will help me get better at this.

    I would be very astonished if he even thought about creating something like bountysite

    I agree that BountySite is indeed a huge huge challenge. Its taken me a lot of time and thought building it. I will continue making it better.

    I wish Danny good luck with bountysite, honestly, but after looking at his website I'm not at all interested in looking at his solution anymore and I would certainly not hand out my sites access data to some guy in Chennai, India who didn't convince me at all.

    Thank you. I can only put facts flat out. It is upto you to decide.

    And btw, no I do not think that Python is inherently much more secure than PHP.

    Ok! This is your perspective.
    I disagree.

    @joepie91

    What's new about it? Both backup systems and vulnerability scanners have been around forever, and only one of those generally actually works.

    With BountySite, the security scanners are all coupled with backup. No backup, means no security scanning.
    All operations work on the backup, the storage server.

    Okay, so the "platform" isn't actually doing much, it's mostly just you analyzing issues and then broadly applying the fix to all customers? Or what exactly is the idea here?

    The idea is to make security transparent. A site owner can always detect the malware out, through the platform. So, you know what is the issue. This is a start.
    Can you find out why it happened? That is the idea of the investigation.
    I enumerate applications and its versions, which helps me assess the possible vulnerability that was being exploited to insert the malware.
    Based on the possibilities, I can suggest patch(s) which will be available to all websites on the platform to apply and stay secure from the current attack.

    Security vendors do the same, but the solution is mostly off WAF. My proposition is at root level, by patching code.

    There's a reason AV software companies have largely moved over to heuristics. Signature-based scanning just isn't that effective anymore, given how easy it can be to circumvent it. If you're looking for specific hashes, it will be even less effective, because a one-character change can throw it off...

    AVs aren't designed for hosting environments. BountySite is for hosting environments.
    Well, if you are a site owner and you get a mail saying that a new file was added or an existing file was modified, you don't need any hueristic or artifical intelligence to say that it is a malware.

    Site owner is best security administrator for their own website. Tell me any security vendor who would say this?

    I can actually put greater marketing terms like Artifical Intelligence, Machine Learning etc which is actually present/doable in BountySite. But I prefer to keep things simple.

    Why not argon2i or scrypt?

    web2py default auth is sufficient, which is well supported an inbuilt and tried/tested for a long time.

    AES DES 256 bit encryption on storage.
    There is no addition of attack surface by adding storage.

    Meaning, if someone pulls off the hard drive, they wont be able to see data.

    Yes, encryption only prevents from physical access removing the hard drive.

    I am more than willing to answer your questions. This will only help BountySite get better. I truly appreciate these questions. :)

    What does your service actually, concretely, provide in terms of security? "Vulnerability scans" (current-gen signature-based ones, anyway) are notoriously ineffective, and certainly don't require storing a full copy of a site on an additional system. So what's the value proposition here? What do you do that the hundreds of other vulnerability scanners can't?

    Well, you do understand that there is no concrete security solution.
    Instead of calling BountySite security scanner, I would call BountySite a problem solver. BountySite solves website(hosting) security related issues at various levels.

    Why name BountySite? My main goal is Bounty hunting 0day vulnerability for web hosting environments. This is just a platform with some automation. This is one herculian task, but I am taking things bit by bit.

    So, what various levels?
    Level 1 Security
    - In most cases, website restore and app update fixes most of infection. Again, which security vendor says this?
    - User password resets and cron backdoor checks
    - You can investigate what happened to your site, at file/table level

    BountySite makes it easy to handle level 1.

    Level 2
    - Despite doing the above, website still gets infected
    - Temporary solution - Dormant Site Protection : A feature that will auto revert changes to a user mentioned version, post backup. This feature can also be used to protect idle websites.
    - Security investigation - Investigate why and how it is happening. The real work!

    Here is more information that I keyed in lately https://www.webhostingtalk.com/showthread.php?t=1789082

    Now, I don't have a prebuilt database of all vulnerability patches. I only address attacks/backed-websites and issue patches. This is all I can do.

    One hacked website can protect other websites from the same attack
    Works in similar lines of AV vendors updating signatures. The more data you have, the better you get.
    BountySite does this without impacting hosting server resources. The backup has minimal resource usage on hosting. First backup is full followed by always incremental based on timestamp, size and perms.
    User managed website backups : Managing server website backups can be a pain for providers and it can be offloaded to site owners, who are responsible for their own backups. Also, site owners dont have to wait for hosting provider to do a restore(depending on website backup software).

    I could do all this as a big company and take some funding and backing, if that adds trust. But it would take me in a path of just making money. Surely, I do want to make money but it is not the only thing.
    I like my freedom and love what I am doing. I think innovation comes with freedom. I have built BountySite trying to solve problems and not wanting to be better than x security vendor. Infact, I dont and cannot compete with anyone. I am just a problem solver.

  • edited December 2019

    @TimboJones said:

    @LosPollosHermanos said:
    The absolute worst advice in the world, that I always read on these types of questions, is to wipe and reinstall. You learn nothing from doing that, create a bunch of unnecessary work for yourself, and usually only temporary fix the problem until it happens again and you will still not know how to fix it properly.

    ** You learn a lot from tracking this stuff down and surgically removing it. I mean all of it**, including the alternate backdoor stuff they sometimes put in to try get in again if you find their primary access.

    One of the first things you learn by doing this is that hackers are lazy and usually not that clever. Some things that may not be obvious to them as an outsider with malicious intent is obvious to an admin. Like datestamps. If you know approximately when it happened you can do a search for datestamps and maybe figure out what the first file was that was touched.

    To clarify, "wipe and reinstall" should always be part of the solution, just AFTER finding out how it got in. Trying to and thinking you have successfully removed an infection is... dumb and prone to missing something. It's trivial to make an obvious infection to make user think they found the problem and the hacker just hid something else in there. They just need to cover their tracks a bit, which decent bad actors have been doing for decades.

    So,
    1. Find out how it got in
    2. Wipe
    3. Reinstall

    I don't think I have ever needed to wipe/re-install to permanently clean up of a compromised server. There was a lot of time and effort involved sometimes but I learned a lot. I learned to understand the enemy so to speak. I certainly don't live in fear of hacks or potentially unsafe software anymore. I know most of the tricks they use and do a lot of pre-emptive things now to prevent potential hacks with zero-day exploits. You can only learn how to be good at that by taking the harder route and not just wiping and re-installing.

  • @LosPollosHermanos said:

    @TimboJones said:

    @LosPollosHermanos said:
    The absolute worst advice in the world, that I always read on these types of questions, is to wipe and reinstall. You learn nothing from doing that, create a bunch of unnecessary work for yourself, and usually only temporary fix the problem until it happens again and you will still not know how to fix it properly.

    ** You learn a lot from tracking this stuff down and surgically removing it. I mean all of it**, including the alternate backdoor stuff they sometimes put in to try get in again if you find their primary access.

    One of the first things you learn by doing this is that hackers are lazy and usually not that clever. Some things that may not be obvious to them as an outsider with malicious intent is obvious to an admin. Like datestamps. If you know approximately when it happened you can do a search for datestamps and maybe figure out what the first file was that was touched.

    To clarify, "wipe and reinstall" should always be part of the solution, just AFTER finding out how it got in. Trying to and thinking you have successfully removed an infection is... dumb and prone to missing something. It's trivial to make an obvious infection to make user think they found the problem and the hacker just hid something else in there. They just need to cover their tracks a bit, which decent bad actors have been doing for decades.

    So,
    1. Find out how it got in
    2. Wipe
    3. Reinstall

    To be quite blunt about it, if you rely on wiping and re-installing as part of your security policy you should not be in this business or need to hire yourself a proper IT person. That's my opinion.

    Of course if your setup allows you to easily do that and get back to where you were before with mimimal effort then sure why not. But then you probably aren't really doing anything all that involved to begin with. I would think most things would still require quite a bit of re-configuration afterward. I suppose it depends on what you are doing.

    That's not a reliance, that's being certain. Kill it with fire. You will never be able to say with 100% certainty that you found and removed the infection, therefore it's permanently suspect and unsecured. Your ego that you found and removed 100% of the infection is being counted on for missing hidden backdoors. Don't guess, be certain, especially if it's not just your data. You don't come off as a surgeon, just lazy and willing to take unnecessary risks.

  • joepie91joepie91 Member, Patron Provider

    bountysite said: With BountySite, the security scanners are all coupled with backup. No backup, means no security scanning.
    All operations work on the backup, the storage server.

    Okay, so what? How is this advantageous? This sounds like a "Facebook, but for dogs"-style marketing pitch to me.

    bountysite said: The idea is to make security transparent. A site owner can always detect the malware out, through the platform. So, you know what is the issue. This is a start.
    Can you find out why it happened? That is the idea of the investigation.
    I enumerate applications and its versions, which helps me assess the possible vulnerability that was being exploited to insert the malware.
    Based on the possibilities, I can suggest patch(s) which will be available to all websites on the platform to apply and stay secure from the current attack.

    Okay, so... basically all you do is check installed software against a list of versions and known vulnerabilities for those versions?

    bountysite said: AVs aren't designed for hosting environments. BountySite is for hosting environments.

    This is irrelevant. An ineffective detection measure doesn't magically become effective just because it's a hosting environment.

    bountysite said: Well, if you are a site owner and you get a mail saying that a new file was added or an existing file was modified, you don't need any hueristic or artifical intelligence to say that it is a malware.

    There are many tools for detecting file changes already. This is not novel, nor does it need to be a service.

    bountysite said: web2py default auth is sufficient, which is well supported an inbuilt and tried/tested for a long time.

    No, it's not. PBKDF2+SHA512 is very prone to being attacked through ASICs/FPGAs, because it isn't memory-hard, like scrypt and argon2i are. You're in the business of selling a security product; I'd expect you to know this.

    The current default suggestion from cryptographers / security specialists for password hashing is argon2i, not PBKDF2.

    bountysite said: AES DES 256 bit encryption on storage.

    This is letter soup. "AES DES 256 bit encryption" is not a thing, and DES is certainly not an AES mode. This statement alone makes me immediately skeptical about your competence level where security is concerned, and would be enough to make me recommend against using your services.

    bountysite said: There is no addition of attack surface by adding storage.

    What? Of course there is! You're storing a copy of data in a new place, a new environment that can be individually attacked. You've gone from one single-point-of-failure, to two single-points-of-failure, where compromising that data is concerned.

    bountysite said: Instead of calling BountySite security scanner, I would call BountySite a problem solver. BountySite solves website(hosting) security related issues at various levels.

    Why name BountySite? My main goal is Bounty hunting 0day vulnerability for web hosting environments. This is just a platform with some automation. This is one herculian task, but I am taking things bit by bit.

    So, what various levels?
    Level 1 Security

    • In most cases, website restore and app update fixes most of infection. Again, which security vendor says this?
    • User password resets and cron backdoor checks
    • You can investigate what happened to your site, at file/table level

    BountySite makes it easy to handle level 1.

    Level 2

    • Despite doing the above, website still gets infected
    • Temporary solution - Dormant Site Protection : A feature that will auto revert changes to a user mentioned version, post backup. This feature can also be used to protect idle websites.
    • Security investigation - Investigate why and how it is happening. The real work!

    This is marketing fluff. I'm not interested in marketing fluff. None of this tells me clearly what your product actually does, from a technical perspective. How does it work? How do things get 'investigated'? How do compromises get detected if it doesn't match a known signature? How do the "backdoor checks" work? And so on.

    bountysite said: I could do all this as a big company and take some funding and backing, if that adds trust. But it would take me in a path of just making money. Surely, I do want to make money but it is not the only thing.
    I like my freedom and love what I am doing. I think innovation comes with freedom. I have built BountySite trying to solve problems and not wanting to be better than x security vendor. Infact, I dont and cannot compete with anyone. I am just a problem solver.

    I don't expect anyone to take external funding. In fact, I much prefer it when they don't. The problem is that you're over here making grandiose claims, yet showing yourself unable to properly address simple technical and security concerns.

    Running something like this by yourself is fine. But then you do actually need to know what you are doing, and I am not at all convinced that that is true here.

    You're selling random people a security service here. You're asking them to trust you that you're protecting their stuff. That comes with a responsibility to get it right, and to not overpromise.

    Comments like this:

    bountysite said: I am not saying that I am the best website security expert. BountySite will help me get better at this.

    ... are therefore extremely worrying to me. A service like this shouldn't be your personal learning environment, and I frankly don't think you're ready to run something like this. Try it out in a more restricted environment first, offering it as a free thing for friends or whatever.

  • jsgjsg Member, Resident Benchmarker

    @joepie91 said:

    bountysite said: web2py default auth is sufficient, which is well supported an inbuilt and tried/tested for a long time.

    No, it's not. PBKDF2+SHA512 is very prone to being attacked through ASICs/FPGAs, because it isn't memory-hard, like scrypt and argon2i are. You're in the business of selling a security product; I'd expect you to know this.

    The current default suggestion from cryptographers / security specialists for password hashing is argon2i, not PBKDF2.

    On this one I would be more generous than you, because PBKDF2 is in RSA's PKCS, which many less experiened people understand to be a recommendation from RSA. Also it's technically dimensionally better/more secure than MD5 or SHA1 or even SHA2 (which is the background against which PBKDF must be seen in real life as those are still used by many). And while you are right that PBKDF2 is not a really good solution it's still a very major obstacle for intruders/crackers.
    Two points though still remain

    • The reason. He uses PBKDF2 because that's what web2py comes with - that looks like a very sloppy and careless attitude for someone in the security field.
    • I'm not so sure about SHA-512 being the hash function used, I'd not be surprised to see it actually use SHA-256 or even SHA1. Plus he seems to not mention the iteration count which can make a killer difference.

    bountysite said: There is no addition of attack surface by adding storage.

    What? Of course there is! You're storing a copy of data in a new place, a new environment that can be individually attacked. You've gone from one single-point-of-failure, to two single-points-of-failure, where compromising that data is concerned.

    There he stated pure BS. And you were even too generous with your response, because not only does he of course add attack surface but way worse he created and runs a highly attractive target because hackers, if successful, gain access not only to one site but to many sites and even at different levels.

    And frankly I see no basis to presume that @bountyside even understands that. His first and main wall against intruders is "well, what web2py comes with" ...

    And there are many more points. To name one example: one does not use debian (or centos) and certainly not as it comes as an ISO for a secure storage server but one uses slackware or alpine or the like -plus- one creates ones own minimal kernel at the very minimum. Simple reason: code that's not there is code that can't be attacked.

    Comments like this:

    bountysite said: I am not saying that I am the best website security expert. BountySite will help me get better at this.

    ... are therefore extremely worrying to me. A service like this shouldn't be your personal learning environment, and I frankly don't think you're ready to run something like this. Try it out in a more restricted environment first, offering it as a free thing for friends or whatever.

    FULL ACK.

    Thanked by 2poisson maverickp
  • @joepie91 said:

    bountysite said: AVs aren't designed for hosting environments. BountySite is for hosting environments.

    This is irrelevant. An ineffective detection measure doesn't magically become effective just because it's a hosting environment.

    bountysite said: Well, if you are a site owner and you get a mail saying that a new file was added or an existing file was modified, you don't need any hueristic or artifical intelligence to say that it is a malware.

    There are many tools for detecting file changes already. This is not novel, nor does it need to be a service.

    Remember Violasoft and Trendfire Security Essentiales? Sounds just like them :p

  • @LosPollosHermanos

    You can only learn how to be good at that by taking the harder route and not just wiping and re-installing.

    Yes!

    @TimboJones

    You will never be able to say with 100% certainty that you found and removed the infection, therefore it's permanently suspect and unsecured. Your ego that you found and removed 100% of the infection is being counted on for missing hidden backdoors

    With BountySite, when you know the changes made to the website you know what has happened and know how to fix.

    @joepie91

    Okay, so what? How is this advantageous?

    You asked me how I am different.
    This solution of backup coupled with security is effective.

    Okay, so... basically all you do is check installed software against a list of versions and known vulnerabilities for those versions?

    Yes! It is one of the parts of the automation.

    This is irrelevant. An ineffective detection measure doesn't magically become effective just because it's a hosting environment.

    Yes, it is. You try to run a website malware against all known AVs. Even try VirusTotal, you will not have a 100% hit.

    There are many tools for detecting file changes already. This is not novel, nor does it need to be a service.

    Which tool is available in the market which notifies site file changes via mail to a site owner and can shows diffs? Ofcourse, no rocket science in it.
    Site File Integrity System is an effective way of dealing with website infections.

    I reiterate I am only solving a problem.

    My apologies, on buff up it is AES CCM, by zfs. I should have checked. Yes, cryptography is not my forte. I rely on zfs and cryptsetup, for storage data encryption.

    What? Of course there is! You're storing a copy of data in a new place, a new environment that can be individually attacked. You've gone from one single-point-of-failure, to two single-points-of-failure, where compromising that data is concerned.

    You mean, moving from hosting environment(SPOF) to another copy of data on storage? The storage is invisible to internet. Storage can be logged in only via a jumpbox with mandatory 2FA https://www.bountysite.com/sshtrail.html
    Hence, no other attack surface except via evil FTP server.
    Also, storage servers can be kept in a NATed private network.

    This is marketing fluff. I'm not interested in marketing fluff. None of this tells me clearly what your product actually does, from a technical perspective.

    Ok! I am trying to explain.

    How does it work?

    • It starts with site owner's consent, by configuring FTP backup. A job is pushed to the backup queue.
    • FTP host is contacted and all files are downloaded and committed to a git repository.
    • Subsequent backups are downloaded based on file changes in timestamp, size and perms. (Similar to rsync)
    • Site owner is notified about the file changes
    • Post backup jobs, another job is queued which calculates checksums md5 and sha256, which is used for enumerating application and looking up known malware db. Files that are part of existing app is tagged as known, which are queued for vulnerability scanning. The unknown files go through malware scanning - hash db, clam, yara signatures, fuzzyhash

    How do things get 'investigated'? How do compromises get detected if it doesn't match a known signature?

    • In the backend, there is a job which gives filename, size and hashes(md5, sha256 and fuzzyhash) for files tagged as unknown, where I can investigate suspicious file names or update known files list. So, down the line this would narrow down to malwares only.
    • My yara rule sets are divided into 2. One set which tags files as malicious and another set which tags files as suspicious. They are tagged suspicious to avoid false positives. Files tagged suspicious are investigated separately, just like unknown. The categorization of files are also available to site owners, where they can investigate on their own.
    • Malware building also can come from user reporting of hacks. There is an option where a site owner can request to investigate. Getting git diffs helps the process. And so can a user.
    • Manual investigation mainly comes from app enumeration, and checking known vulnerabilities.
    • If not a known vulnerability, a local host environment with same list of apps/plugins can be setup to invesigate and perform local testing.
      I have plans to automate source code analysis to ease finding 0day. Like give me those POST and GET in a summary, and find where the var is used. But that is next phase.

    How do the "backdoor checks" work? And so on.

    The backdoor checks on files are malware checks. Educating users to check for cron jobs and password resets are part of backdoor checks. Security is not just technology.

    You're asking them to trust you that you're protecting their stuff. That comes with a responsibility to get it right, and to not overpromise.

    Yes! Valid point.
    The Bounty model is where you get paid only for successful investigations. Never have I mentioned any guarantees of any sort. If someone wants data reliability and guarantee, use Backup Sync to push an archived copy to their own storage.

    I think there are different ways to take these reviews as:-

    • You should add this x security to your service
    • This xy would be a better addition and so on
      None of you have used or tried my service fully and have already jumped to conclusions. If you were to really give feedbacks, it would have been what the platform could have to make it better.

    All services start with a free trial. I can only answer questions.

    @jsg

    The reason. He uses PBKDF2 because that's what web2py comes with

    Yes, why would I change the default auth and break the whole default session management of a framework that has been tried and tested for so long? There is lot more work and testing to these changes, which can shift my focus.
    For the likes of hosting environments, I reckon that this is enough.

    Plus he seems to not mention the iteration count which can make a killer difference.

    1000 iterations

    one does not use debian

    Debian install with openssh comes with minimal set of binaries and kernel. Besides, this can also be deployed on any *nix os. I just have the automation ready for Debian install and verification. My next choice would be Arch linux and then look at OpenBSD.
    I indeed was looking at OpenBSD, but it does not really add much. May be openbsd can help stack protection.

    One suggestion that I can take from this is to run this service along with existing hosting backup services.

    Running a free service is definitely part of the plan.

    @FlamesRunner

    Remember Violasoft and Trendfire Security Essentiales? Sounds just like them

    Like I said before I have not looked any other service offering. I have built the platform addressing the problem areas only.

    I am being constantly swept down the security vendor lane.
    Yes, there are things that I can do and there are things I cannot. Do you really think the big players out there have the best security platform? Atleast, I dare to answer these onslaughts.

    Definitely! I need videos out there to show case things.

  • @bountysite

    Wait, is this intended to cover the webroot of a website, or the entire OS? I was thinking your service is just the webroot (for it to be portable to other hosts) but I'm talking about an infected server (OS) needing to be put down and reinstalled. There's thousands of files to track over GB's of data.

  • jsgjsg Member, Resident Benchmarker

    @bountysite said:
    @jsg
    ... PBKDF2 ...
    Yes, why would I change the default auth and break the whole default session management of a framework that has been tried and tested for so long? There is lot more work and testing to these changes, which can shift my focus.
    For the likes of hosting environments, I reckon that this is enough.

    But yours isn't the local bakery's website.

    1000 iterations

    That was too low 10 years ago, let alone today. But it still is the default in web2py. I just looked it up ( https://github.com/web2py/web2py/blob/master/gluon/contrib/pbkdf2.py )-
    Unfortunately it uses SHA-1 as default hash algo. !WARNING! -> That is very poor! I strongly suggest that you at least have it use SHA-256 (or even better SHA-3, which btw is not considerably slower).
    And you also should very considerably increase the iteration value.

    Debian install with openssh comes with minimal set of binaries and kernel. Besides, this can also be deployed on any *nix os. I just have the automation ready for Debian install and verification. My next choice would be Arch linux and then look at OpenBSD.

    No, debian comes with all the usual stuff (e.g. su, sudo) and a kernel that may look small compared to some of the monsters out there but is not minimal, plus debian comes with systemd and its whole apt stuff.
    You should try to make sure that each system in your operations has what it needs and only what it needs, both in the kernel and in terms of binaries. If you want both a distro with a good reputation and good security (for a linux) look at alpine which comes with something like apt ("apk").

    I indeed was looking at OpenBSD, but it does not really add much. May be openbsd can help stack protection.

    OpenBSD IMO is clearly better in terms of code quality and security but it has some quirks (e.g. no SMT and often no or only half-cooked SMP) that may make it unattractive for some jobs. Plus being a BSD it's quite a bit different from Linux so you would need to learn a lot.
    Should you go with OpenBSD? Some people out there consider anything except OpenBSD inacceptable (in terms of security), others say it's not anymore that much ahead of other OSs. I personally would not urge to use OpenBSD in most cases (although I think highly of OpenBSD). One can have a reasonably secure system based on linux but that requires a lot of effort and attention.

    But clearly what you operate with right now is light years away from being even modestly safe and secure.

    My advice: Do not argue with @joepie91 but carefully think about what he told you.

    Thanked by 1poisson
  • CConnerCConner Member, Host Rep
    edited December 2019

    My next project should really be a CMS with proper plugin sandboxing.

  • @TimboJones
    Yes, BountySite is only for websites.

    @jsg

    I strongly suggest that you at least have it use SHA-256
    And you also should very considerably increase the iteration value.

    Ok! thanks

    Debian does not come with sudo. You can move unwanted binaries elsewhere. For best community support and stability, Debian is good.
    Few years back, I do remember looking at Alpine. I wasn't sure of the community support and its backing.
    It seems it is lately gaining traction with docker due to its small footprint. Not having grsec is also a big loss for alpine.

    The opinion of restricted environment is nothing but allowing only known FTP server, which is already inbuilt as a feature for partner based setups. I think what you are recommending is to implement partner based setups only.
    Ok! Point taken

    Another key aspect to note is that the attack will have to come from a signed up user, which would be a hosting customer. Unlikely, but possible!

    The thing with BountySite storage is that I can design custom storage nodes depending on customer requirements. I have already spent sometime looking at OpenBSD before. I will revisit this and add as an option to storage solutions. Infact, I am looking at adding bsd based nodes too, as an option.

    therefore extremely worrying to me. A service like this shouldn't be your personal learning environment

    The best aspect of BountySite is providing users with ample information to fix on their own. BountySite is like a DIY tool for malware removal. BountySite is not a have and forget tool. Since, everything is going into a git revisioning system, I can say that I dont need any level of expertise whatsoever for malware removal part. The expertise is needed only in building intelligent signatures to catch malwares which will only come in live environment. Hence my point. Just being brutally honest here.

    Site owner is the best security administrator for their own website. BountySite is like a Site File Integrity System. I initially thought of having site owners report malware on their own, and it would automatically apply/report for other site owners(like "This file has been reported as malware by 100 other users"). But this would mean trusting site owners, which could lead to false positives.

    Regarding multi user setup, one way of implementing is with LXC and using custom templates. For every customer(not website), an unprivileged container can be created under a new user(precreated with LXC container[with static ip] running the job with API on port x). An API on host would need mapping as to which user is mapped to which customer, and proxy the API request to the respective container. But this would reduce the number of provisionable backups in a storage node from 20K to 1K. This is something like having a shared hosting to a VPS.
    I think I should add as a premium service.

    I just noticed that my website is missing "How it works" page. Lost it in website redesign. My bad! It would take a week to just put forth everything. I will mention all possible deployment options with its pros and cons. Sounds fair!

    BountySite's main core was ready in Jan 2018, and its being constantly tested. Yes, more and more layers of security should be added constantly. No doubt!

    Thank you for the feedbacks and opinions.

  • edited December 2019

    @TimboJones said:

    @LosPollosHermanos said:

    @TimboJones said:

    @LosPollosHermanos said:
    The absolute worst advice in the world, that I always read on these types of questions, is to wipe and reinstall. You learn nothing from doing that, create a bunch of unnecessary work for yourself, and usually only temporary fix the problem until it happens again and you will still not know how to fix it properly.

    ** You learn a lot from tracking this stuff down and surgically removing it. I mean all of it**, including the alternate backdoor stuff they sometimes put in to try get in again if you find their primary access.

    One of the first things you learn by doing this is that hackers are lazy and usually not that clever. Some things that may not be obvious to them as an outsider with malicious intent is obvious to an admin. Like datestamps. If you know approximately when it happened you can do a search for datestamps and maybe figure out what the first file was that was touched.

    To clarify, "wipe and reinstall" should always be part of the solution, just AFTER finding out how it got in. Trying to and thinking you have successfully removed an infection is... dumb and prone to missing something. It's trivial to make an obvious infection to make user think they found the problem and the hacker just hid something else in there. They just need to cover their tracks a bit, which decent bad actors have been doing for decades.

    So,
    1. Find out how it got in
    2. Wipe
    3. Reinstall

    To be quite blunt about it, if you rely on wiping and re-installing as part of your security policy you should not be in this business or need to hire yourself a proper IT person. That's my opinion.

    Of course if your setup allows you to easily do that and get back to where you were before with mimimal effort then sure why not. But then you probably aren't really doing anything all that involved to begin with. I would think most things would still require quite a bit of re-configuration afterward. I suppose it depends on what you are doing.

    That's not a reliance, that's being certain. Kill it with fire. You will never be able to say with 100% certainty that you found and removed the infection, therefore it's permanently suspect and unsecured. Your ego that you found and removed 100% of the infection is being counted on for missing hidden backdoors. Don't guess, be certain, especially if it's not just your data. You don't come off as a surgeon, just lazy and willing to take unnecessary risks.

    Why not do both?

  • https://www.theregister.co.uk/2018/09/15/alpine_linux_bug/ proves that minimal is not always secure. Honestly! not sure what to make out of the advice.

    I gave a good thought about everything and I have decided to go in for a major overhaul.

    • I definitely need a lighter, faster and simpler UI. Aargh!
    • It seemed like a long road to reach this milestone. But, as a company I cannot take even a 1% chance. grsec being expensive, I can only look at OpenBSD or FreeBSD
    • I added a lot of features which I am going to cut down. Do one thing and do it well and keep it simple philosophy!
    • multi user backup is a definite necessity
    • optimize code to increase scalability and security
    • optimize rule engine and detection

    @LosPollosHermanos
    My initial idea "One Threat One Dollar" was to run off a hosting server. The idea was to charge 1$ for every detected vulnerability. Basically, compute hashes(md5, sha256, fuzzyhash) and put everything in db.
    All you do, is run a query to detect vulnerable code. For eg search for filename xxx.php with a vulnerable code snippet in fuzzyhash, to detect a vulnerability or search for a sha256 hash of vulnerable code file.
    The problem with this concept:-

    • Site owner does not care about detecting vulnerability, but fixing it
    • Hosting market is very competitive. "Nope! I dont want to run anything on hosting server"

    So, BountySite approach was to:-

    • backup websites(not trust cpanel or local hosting backups), to give site owners easy fix to sites
    • use git to be able to assess malware code and be able to restore back to any point
    • very minimal or no impact on hosting server
    • run all computes, offsite
    • be Hosting Platform independent
    • provide php patching for proactive security

    Your question is what if a website hack gets elevated to higher privileges and how to detect server level backdoors?
    The industry is mostly using CloudLinux to mitigate Cross Site Contamination like attacks, and KernelCare to upgrade kernel without reboot.
    This technique would help but wont be enough. The malware could be running off memory and not be present on the file system. There is already a hash database(I think OWASP file hash db) for carryingforensics.
    I wont be able to manage server side security like websites. There is lot more.

    I want to focus on proactive security patching and vulnerability detection off source code, for websites.

  • edited January 2020

    Proactive security patching and vulnerability detection is fine if you truly understand what you are protecting against. The only way to truly understand is dig into it rather than just re-installing or applying patches someone else made.

    "Sometimes the correct path is the tortured one."
    --a line from Draft Day

  • @LosPollosHermanos Agree totally!
    In most cases, upstream patch is enough or better, notify site owner to perform website update. Only in case of a zero day, a quick fix patch will be offered, which can only be done on fully understanding the vulnerability.

Sign In or Register to comment.