The commands themselves don't seem particularly concerning - they're a few random-looking searches for particular substrings.

However, if your shell history has unexplainable entries, that's a sign that you've been hacked.

At this point, what I would recommend is to check your SSH logs to find out when this occurred (and from what IP), and secure your server - probably by reinstalling the OS, restoring your content from a back-up, and then plugging whatever hole led to the compromise in the first place (if you can identify it).

Checking SSH logs

On CentOS, SSH logs are written to /var/log/secure by default. On Ubuntu, they're written to /var/log/auth.log by default.

Here's a command that will search either of those locations for SSH log entries:

grep -i 'ssh' /var/log/secure /var/log/auth.log

You'll probably be interested in the most recent log entries, which will be at the end of that command's output.

Note that it's possible that there are no entries in the logs indicating a break-in; this could be because the attacker wiped SSH logs, but didn't wipe shell history.

Some commands that will be useful for log investigation are grep, tail, and less. Also remember that you can pipe output from one command into another. Check the manpages or the Unix & Linux Stack Exchange if you need more help with command line tools like those.


does mailto require opt-out when user sending initial request for information from website?

As mentioned by @deviantfan in a comment, your premise seems wrong.

So, suppose someone writes you askign for additional information (eg. I am moving to Finland next month, do you have a store there?). Let's assume they have dutifully read your privacy policy, which is nevertheless unlikely.

What is the opt-out you think may be required? IANAL, but it seems trivially to me that (unless there is some weird case that needs to be taken into account) you can reply to them (No, sorry, we have no local presence there).

Were you perhaps going to add that person into a mailing list so they get daily/weekly/monthly mails about your products, despite having expressed no desire for that (or only implicitly by sending you an unrelated mail)? I don't recommend doing that, but in that case, I certainly would mention in the reply that they would start receiving your spam unless they opted-out. Are you even automatically adding to such mailing list any mail that you receive? (even worse, since the email could be spoofed)

If you don't use that address for a mailing list (the most common context for including an opt-out… link?), there would be no need to state how to opt out of such non-existent mailing list. You may wish to state nevertheless that the provided data is being stored according to the regulations of EU directive 2016/679 and they may access, etc. by doing XYZ (probably not needed at all, but your legal department may wish you to include such reminder anyway).

And all of this has no relationship at all with OWASP. The OWASP Top 10 Application Security Risks, published in 2017, were

Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross Site Scripting (XSS)
Insecure Deserialization
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring

As you see, none of them is relating to opting out. You seem to be confusing two completely different lists of recommendations.


Linux, Security and Safety inside a large intranet

security does not mean or necessitate over-restrictive control, rather
  it is about understanding basic principles, following secure and safe
  practices

That is a reasonably true statement, especially when you're describing a development environment.  But be aware that the security/administrator's definition of "restrictive" is going to differ from the developer's definition!

  the Linux kernel firewall matters

On an intranet Development environment, not so much.  Such systems often require loose and flexible port access.  In any environment, maintenance of local firewall rules across any number of machines is daunting (read: breaks functionality early and often, ties the administrator down loosening it).

  the intranet's firewall matters even more

Absolutely.  With a development environment, it often needs to be loose and open internally, so the border has to be more restrictive - definitely inbound, but also outbound.

  remote root access should not be allowed, rather use of ssh key authentication

There are couple of best practices in this area which, combined, equal what you're talking about.

Direct remote root login is discouraged due to attribution issues.  Users, even administrators, should log in as themselves and su or sudo to root so that their actions can be attributed to a person, not a crowd of people with the credentials necessary to log in as root.
Remote root logins, if allowed (perhaps for configuration management software) should require SSH keys to make brute-forcing them impractical.

  Are the above and the following questions the appropriate points to
  discuss and ask, when it comes to security and safety inside a large
  intranet?

They are all good points.  However, you've missed the two most important parts of this adventure:

Patching.  Patching should be automated, centralized, and vigorously
often.
Configuration management.  Something like Puppet should be used to centrally manage the configuration of the machines and common software.

Patching is pretty obvious.  Configuration management, while less obvious, is just as important.  Configuration management means:

When you need to tweak configuration, it happens across all your
systems without relying upon you to run around doing it everywhere.
Developers who tweak their configuration (often with security
implications) are swiftly overridden and brought back into
compliance.
When you bring a new system online, it's quickly brought into
compliance with your standards, and doesn't get "missed" or left out.

  Is it a necessity or best practice to restrict a Linux user from
  having "sudo" rights in his "own" system, for the sake of security and
  safety, for protecting from outside threats?

There must be balance between security and business need.  Developers often have a legitimate need for privileged access.  To balance that need, security will often restrict privileges (e.g., sudo to particular commands but not a root shell), log for audit (e.g., bash to syslog, available in 4.1+), and limit damage to the pool (e.g., restrictive outbound access through the firewall).

  Can security and protection from outside threats be performed with a
  good set of rules for iptables and adequate maintenance of the
  intranet's firewall?

No, more than that is needed, as described above.

To quote Gary Larson:

  Is remote root access to a Linux machine, from inside the intranet, a
  safe practice?

It is more unsafe than local root access, simply because the authentication of the user responsible for running commands is lost (or, removed 1+ steps).  Requiring that privileged commands be tied back to a user, and logged that way, is necessary both in content (now you know) and consequence (developers held personally accountable are less inclined to do things they shouldn't).


Mitigating risk from electronic payments

Use an escrow service.

From Wikipedia:

  Internet escrow works by placing money in the control of an independent and licensed third party in order to protect both buyer and seller in a transaction. When both parties verify the transaction has been completed per terms set, the money is released. If at any point there is a dispute between the parties in the transaction, the process moves along to dispute resolution.

Also,

  One way to avoid escrow fraud is to use a Government Agency authorised escrow company (UK),or a State licensed escrow company (US)... The validity of an online escrow company's license can be checked with the regulating authority. Usually this is accessible through their official website, and should always be checked before dealing with an escrow company to ensure it is not a look-alike or fraud.


What is the purpose of an API Token and an API Secret?

This statement is incorrect:

  both of which are transmitted in each request

The secret is never sent. Instead, each request is signed with the secret. From the Twitter API documentation, the data that is sent is in the Authorization header is:

OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
    oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
    oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
    oauth_signature_method="HMAC-SHA1",
    oauth_timestamp="1318622958",
    oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
    oauth_version="1.0"

The documentation continues to say:

  The oauth_signature parameter contains a value which is generated by running all of the other request parameters and two secret values through a signing algorithm. The purpose of the signature is so that Twitter can verify that the request has not been modified in transit, verify the application sending the request, and verify that the application has authorization to interact with the user’s account.

As the documentation states, the signing is used for authentication and to ensure that the request isn't tampered with after it has been signed.

Another advantage of this authentication strategy is that it interacts well with stateless services.


ASP.NET does not provide a XSS API.  I suspect you are talking about Request Validation which is a feature in ASP.NET that inspects HTTP requests and looks for potentially dangerous input.  To my knowledge PHP does not offer anything like this.

While request validation can be a benefit by preventing certain types of XSS attacks, it is not a replacement for properly securing an application from XSS vulnerabilities.  This can be dangerous because it lulls developers into a false sense of security.  In addition to this, request validation can be disabled, so if you are relying on it for XSS protection and then someone else disables it, you are in big trouble.

There is a good post here that talks about some of the shortcomings of request validation in ASP.NET.

So in summary: there is no PHP equivalent of ASP.NET's request validation and you shouldn't rely on request validation to protect you from XSS anyways.


All files are just a string of bytes. An MP4 file means, depending on who you ask, a string of bytes that conforms to the MP4 standard, or that an MP4 player can do something with, or that has '00 00 00 18 66 74 79 70 6D 70 34 32' as the first twelve bytes (many file format standards always start with some fixed string of bytes so a program can look at just them to tell what kind of file it is. This is called a Magic Number). In principle you could craft a valid MP4 file with a hex editor, just typing in the bytes one by one, but since the MP4 standard is pretty complex it would be a lot of effort.

In the context of crafted exploit files, an MP4 file is one that the target MP4 player will read and say 'this is an MP4 file', before trying to process it. That might mean it has the magic number, or possibly just the extension '.mp4'. It can be crafted in any way you might create an arbitrary file, but probably by either modifying a program that creates mp4 files or taking a valid mp4 file and modifying it manually in a hex editor. Most crafted exploit files aren't actually truly valid but rather just pretending to be MP4 files (or whatever).

so,
1) He could craft it using any method of writing bytes to a file, but in practice probably did it by modifying something that produced or was a valid MP4 file already.

2) You can reproduce the bug by trying to play the poc file on a vulnerable android version (Android-7.0 Android-7.1.1 Android-7.1.2 Android-8.0 Android-8.1 Android-9. Android ID: A-130024844 apparently), or otherwise in an environment where it will be processed using a vulnerable version of Android Video Player.

3) You could put the vulnerable software in a debugger and see exactly what happens when you feed it hvec-crash-poc.mp4. Note that OllyDbg won't help you here, you need a debugger that works in an Android environment while OllyDbg is Windows-specific. From the screenshots on the GitHub page it looks like he's using GDB. I don't work with Android much so don't quote me on this, but I think the vulnerable software in question (Android Video Player) is a system service that you'd have to attach the debugger to, this will require a rooted Android (or Android emulator).


One possibility is that the connections haven't closed yet they are waiting for any delayed packets before they close completely(if they're CLOSE_WAIT(Facebook closed the connection) or TIME_WAIT(You closed the connection), these connections will typically close on their own within 5 mins.

Another possibility is that your browser keeps some tabs JavaScript running after closing because of a feature or a bug. A good test for that is to look in your task manager for anything related to your browser.


Will enabling SMB protocol authentication prevent Ransomware attack like WannaCry spreading in network?

An exploit is making use of a vulnerability to perform an unintended action.
So an exploit may execute code without going through an authentication flow or a variety of other actions. This is why regular patching and not using software that is no longer supported is so important.

Authentication is only useful if the software does not have vulnerabilities that bypass it - with SMBv1 this would be the popular eternal blue.

As for your particular issue there are a couple versions of SMB if you are on version 1 then you are going to need a few extra security controls to address your requirement to use an outdated protocol.

It would be worth costing up an upgrade of your systems and compare it to potential losses or costs for the additional controls.

Note its important to understand that being just within your own network is not a satisfactory control for outdated SMBv1 as seen with latest Upnp issue making the rounds


What are the risks of a self-signed client certificate?

What you are doing there is basically becoming your own certificate authority - which is fine, as long as you accept the risks associated and/or mitigate them.

In this scenario you can safely base your servers trust in your own certificate to issue client certificates as long as you are fine with your own CAs method of establishing trust in the users identity.

I’m not too sure let’s encrypt will give you a certificate that has the CA attribute set (i.e. can act as a certificate authority). While you might have the key for the certificate, that certificate does not allow signing certificates itself.

Certificate revocation should be handled internally (your server should know which certificates should no longer be accepted) at least; you do not need to provide CRLs if you only use the CA internally.

You can also establish a 1:1 connection between user and certificate, replacing the revoked certificate with a new one should be fine then.


Using Random Numbers As Session variables

The best way to generate random tokens for security purposes in PHP is using openssl_random_pseudo_bytes() to obtain some random bytes, and then bin2hex to make them printable.

$token = bin2hex(openssl_random_pseudo_bytes(16));

You can safely use $token for your session identifier, CSRF tokens, etc.


Does periodically rebooting secure-boot-enabled devices improve security by preventing persistent compromise?

Periodic rebooting does very little to improve device security in general.

Secure boot is designed to protect your system from attacks that target the boot process, e.g. the part of a computer's uptime where the operating system can't yet protect the system, because it's not loaded yet.

Once the operating system is loaded and running, it becomes the OS's job to protect the system. So... secure boot protects you from someone sneaking into your home and hiding a software keylogger somewhere deep in the boot process. But it can't protect you from attacks that target a security hole in an application or the operating system itself. If, for example, you visit a website that infects your browser with malware, which then installs itself in the system without being detected, this malware will still be there when you reboot. secure boot can't protect you against this.

There are only three cases in which periodic reboot would improve security:

When your computer gets infected with transient malware which only runs in memory and doesn't install itself into the system. A reboot would
wipe such malware from your system.
If you have a system that runs entirely from write-protected media and provides only ram drive storage. In that case, rebooting will also wipe the malware.
When your computer gets infected with malware which tries to install itself into the computer's boot-process - secure boot should detect this malware, and the sooner you reboot, the sooner you know.

I'm not sure whether malware which attacks firmware (e.g. military-grade cyber-weapons which attack the BIOS or hard drive firmware etc) would be in any way affected by secure boot. I'm thinking that malware which could alter a computer's firmware would be undetectable and could disable secure boot alltogether if it wanted to. Maybe someone can comment?


With whom does my PC communicate at startup?

Here is a suggestion for your case.
You need an extra laptop with both cable connection and wifi connection. You, then bridge the two connection and enable the Internet Connection sharing function from the cable to the wifi. By that way, your laptop's wifi become an access point.
Next, you install Wireshark on this computer and set it to monitor the wifi interface. You now connect the computer that you want to monitor to this access point and log all the packets. You will know all the IPs that your computer talks to.

Since you mention Tails, I also suggest that If you have some time, you can have a look at this paper:(A Tor-Based Anonymous Communication Approach to Secure Smart Home Appliances). In the paper, there are some experiments done exactly in the manner that I just explained above with WireShark.


Would this form of more seamless e-mail confirmation be secure?

Ah, but the user is "clicking a link in the email". It just is an "automated click". The danger in "clicking a link in the email" does not come from the physical action of pushing the button, but from the downloading of data from a link found in the email. If this downloading occurs automatically, the risk is not reduced; quite the contrary, in fact. Most emailing software offer, at least as an option, a possibility not to automatically download pictures; this is an improvement because it, at least, gives a way for the user to prevent the download to occur (namely, by not clicking).

In that sense, your proposal is equivalent to a click-in-email system, and shares the same security issues. At best, it improves user experience, in that it removes the physical click in the cases where the user is careless (i.e. his software follows image links automatically). To some extent, what you suggest boils down to: "yeah, user is vulnerable, but at least we can leverage his vulnerability to make his life easier; he cannot be protected, but let's fill his world with blissful ignorance instead of dread".

Now, if you take the server's point of view, the system indeed guarantees that whoever received the cookie in his Web browser is also able to read the emails sent to the specified address, since the browser followed the image link from the email. You should still make sure that the link in the email contains a non-guessable random component; otherwise, an attacker could simply get the picture by typing the link in his browser, thus simulating reception of the email. As usual, even the best security systems contain enough room to totally botch them, if implemented without due care.


Principle of asymmetric algorithm in plain english

It's like one of these:

Say you want to secure something in a box. Anyone can close the lock (public key). This means anyone will be able to put something into the box and lock the box (they won't be able to open the lock once it's locked (you just pinch these closed)). The key to open the lock is something only you have (private key). You are the only one that will be able to open the lock and see what's inside the box.

I suggest you buy on of these to demonstrate how they work.


If you didn't create the keypair and never had the private key, then it's not your key; it's a fake that was created by a third party. Anyone can create an OpenPGP key under anyone's name without their consent and upload it to the public keyservers. The fact that this was done by your former employer is irrelevant (unless it means you can contact them and ask them nicely to revoke the key).

The real solution to this problem is the web of trust: your genuine key should be verified directly by your contacts and/or signed by others that they trust (and whose keys they have verified). If your contacts don't understand this, your private communications with them are already doomed, as they will be easily fooled when a malicious man-in-the-middle provides them with a fake key.


Is a debuggable android application exploitable from another application?

Probably not.

First let me clarify "physical access" that you mention. It's adb shell (which can be accessible over TCP as well, if configured so; but normally it requires access to USB, and physical user to use touch screen), and for debuggable apps, one can use run-as to change their UID to that of the app (and do anything as if they were an app). run-as is limited to root and shell GID, so plain apps should not have access to it.

There might be mechanisms similar to run-as, but one would expect similar security restrictions.


Does ARP or DNS spoofing play a role when performing MITM in fake AP attacks?

ARP Spoofing is mostly the basis of MitM Attacks. It is used to redirect the traffic initially. This is done by fooling the victim into beliving that your MAC address is associated to the routers IP address. This is called ARP-Spoofing or ARP-Cache poisoning.

DNS Spoofing is used to target specific sites. For example if you created a fake site that is looking like the one of a local bank you will then send fake answers for the associated domain to redirect the traffic to the site you controll instead of the original one.

Bypassing HSTS is done by manipulating the clients time setting. This can be done by manipulating the NTP traffic the client receives. There is a stand alone tool to do this called delorean. This will not work when the site is listed on the HSTS pre-load list.

I also had different experiences with different tools. For example arpspoof and bettercap did work great for me while ettercap did nothing but cause trouble.


How does malware become executable code?

Many of the questions in the original post have already been asked and answered elsewhere on this site. Entire books have been written on some of these topics.

  I'm a software engineer and I still don't understand how malware works or what an exploit actually is in software engineering terms.

If the definition of what an exploit is in the context of computer security is not clear enough, it may be helpful to look at examples of exploit code.
exploit-db is a good resource for this.

  File formats like HTML, JPEG, MP3, PNG, BMP, etc, are all read by another piece of software and so should only be able to do what that reader allows it to do. Something that reads a JPEG file can basically light up pixels using certain RGB values in a display window; there's nothing in the JPEG spec that says "create a .exe file and put it here in the file system and then execute it". So how do they corrupt a JPEG file to achieve that? Why would a legitimate JPEG reader have the capacity to execute arbitrary code on a PC, and how would those bits get written to the PC?

How to inject executable, malicious code into PDF, JPEG, MP3, etc.?

How can normal files hide a virus?

Is it possible for a file that is non-executable and read-only to run malicious code?

How can a virus exist in an image?

  Modern programming languages don't even do direct memory access with pointers like we used to with C in the 80's and I assume that the "buffer-overrun" vulnerabilities that existed in the old days are a thing of the past with modern OSes and hardware memory management. So even if I wanted to, I don't know how I would write bits into a block of memory I didn't have legal access to, and even if I managed to do that, how would I trick the OS into treating those bits as executable code and execute them?

Stack Overflows - Defeating Canaries, ASLR, DEP, NX

  So how, exactly, does a nefarious website create executable code on a modern PC with a modern OS?

How can a modern Windows/Linux system be compromised by a heap overflow in Chrome?

Browser Exploits: Attacks and Defense

The AnC attack

CWE-94: Improper Control of Generation of Code ('Code Injection')


Any security vulnerability using filenames generated from database?

Even though I only half agree with you on an attacker having access to the DB not being worth protecting against, I would still say that this is not a big issue for a couple of reasons:

Since the include is client side and not server side, you do not risk exposing any sensitive files that are not already exposed. Had it instead been a PHP include() you would have bigger risks, since it can reach files that can not be reached over HTTP.
Probably only files on your domain can be included (but using /../ could let an attacker traverse to other directories). But if you have an open redirect vulnerability on your side it could be used to include files from other domains. That would be dangerous.
As I understand it, the user can only set their own language. So even if this was exploitable it would be hard to "deliver" the exploit to other users.

But still, there is no reason to take unnecesary risks even if they are small. This can be easily defended against:

Validate the data in the application layer, so the user can not set a language that is not on your list of languages. So if they try setting ../evil_javascript.js it will fail.
Make sure only country codes can be stored in that database column, e.g. by using a foreign key to a languages table or perhaps a check constraint. This way, you know a user can not sneak in any strange values even if the validation in the application layer should somehow fail.
Then validate the data as it comes out of your DB. You could make a check like this (but perhaps with nicer error handling):

if(!in_array($lang, $language_list)) die("Unknown language!");

Or just doing this would take the teeth out of any attack:

<script src="<?=$home_url?>/languages/<?=substr($lang, 0, 2)?>.js">

This might seem a bit execive for a low risk thing. But at least the first and second point is good practice anyway, even if you don't take security into consideration.


Bank sends one-time password by e-mail (while sending on SMS) for transaction verification; is this insecure?

Multi-factor authentication (aka two-factor authentication) is more secure than simply using a long-lived password.  The one-time password that sits in your email account will be useless if (1) you don't have the account password/secret key (or other factors required to login) or (2) the one-time password has been used once.

Yes, it is bad advice to send long-lived passwords via email or SMS (as email is often transferred between mail servers unencrypted and may be eavesdropped on -- say by malicious sysadmins -- and email is commonly stored on your desktop unencrypted).  However, it is common practice to send one-time passwords that are useless on their own without other factors.  In fact it's provably stronger than not requiring the other factors.  There are potentially better ways to do multi-factor authentication than potentially insecure email (e.g., company issued physical tokens though it's probably not feasible for every bank to issue separate physical tokens to every customer and expect most customers to keep them secure and not lose them).  Bottom-line, requiring an extra factor to demonstrate ability to read messages sent to your email address or phone number is stronger than not requiring it (though it would be a bad idea to allow someone with only access to your phone or email address to easily get full control of your bank account).


Generally speaking, cascading algorithms is rarely a good idea. Cascading works very well at making software more complex and less responsive, which is hardly desirable. The usual "justification" of cascading is that it should somehow (possibly magically) resist complete breakage of one of the algorithm, but not of the other. In practice, this is not so, for several reasons:

There are several ways to "cascade" and they do not do the same thing. For instance, if you have hash functions f and g, and you want to protect against preimages, then cascading as f(g(x)) might work; but if you want to protect against collisions, that's f(x)||g(x) which makes sense (i.e. concatenation, not composition). People who request cascading rarely think about what they actually want with sufficient depth in that respect.
Let's face it, this is not 1938 anymore. The algorithm itself is never the weak point; what's weak is how it is (mis)used. Cascading is like looking at a steel door on a wood cabin, and claiming that it should have an extra, heavy padlock in addition. It is a great and time-honoured way to avoid dealing with real security issues.
In the specific case of password hashing, there is one glaring weakness, which is the password itself: passwords are guessable. So we want slow hash functions, and we defeat the attacker by putting more CPU into it ourselves (i.e. we increase the number of iterations, so that the hash is as expensive as possible; the attacker's advantage becomes how much more CPU he can muster when compared to the honest server). The server's CPU is his line of defense. Cascading means wasting precisely that lifeforce, just for the fuzzy feeling that it will make things more resistant to fabled cryptanalytic breaks.

So no, don't cascade. At best, it will just make your life harder. More often, it will more or less directly decrease security.


Can I prevent Active Directory from accepting common passwords?

There are well-baked drop-in replacements for passfilt.dll that provide more granularity (and doing so is supported by Microsoft). I'm not affiliated, but products like nFront and Anixis PPE give you a lot of options, including blacklisting common passwords.

You can also code your own replacement, but that's probably harder than using an existing package.


Is it safe to have a TrueCrypt container file synced with DropBox?

NO, it is not safe. Truecrypt uses the XTS block mode for encryption, which has severe problems when your adversary is able to see snapshots over time of how the data changes. In fact, an article called You Don't Want XTS, intended for software developers to learn when they can and can't use XTS, specifically uses Dropbox as an example of when NOT to use XTS. It would not be the end of the world, resulting in your password being disclosed or something, but it does bring out the worst in XTS.

To quote the article:

  Again: XTS works like ECB. It’s deterministic. If you’re looking for the penguins, they’re there, but you have to look for them across time instead of space: successive writes to the same sector-block location will repeat, but encryptions of the same plaintext at different locations will be randomized.

This means that hosting it on Dropbox which will see changes over time will "see the penguins". This also makes it extremely easy to tamper with data in predictable ways. While XTS does not have the same crypto malleability issues as, say, CBC or CTR, it still has some, giving them much greater capabilities than any other attacker:

  But whatever margin of safety XTS gets you on physical media probably goes out the window when you stick a Truecrypt volume on Dropbox. From the vantage point of Dropbox, attackers have far more capabilities than the XTS designers planned for.

If you need to host encrypted data on a remote server, you may want to look into duplicity, which in fact supports Dropbox natively. It provides client-side encryption, is very fast, uses incremental, revisioned backups, and signs all transfers. This makes it so that, not only is tampering impossible, but any change to data on the server is in the form of data being added, with the exception of clean-up operations. It's a very useful tool for syncing with remote servers.

I am disappointed that there are already two answers claiming that this is just fine, with no background in cryptography, assuming that because Truecrypt provides confidentiality, it should be completely fine to sync Truecrypt to. They are giving dangerously incorrect advice.


Hydra gives right password if used after 3 minutes else gives wrong passwords

I Have figured out the issue. Hydra considers 401 as the Fail Response and 200 as the "Success" response. It also considers 403 as success response. My IP-Camera is smart enough to identify that hydra is trying to bruteforce. At the start, it returns 401 for the wrong passwords and 200 for the correct password. If I try again immediately, it figures out that something fishy is going on here and responds with 403 instead of 401 (Hydra takes 403 as a success response). If I wait for 3 or more minutes, It starts responding with 401 again.


HTTP + HTTPS + One Time Pad/stream cipher

You are talking about encryption only; you are forgetting about integrity, an often fatal mistake. Encryption protects you only against passive attackers, who can spy on everything everybody says, but can alter communications in no way. That's not a very realistic model. You need verified (i.e. keyed) integrity, and for that you want a Message Authentication Code. Or one of those nifty Authenticated Encryption schemes.

Now, a protocol which begins with a potentially expensive initialization step, resulting in a shared secret, which is then used to encrypt data an protect it with verified integrity... that's not easy to build without making any mistake. Fortunately, one such protocol already exists, with all the hard bits done the right way, and implementations already available. It is called SSL.

As @Rook says, SSL is very lightweight once the initial handshake has been done. A typical HTTPS client (say, a Web browser) will first open a SSL connection, and then keep it open for sending requests. An open SSL connection implies a very slight overhead compared with raw unprotected data: in practice, about 30 extra bytes per record (it depends on the cipher suite), each record able to hold up to 16384 bytes of data, so we are talking about less than 0.2% of size increase, and you would get that with any other protocol which ensures confidentiality and integrity anyway. On the other hand, your handmade scheme doubles the network consumption (the one-time-pad is not exactly free to send).

Moreover, even if the SSL connection gets somehow closed (e.g. because the server does not wish to keep any connection open for more than 15 seconds of inactivity), a new one can be reopened with an abbreviated handshake which reuses bits of the previous handshake; in particular, it requires less messages (so reduced latency), it is symmetric-crypto only (so light on CPU), and it involves no certificate whatsoever, so it is simple and sane.


Has anybody successfully decrypted their files after paying the WannaCrypt ransom?

Yes, some have apparently gotten their files decrypted after paying the ransom.

  We have confirmation that some of the 200+ #WannaCry victims who have paid the ransom have gotten their files back. Still, not recommended.

(tweeted by Mikko Hypponen, CRO at F-Secure, on May 15, 2017)

But there is absolutely no guarantee to get yours decrypted after paying and chances seem to be pretty low, especially since it's not an automated process but requires interaction with a human operator. Security researchers strongly recommend against paying the ransom.


Command Injection DVWA (1.0.7 iso version) High Security level

The code snippet in your question is actually from the impossible level, not high. I'm not sure which one you're trying to beat.

The high level uses a blacklist approach:

    $substitutions = array(
        '&'  => '',
        ';'  => '',
        '| ' => '',
        '-'  => '',
        '$'  => '',
        '('  => '',
        ')'  => '',
        '`'  => '',
        '||' => '',
    );
    // Remove any of the charactars in the array (blacklist).
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

There are a few ways to beat high, however at a quick glance the impossible level might not be beatable without additional bugs. You could still beat it via something like shellshock on an older system though as it forks to run ping.


How are calls or SMS used to exploit a smartphone?

I think you are talking about Stagefright(CVE-2015-3864, /exploits/39640). It resides in Stagefright, an Android code library that processes several widely used media formats. It affects all Android phones upto version 5.1. It was first reported by a researcher of the company Zimperium. The vulnerabilities are extremely dangerous and extremely rare. It allows the attacker to compromise the victims phone without the user even taking any action, no authentication is required, you just have to know your vitctim's phone number, Android showing you a preview on your unlock-screen is enough to trigger the exploit and thus allowing to execute arbitrary code while you sleep and the day after the SMS is deleted and your phone is still compromised without your knowing, The attacker does this by sending a crafted massage that contains the arbitrary code mostly in the form of a MP4-video, the crafted SMS is in the MMS format which was found to be very useful in this process of exploitation.


What is this compromised-looking result under the google.co.uk main search result?

I think it's kind of Easter Egg of Google.
If you change language code in hl parameter to xx-hacker then you will get 1337 speak at many places on result.
It's safe


Using DOM-based XSS to redirect to different domain or execute script?

This snippet of code does not have an XSS flaw but it does suffer from parameter splitting.  It allows the user to specify extra GET parameters which can allow escalation of privileges when the request carries credentials such as a CSRF token in an earlier parameter or authorization cookies.

For example, if userControlled is

&start-world-war-iii=true

then the browser will GET /abc/xyz?param=&start-world-war-iii=true with the user's cookies.

It's probably low risk since assigning window.location leads to a GET request which rarely have side-effects that can be abused by the carried credentials.

To mitigate this, userControlled should be normalized:

window.location="/abc/xyz?param=" + encodeURIComponent(userControlled);


Is a cookie safer than a simple HTTP header?

Cookies are HTTP Headers. The header is called Cookie:, and it contains your cookie.

But cookies are in fact safer than URL parameters because cookies are never sent to other domains. URL parameters, on the other hand, will end up in the Referer: header of any site you visit directly from the one with the URL parameter.


How can empty USB sticks contain malware?

I'm afraid this stems from a misunderstanding from the reporter:

  ... said a device that appeared to be empty could still contain a virus.

In the video the reporter's referring to it is clear, in fact, in the first two minutes Karsen says he's NOT talking about viruses. He then goes on to demonstrate, on screen, that the seemingly empty USB device is changing itself into a different device (e.g. emulating storage as well as a keyboard and playing keystrokes), as was alluded to in my previous answer (below), but I had not at the time reviewed the full resource to establish it as conclusive evidence.

So there you have it, the author somehow misunderstood the video presentation, and BBC published it...

  How can "empty" USB sticks contain malware?

This question doesn't form a clear picture.

Firstly we must define "empty".

Do you mean unformatted? If this is the case, can we just erase the first sector to unformat a storage device, leaving the rest of the bytes intact?
Could there be viral code in those unerased, yet technically unformatted bytes?
Do you mean looks empty when inserted? There have been numerous tricks for hiding files in the past, such as storing them in the recycling bin, using the 'hidden' or 'system file' attribute, using NTFS streams or even unsupported partitions. Delving further down the rabbit hole, is the drive empty but encrypted? A flaw in a major cryptographic library (we've seen those quite a lot recently) could expose the system to covert side-channel attacks, even from a seemingly empty device... Additionally, some USB sticks are bootable (on some systems; we'll get to that later), implying that you might be able to write a boot sector virus to infect them. Boot sector viruses don't really care what OS is installed, since they execute before the OS boots anyway... This leads me to your next question:

  Is this only a problem for (legacy) Windows systems?

No. We should consider what constitutes "malware". It's possible for an arbitrary sequence of bytes to be considered malware because it causes damage to one system (e.g. x86/x64 machine code on an x86/x64 prcessor) but not another (e.g. the same bytecode on an ARM/SPARC). To answer this question, we only have to find (or design) a system that decodes the arbitrary sequence as malware, even though it previously wasn't.

  Is there some way to use these sticks while protecting yourself?

No. Finally, consider the definition of USB stick. Is it possible that, instead of plugging in a storage device, you might be plugging in some kind of electronic bug, such as a wireless keyboard adapter or a USB thumb killer. Such devices themselves don't really constitute malware, either because they're not software or they weren't designed to be malicious... though they could nonetheless be security risks. It might also be possible for a device to access memory (e.g. by appearing as a charger for your mobile phone and then stealing all of your photos, videos, etc using the data line or a covert wifi network).

Don't insert untrusted USB devices. Period. They might not contain malware, but that isn't the only danger... especially in this day and age where competition, electronic sabotage & surveillance are all the rage.


Renaming it to something, then shoving that name into robots.txt just shows an attacker what directory you want to protect. Think of the following: "I will put my jewels into the third drawer, but leave a sign for a robber that says: 'don't look in the third drawer!'"

Your real option to protect you here, is to place an .htaccess file in the directory you DON'T want accessed, and in that .htaccess file, ONLY give yourself the option to view that directory

Order Deny,Allow
Deny from all
Allow from 127.0.0.1 (where this is your IP)

Or you can add mod_security and add a similar re-write.


yes
yes
If the decryption key is in the memory, then you will be able to find it if you have access to the host.  The reason that the decryption key is in the memory is because you need to store it somewhere to use when you need to decrypt/encrypt something from/to the harddisk. You can't store it on the harddisk, so that leaves you with the memory.
not really, it's the hosting provider that needs to make sure their systems are hardened
I have no experience with Windows, but just changing the shadowfile (linux) and insert a password you generated yourself for root (the hashing is the same on every system) and you will be able to log in. Most of the time it does involve shutting down the virtual machine to access the virtual disk. But I imagine on containers like LXC this would even be easier.


What password based key derivation does PKCS #12 use?

The first paragraph of RFC7272 appendix B, which is the second paragraph in original [RSA PKCS#12v1.1]
(http://www.emclink.net/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf),
recommends that PBES2/PBKDF2 from PKCS#5v2+ be used, but this is only 'should'
(not even RFC2119 upper-case SHOULD) and the scheme of appendices B and C (all in B in original)
can be used, and is used by the specific OID you quote.

Note RFC7292 as published has two typos in B.2 step 6 A, (only) one of which was previously errata-ed.
I have reported this to the rfc-editor and they will fix the erratum;
until then you should use the original v1.1 (or v1).
Or alternatively the code in a
working and available implementation like OpenSSL (or its forks) or NSS or Java.

RFC7292 C (or PKCS#12v1+ B.4) says

  The PBES1 encryption scheme defined in PKCS #5 provides a number of
     algorithm identifiers for deriving keys and IVs; here, we specify a
     few more, all of which use the procedure detailed in Appendices B.2
     and B.3 to construct keys (and IVs, where needed).

As stated, these schemes derive both the key and the IV if needed (which it is for 3TDES-CBC),
using different 'diversifier' inputs as described in B.3 and referenced in B.2.

In contrast PKCS#5 PBES1 derives both the key and IV from a single PBKDF1 operation,
while PBES2 uses PBKDF2 to derive only the key; the IV if any is chosen separately,
and carried in the parameters field of the AlgorithmIdentifier for PBES2.


What point in Authenticator App 2FA when SMS fallback is enabled

You need in Appenter link description here 2FA, see the attached image as an example in gmail.
Above most operators are installing SS7/Signalling firewall to ensure that subscribers are secure from SMS interception and redirection attacks.


SMS Authentication: random OTP or a cryptographic one

If done properly, time-based one-time passwords will be reasonably secure. That's a bigger "if" than usually assumed.

What would work would be the following:

Decide about your time granularity, e.g. 5 minutes. All dates considered here will be a multiple of that granularity (i.e. 8:05:00, 17:25:00... but not 16:34:00).
Generate a secret symmetric key K of appropriate size (16 bytes straight from /dev/urandom, CryptGenRandom(), java.security.SecureRandom or System.Security.Cryptography.RNGCryptoServiceProvider, depending on your religion).
When generating a one-time password P for user U at time T, compute:

P = encode(HMAC/SHA-256(U || T, K))

which means that you "concatenate" the user name and the current date into a custom structure (XML, ASN.1, text-with-separator... whatever fits your bill, as long as it is deterministic and non ambiguous), over which you compute a MAC, using specifically HMAC with SHA-256 as underlying hash function, and K as key. The encode() function is something which truncates the output of HMAC and encodes it into something that can be displayed on a phone and typed in by a user.
You send P to the user. At time T' (presumably not long after T), the user comes back and enters a password P'. You then recompute the value of P for time T' and for time T'-5min, for the same user U. If either value matches P', then authentication succeeds, otherwise it fails.

The tricky points:

You must not truncate "too much". The attacker may want to try his luck and send a random password; the space of possible passwords must be wide enough to make such success highly improbable.
You can use any "encoding" you want as long as it is deterministic and mostly uniform. For instance, interpret the HMAC value (a 256-bit string) as a big integer (in the 0..2256-1 range) and take the remainder of the division of that integer by 100000000; you can then represent that value in decimal (left-padded with zeros if necessary), to get a nice 8-digit password. The remainder operation is the "truncate" and it will be sufficiently unbiased in this situation. If you prefer 8 letters, divide by 268 and use base 26 to represent the remainder.
The granularity is linked to the security. Note that upon verification, we try exactly two passwords (we need that, because the password must be valid even if the user gets his SMS at 11:34 and enters it back at 11:36). This divides by 2 the difficulty for the attacker: if passwords are 8-digit sequences, then there are 100000000 possible passwords, but the attacker has probability 1/50000000 of success. A granularity of 5 minutes means that a one-time password is valid for 5 to 10 minutes. If we want to make this lifetime more precise (e.g. 5 to 6 minutes) then we must lower the granularity (e.g. down to 1 minute) and accept more passwords (for T', T'-1, T'-2... to T'-5) which raises the success rate for the attacker (here 1/16666667). There is a trade-off here: more precision implies less security. In my opinion, it is best to keep security high and to tolerate password lifetime to freely vary in the 5-to-10 minutes range.

Note that this question granularity is precisely the point where security of time-based passwords departs from that of randomly chosen passwords. As explained above, you need to accept N successive passwords for some N (at least 2), and the chances of success for the attacker are N times as much as what he would have for a random password of the same size.
For multi-frontend systems, the key K must be shared because the server which receives the first request and generates the password is not necessarily the same than the one who receives the second request and must verify the password; but both must use the same key. Also, all frontends must have the same notion of time (use NTP).
The key K needs not be permanently stored; it is acceptable that it does not survives reboots, since the generated passwords are short-lived anyway. You could generate K when the server starts (this means that a password sent by SMS before the reboot will not be accepted after the reboot, which is probably no big deal). Mind, though, that transient keys can be a hassle with multi-frontend systems (the frontends must somehow use the same key).
You want to add some guard mechanisms to avoid vandal attacks: people who ask for one million authentications for a given user U. User U does not want to receive one million spurious SMS; and you certainly do not want to pay for the sending of one million SMS (these things ain't free). One possible countermeasure is to use the SMS-based password only as a second authentication step, after having verified the user's principal (non moving) password (or whatever is your first authentication factor in your two-factors system).


Let me answer with a few observations, and comments. I will begin with the "whodunit" approach of aiding in determining who, what, when, where, and how.

What - a file you found on your system
When - what date was it found
How - how was it uploaded
Who - who uploaded it

You already know the file because you found it. Let's call this file: malicious.php. What you mention doing is determining "who" accessed this file, but you need to figure out how it was uploaded. Looking at the who accessed this file is the wrong approach. This is because attackers usually use multiple attack points. E.g., one system may scan you, another may compromise you, and yet another may access the system one compromised. So let's figure out the who first using deductive methods:

$ ls -ltha malicious.php
-rw-r--r-- 1 www-data www-data 0 Mar 27 10:59 malicious.php

In this instance, we see the file belongs to user www-data in group www-data. This does not mean an attacker uploaded it via http using post or get. There is nothing to stop someone from exploiting say telnet, uploading a file and performing a chown on the file.

ls -ltha --time=atime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 10:09 malicious.php
ls -ltha --time=ctime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 11:00 malicious.php

We can see the differences in timestamps here. If someone used say timestomp (Metasploit) MAC times can be changed. So we can deduce on the data above, that we are more or less within the 50 minute realm. Let's ensure that this user has never logged in, for that we can check wtmp, auth, ftp logs, etc. If this user has never logged in, we can then infer that this was not uploaded in any other fashion outside of via HTTP.

When - we reduced the timeframe to a degree to a 51 minute period. The logs I would look at would be error logs FIRST followed by access log. The reason for this is simple, at no point in time would an attacker know exactly how to get a file on your system. This means, there was a trial and error recon. This will be in your error logs appearing as a 404 or 403. I would search those first. Now let's further reduce the searching. A log analysis of visits will show what is normal versus what may be an anomaly. For example, if the base of traffic goes to say index.html remove all those instances, and look at the anomalies. One you determine this, you have then determined the How. This is completely separate from figuring out how they compomised your your code which would be a completely different question.


Can a file be extracted from a folder with only execute permissions?

It takes only a few lines to test and the answer is clear: if the user knows the name of the file he can still read its meta data and content as long the permissions of the file itself allow it:

$ mkdir x
$ echo foo > x/y
$ ls -l x
total 4
-rw-rw-r-- 1 user user 4 Nov 21 18:44 y
$ chmod 0100 x
$ ls -l x
ls: cannot open directory 'x': Permission denied
$ ls -l x/y
-rw-rw-r-- 1 user user 4 Nov 21 18:44 x/y
$ cat x/y
foo
$


What is the most secure way of decrypting a GPG message within a non ad-hoc OS?

How can I do the same within the OS I am currently running

You can't.

However, you can come pretty close.

For example, under linux, you can make sure you're using an encrypted swap partition with a random key, so that if your computer swaps memory pages out to disk, they can't be retrieved once you power off.

Then you can decrypt the message on /dev/shm, which is a ramdisk; e.g. files stored there only exist in RAM and get automatically wiped once you cut power to your computer, and if you do an rm * on /dev/shm, the files are immediately lost. Note they might persist in RAM, even if no longer visible on /dev/shm, though.

This isn't foolproof, but unless you're specifically targeted, it should ensure your decrypted messages don't end up on your hard drive.


Command Injection when all dangerous characters are escaped?

I came up with a bypass.

As @Sjoerd mentioned, backslash escapes don't work in single quoted strings, so it's possible to get out of the single quoted string.

Your list of 'dangerous' characters does not include backticks, or hashes; which allows a payload such as this one to work:

' `hostname` #

Or urlencoded:

%27%20%60hostname%60%20%23

The single quote becomes \' (which is treated as a regular quote, and '\' becomes the first argument to echo), the command in backticks is executed with the command output passed to echo. The hash is treated as a comment and causes the shell to ignore the trailing single quote, avoiding a syntax error.


Why not have an identical session cookie for different user's devices?

The problem

Imagine the following scenario: Alice logs in to your site on her computer at home, and stays logged in. Later she logs in on a computer at school as well, but signs out when she is done. What happends when she gets home?

To make this system work, you would need to set the cookie column to NULL on logout. But that would log her out from all devices. That would be very annoying if you for instance want to stay continously logged in on your phone. So as long as you actually invalidate sessions server side on logout (you should always do that) this is more of a usability issue than a security issue.

Solution #1

So what would your table structure look like if you allowed multiple sessions per user? First, drop the cookie column from the users table. Then create a new table called sessions like this:

+------+------------------+
| user |     cookie       |
+------+------------------+
| 1    | ojer0f934mf2...  |
| 2    | ko4398f43043...  |
| 2    | 34fjkg3j438t...  |
| 3    | 0243hfd348i4...  |
+------+------------------+

Note that the second user has two different active session.

There should be a timestamp in there somewhere also, so that you can terminate the session after X hours. Even if you have a max-age on the cookie, you should always terminate sessions server side as well to mitigate the effects of session theaft.

Solution #2

No need to store session identifiers in a database. Just use PHP's built in session handling and you will not have to worry about generating ID's, setting cookies, etc.

Signing out from different devices

Conserning your edit about how to let Alice log out from school if she forgot to do it: Include a feature that lets her log out from all devices. Facebook, for instance, has a feature like that. Or if you don't want to waste energy implementing that, just instruct users to change their password - a well implemented password reset function should terminate all the users active sessions anyway.

In the database setup, ending all sessions would be the equivalent of running this:

DELETE FROM sessions WHERE user = :id


openssl problem decrypting passhrase-encrypted file using the derived IV, Key and Salt

Just to be clear, as the answer you reference points out openssl enc is quite terrible and was never intended to be used for anything other than testing.

The problem is with inconsistent formats. If you encrypt with a password, it will use the 16 byte Salted__ header that includes the salt used in the key derivation. If you use the key and IV directly there is no need to specify a salt, and it won't use the salt header. Since you encrypted with a password and later retrieved the key and IV, you'll need to strip off the first 16 bytes before decrypting.

$ echo test | openssl enc -aes-256-cbc -pass pass:password -base64
U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=

$ echo 'U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=' | openssl enc -aes-256-cbc -d -pass pass:password -base64 -P
salt=E1996C9D0F4597E5
key=90C6AF89C13459AD5F55B9CD72705249BC494F4539D2FA75B4C6E5B343D7FDB2
iv =3D29E6F33CBBDA72B6757B5078003B53

$ echo 'U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=' | base64 -d | tail -c+17 | openssl enc -aes-256-cbc -d -K 90C6AF89C13459AD5F55B9CD72705249BC494F4539D2FA75B4C6E5B343D7FDB2 -iv 3D29E6F33CBBDA72B6757B5078003B53
test


It's not a "security flaw" in the sense that something is broken or that the flickers indicate a bug or an attack. Rather, it's an issue with the underlying graphic stack of Linux and the lack of semantics for privileged desktop clients.

Just to get this out of the way, the flicker is most likely caused by a poor interaction between your GPU drivers and GNOME Shell or whatever built-in Wayland compositor there is in GDM. It's completely unrelated to security.

Now onto why you see your desktop below the lock screen...

Historical situation

X11, the protocol and graphic stack server used on all Linux systems, was not designed with the ability to isolate windows from one another effectively, and both the original X11 protocol and a number of extensions to it make it possible and easy for apps to spoof authentication UI dialogs and steal input from other clients.

Traditionally hence, lock screens are merely programs that:

spawn full screen, on top of all other windows (by using specific WM options on their window
grab all input (in practice, they can go as far as binding every single key combination on your keyboard to ensure all input events are dispatched to them first)

At this stage you could open a TTY and kill the userland process that grabs the input and covers the screen, and you could probably try to pop some other window on top of it (but it couldn't receive keyboard events). Also note that in X11 keyboard events are not properly dispatched when there is a menu open. So if you can spawn an app and make it open a menu, you might be able to prevent the lock screen from getting input. So far so good.

The most obvious security flaw that comes to mind is that graphic stack servers / compositors have no way to identify whether a specific window is a lockscreen, and whether a specific window claims to be a lockscreen but isn't. This is also a problem on OSX and Windows 8, and I've discussed it before at XDC. The only proper protection against lockscreen spoofs is to use 2-factor authentication.

Less acceptable forms of protection are secure attention sequences (Windows's Ctrl+Alt+Del) or special lockscreen-only capabilities that are hard to spoof and easy to identify (off-screen yet visible indicator, fullscreen only for lockscreen, etc.). In other words you need a trusted path between the user and the OS that triggers the lockscreen, and you also need the lockscreen to authenticate to the user.

Did GNOME-Wayland change anything?

Sadly not as much as it should have. You now have much stronger guarantees, thanks to Wayland's protocol for input dispatching) that your legit lockscreen will not have its input stolen away from it. But you have no way to determine whether it is your actual lockscreen that's in front of you.

Why? There was a strong incentive for GNOME to be the first to "implement" Wayland, and so they just copy/pasted some of the poor, insecure X11 protocols (in particular, selections, methods for accessing special hardware, for binding global shortcuts and accessing fullscreen). Lockscreens are easy to spoof without the requirements I've set up above, and the GNOME Shell developer(s) have not implemented counter-measures. I've discussed this topic privately with one of them and have come to the conclusion that they are not interested in discussing any cross-desktop defences to graphic stack security vulnerabilities. I was told they will solve all underpinning security issues with custom methods that will be somewhat better, at some point in the future.

There is no agenda set for such work to be done and no evidence that it will be carried out. Red Hat's security engineers being busy working on app sandboxing and Docker-related stuff, it's unlikely they will have any manpower to tackle desktop security issues any time soon, and now that the code is implemented and used in the wild, it's even less likely that someone will want to re-change the Wayland APIs. Worse yet, other DEs might want to follow GNOME and leave some APIs unsecured for the sake of not modifying toolkits or desktop apps again.

Last time I spoke to them, the KDE folks were interested in building 2FA, so there might be a workable, less insecure lockscreen for Linux desktops a few years away from now.


What is needed to secure a docker container that's running on nodes in an AWS Private Subnet with internet access only via NAT?

The security configuration required for a specific environment depends on your threat model e.g. who do you expect to attack you, what level of access will they have to your environment, so providing specific hardening instructions for Docker containers could be hard without that detail.

At a generic level I'd recommend reviewing the CIS Benchmark for Docker  to see which of the recommendations there make sense for your environment.


Cisco SNMP Tool is a tool that allows you to:

Telnet to Host
Reboot device
Upload Running & Startup Configuration
Download Running & Startup Configuration
Reset Passwords
Write NVRAM

Just make sure you have permission before doing anything on the router.


Is there a security reason to require email address and password in separate steps?

The main reason might be neither, but the ability for conditional authentication steps. Some services e.g. support multiple single-sign on (SSO) providers, and the username is required to pick the correct SSO to forward the user to. Some may even have different authentication methods altogether. From security and privacy perspective this is also a bit problematic, as it may reveal whether a user exists or not.


What to do after a scammer took control of my mac?

That depends on what she did
I know you don't have more information, so I'll just just briefly go over what steps you should do in the future:

Obviously re-install the OS completely. If you have backups of files in some device that was not attached during the infection, you can recover the files from there. If the device was attached, it is a greater risk.
Monitor her credit card statements closely. A lot of scammers who try the tech support scam try to get people to buy overprized hard- or software from them, often via credit card. If she gave out her credit card details to the scammers, then she should contact her credit card fraud hotline, explain the situation and ask for their advice.
If she gave out personally identifiable information, she may be subject to identity theft. I don't know what to do in that situation, but this website of the US government covers the topic.
Speak with her about tech support scams and scams in general. We all fall for scams at times, but it's important to learn from our mistakes.


Two-Factor Authentication: When is it worth it?

Answer:
Two factor authentication is worth it when one form of authentication is not enough or when it makes sense to have an added layer of Security.

An Example of Two Factor and Why we need it
For example (a tried and true), an ATM Machine. If someone swipes your wallet then they could go to town on your bank account if ATM Machines did not require a pin. If someone figures out your pin through some kind of passive attack then they are still forced to get your card somehow. The What you have is usually called a token.

Minutiae of getting Two Factor right
Important to note is that 2factor authentication requires authentication of different kind. In my example, Your ATM Card is Something you have while your pin is Something you know. Also note there is a throttle set on pin attempts. You can only attempt to put in your correct pin n number of times before you become locked out.

Further Details
I think it is totally worth it to have two-factor authentication on your email account. Two-factor authentication makes it really difficult for someone to guess your password without also stealing your token. It certainly can't hurt and it has actually become fairly convenient. Facebook/Google both can text you a pin number. I think that's pretty damn convenient (as long as you don't register your google accounts 2factor phone number to your google voice account...).  The reason that password authentication isn't enough is all the bad practices people have managing and creating passwords. Weak passwords and passwords stored in plaintext (like in firefox) makes it really easy to put yourself in a bad situation if time are careless.

When should YOU use it.
Like many things in life this is simply a tradeoff. If you think you value the added security over the burden of needing to authenticate twice then you absolutely should use 2fac. On your personal email? Probably. On a junk email or a forum account you don't care about then probably not. It really is that simple.


Is it a good idea to preventive use a robots.txt that disallows all search engines to index query strings in order to slow down reconnaissance?

No, this adds no real security value.

Depending on the approach of your attacker, the first thing he might do is fingerprint the server and libs and do a crawl of the whole site himself (that's what I would do if the point is to find a vulnerability in the code).

Crawling a site like this is extremely trivial (and easily automated), so the gain is negligible. Also, in the afore-mentioned scenario, I would not use search engine data as I would want to be sure that the stuff I'm working on is "the real deal", not a cached version from some hours, days or whenever ago.

Finding parameters is 0.001% of the job. It is exploiting them that is harder. Slowing hackers on that task has no added value.

(Also, you would lose value SEO-wise but I understand that this is not your concern)


Please help diagnose multiple incoming packets

looking at the traffic pattern, It's a clear SYN Flood attack, a type of DDoS attack which is still prevalent and used by a lot of threat actors. Recently, even Google and Cloudflare DNS servers were affected by this and more on this at https://sissden.eu/blog/darknet-attacks-on-google-and-cloudflare-dns

From remediation standpoint, if your service is critical for your customers, you may try looking at DDoS mitigation providers like Incapsula, Akamai etc. They offer dedicated services along with automated scrubbing technologies which can handle various types of DDoS attacks.


I am not aware of any problems with the use of proxychains-ng and Nmap, but to be sure that Nmap is not trying to do any raw socket or packet capture operations that are incompatible with proxychains-ng, you should use the --unprivileged option. Additionally, since version 6.40, Nmap has supported proxies natively with the --proxies option, which covers the -sV option and NSE scripts, but not the host discovery, port scan, OS scan, or traceroute functions.


How to safely display external pictures?

I think the most important of this question is breaking the paradigm: "Images are innocent". Images are not innocent, and are very dangerous, take a look on this article: "Stegosploit hides malicious code in images, this is the future of online attacks".

The short answer is: Creating a new image file and storing it in a static environment, without execution permissions is a safe way to display eternal picture. But I would like to go a little deeper.

The method described above is used by Facebook, and other sites with Twitter and Google plus. When you share an image link, they create a kind of "proxy" to protect your page from external intervention. Keep in mind that malicious code could be a javascript sending all key press events to a host to capture information like your credit card numbers with secure code, your password or something else.

For example, Google plus creates a new link to access this file:

https://lh3.googleusercontent.com/proxy/X2NOfJnTtrux8w_5sczYpXHckBLOYKCTJj3p3Zhpf6bnreayAnU7bMNGrHpjvRmfDHWP9oMln_Od5Oxdilarc8AACg=w346-h192

This method is more expensive because you need the proper infrastructure to store this image.

Services like Imgur can provide a safe API to upload file with safety in low costs. This image below is the same image used in my example (end of this answer), the Imgur creates a new image removing all disposable content.

A few months ago I got a problem, I have a website with a service that allowed people publish your image and put it just to use your external links. One day, I discovered a lot of images used to create a kind of DDOS attacks, every visitor redirects the access to a domain, that domain has a lot of other "iframes" redirecting their views.

I'll share a piece of this code, if you can give any contribution to it, please do it..

$filename = "http://s13.postimg.org/f7728bnqv/php_logo_virus.jpg"; //Unsafe image in a external hosting(this file executes a php_info();)

/* Remove path information and dots around the filename, to prevent uploading
 * into different directories or replacing hidden system files.
 * Also remove control characters and spaces (\x00..\x20) around the filename:
 *
 */
$safefilename = trim(basename(stripslashes($filename)), ".\x00..\x20");

/Try to get possible reall extention by imagem type

$tempSafeFile = tempnam(sys_get_temp_dir(), "JLC"); //Create a Temp File to store content in a static env.
//Must have PHP GD lib do execute Details: http://php.net/manual/en/book.image.php
switch (exif_imagetype($safefilename)) {
    case IMAGETYPE_JPEG:
        $safefilecontent = imagejpeg(imagecreatefromjpeg($safefilename), $tempSafeFile, 100); //Get only file content created a new image and storeing it on my tempfile
        $extensions = array('jpg', 'jpeg');
        $mime = "image/jpeg";
        break;
    case IMAGETYPE_PNG:
        $safefilecontent = imagepng(imagecreatefrompng($safefilename), $tempSafeFile, 100);
        $extensions = array('png');
        $mime = "image/png";
        break;
    case IMAGETYPE_GIF:
        $safefilecontent = imagegif(imagecreatefromgif($safefilename), $tempSafeFile, 100);
        $extensions = array('gif');
        $mime = "image/gif";
        break;
    case IMAGETYPE_BMP:
        $safefilecontent = image2wbmp(imagecreatefromwbmp($safefilename), $tempSafeFile, 100);
        $extensions = array('bmp');
        $mime = "image/x-MS-bmp";
        break;
    //There is a lot of other image types... I use this 4 just for a example
    default :
        throw new Exception("May its a unsafe image file!",500,null);
        break;
}

// Adjust incorrect image file extensions:
if (!empty($extensions)) {
    $parts = explode('.', $safefilename);
    $extIndex = count($parts) - 1;
    $ext = strtolower(@$parts[$extIndex]);
    if (!in_array($ext, $extensions)) {
        $parts[$extIndex] = $extensions[0];
        $safefilename = implode('.', $parts);
    }
}

//Now you can save, move, store this file in a safe place or just display it:

header("Pragma: public");
header("Expires: -1");
header("Cache-Control: public, must-revalidate, post-check=0, pre-check=0");
//header("Content-Disposition: attachment; filename=\"$safefilename\""); //Download instead
header("Content-Type: " . $mime);
echo file_get_contents($tempSafeFile);
exit;

Full code here: https://gist.github.com/LeonanCarvalho/8064a5d66b990b1dafc9

We know that there are no miracle cures, but you can hinder the discovery of the breach.
With my negative experience I could observe the following good points to make the external display safest images:

Create a new image file based on previously
Store the file in a safe, static environment, separate from the application environment.
Use external services to store a new image.
Limit image size. Large injected codes may create a "large file"
Remove Image metadata and Use some image compression resource
Check mime type
Use a proxy service (Here 2 good projects: https://github.com/atmos/camo  & https://github.com/willnorris/imageproxy)


I think this is a reasonable approach, as we have seen countless websites being hacked and millions of passwords being stolen. Using a two-factor authentication mitigates the risk.

Depending on the security level of your installation, a hardware based OTP is not needed. Software-based OPT, like Google Authenticator, will suffice in most cases.

You can use Google Authenticator for Android, iOS, Windows Phone or Windows.

There are libraries for use it in PHP, Perl and ASP. You can even use it with SSH.

Besides being cheap (users generally already have a smartphone), software-based tokens are harder to lose, as it requires the user to lose or factory-reset the phone. Those cases can be solved by sending a reset link to the user, asking for some other information to authenticate the user, like a secret question, phone number or any other piece of information that is hard to guess.


Using plain-text phrases as public/private pair?

You cannot use arbitrary strings as private/public key pairs. These needs to be generated according to the math specifics to the PKI algorythm you use (RSA for instance).

You could, however, create an application that uses the same workflow as you described but uses PKI for encryption, as long as you're ready to make some tradeoffs.

First, it starts with a typical asymmetrical encryption (use a standard library please: don't try to code one yourself): you app uses the sender's private key to sign the data and the the receiver's public key to encrypt it. The trouble is that, quite often, you don't have access to a validated public key for the receiver.

To solve that, you  have all users generate their own key pair (or pairs) and register the public key(s) on a common platform (a key server). This should include some form of user validation in order to make sure the key really belong to the security principle that is associated with them or you run a risk of someone registering a key with an identifier that doesn't belong to them.

So, when a user needs someone's public key, it can request it from the key server (over an authenticated, encrypted channel) as needed.

Of course, the devil is in the details: building such a system is extremely hard: you need to have a validation system for the keys that is both efficient and practical. Also, you need to take into account the fact that users will routinely lose their own keys, forget their passwords, change their email, etc. The key servers needs also to be extremely secure and, at the same time, operated in a transparent manner because anyone controlling them also control everyone's communication (they could replace any public key by their own more or less transparently).

All these "little" details are extremely hard (and expensive) to solve so unless you have a LOT of resources available, you'll probably be better off with sticking to simple symmetrical crypto.


Do Linux systems need antivirus against ransomware?

There are actually multiple parts of the question:

Is Linux affected by malware and especially ransomware?
Do antivirus products exist for Linux?
Do these products help against this threat?

To answer the first:
Yes, there is malware for Linux and there is also ransomware. Currently it is usually propagated in a different way compared to Windows: Malware on Windows is mostly distributed by phishing mail and web and makes use of platform specific vulnerabilities and features, i.e. currently mainly windows scripting host, macros in office documents and vulnerabilities in Office. On Linux systems instead it is usually installed by attacking the server, often by using security issues in Wordpress and other CMS. But this is mainly because server use of Linux is large while desktop use is still rare. The capabilities and vulnerabilities needed to spread ransomware in a similar way to Windows do often exist on Linux too although some differences (like the need to explicitly set the permissions of executable files) make some exploits harder.

As for the second, i.e. are the antivirus products for Linux:
There are both free products like ClamAV and commercial products available.

And finally, do these antivirus help against malware/ransomware targeting Linux?
They mostly don't. These antivirus products care mainly about protecting against attacks targeting Windows and are usually used to scan files or mails which might be served to Windows systems. Thus they are for example useful on a mail server or file server and also on a web server to make sure that the server is not used to spread malware. But they don't even protect fully against attacks targeting Windows. They might have some code in it to detect some well known (and sometimes only proof of concept) malware against Linux but they will not protect against new things. There are also products which scan for traces of existing system compromise and sometimes these are called antivirus but often not.


There are constant scans being performed all over the Internet constantly. These scans include crawlers that follow every link that they can find. I am not surprised at all that you had someone access a link you created, even in such short a time.

From the few details you provided, I do not see any reason to believe that someone has unauthorized access to your server. Your server is public and anything you post is public, too.


Risks of running Honeypot [specific setup]

As long as your router has its access rules to not allow any connections from your honeypot to the rest of your network then that should work out fine. Only allow connections from the management network or IP addresses to the linux VM host and honeypot, that way if either is hacked it won't be able to attack your network directly.

Make sure there's no information on the linux VM host or the honeypot that can be used to attack your network. Don't use the same usernames or passwords, and don't store any information on them at all.

Also, hopefully you've given us fake IP address ranges, otherwise you're enumerated the IP Address ranges you use on your network in which case I'd change them.


There's currently no support for arbitrary iteration in hashcat.

The iterations that hashcat does support are either only exactly as shown in the hash type:

2600 | md5(md5($pass))
4500 | sha1(sha1($pass))

.... or else - for the subset of hashes that natively support it - as embedded in the hashes themselves (rounds=10000, etc.)

It sounds like your salt is only concatenated once, not on every iteration? If so, you can concatenate it manually - and then you only need to find a tool that has support for simple iterations.

If you know enough C, you could add your rounds to the appropriate hashcat module.

You can also do arbitrary iteration with MDXfind, using its -i parameter.

$ cat test.hash
2f9b999e6ec7fe0964bc3827baf33eda331f154056c9c9686bcd77c5395ec597

$ cat test.list
PASSWORDPARTsaltpart

# MDXfind hash type (-h) is a rough regex filter, so you have to anchor the regex
# at both ends to only include exactly that hashtype (and not other hash types
# that happen to include the string 'SHA256')

$ mdxfind -h '^SHA256$' -f test.hash -i 10000 test.list
Iterations set to 10000
Working on hash types: SHA256
Took 0.00 seconds to read hashes
Searching through 1 unique hashes from test.hash
Maximum hash chain depth is 1
Minimum hash length is 64 characters
Using 4 cores
SHA256x10000 2f9b999e6ec7fe0964bc3827baf33eda331f154056c9c9686bcd77c5395ec597:PASSWORDPARTsaltpart

Done - 1 threads caught
1 lines processed in 0 seconds
1.00 lines per second
0.01 seconds hashing, 10,000 total hash calculations
0.85M hashes per second (approx)
1 total files
1 SHA256x10000 hashes found
1 Total hashes found


"Do not enter your password unless you recognize this image" - how does this work?

I presume this to be form of mutual authentication. You're being displayed an image you had selected earlier. This way you can trust the incoming data from being original service provider. I am unsure for the effectiveness of the same especially in an MiTM attack.


Is it possible to un-spoof a spoofed caller ID?

When a call is placed into the PSTN, three different numbers are associated with it.

The standard caller ID: this is analogous to reply-to: in an email. This can be anything the user desires, and the name is matched from an external database.
Calling ANI: This is the phone originating the call, it typically has to be a number on the caller's account.
Charge ANI: This is the number that will be charged for the call, or whose carrier will be reimbursed for a toll-free call. This number is always a number on the caller's account. (except in cases where it is empty, like skype free calls in the past)

Consider the case of an executive making a call without assistance.
Caller ID: +1 (123) 555-0102 - Secretary's number, who should handle return calls.
Calling ANI: +1 (123) 555-0112 - Executive's direct number, the number making the call.
Charge ANI: +1 (123) 555-0130 - Company's main call in number, the account that will be charged for the call.
However, only the Caller ID is sent to the end user, unless the call is toll-free, or the callee subscribes to ANI from their provider.
It is also worth noting that a user can dial a feature code to have the call
'traced', and diagnostic information retained, but a court order is required to access this information (and possibly ditermine the true source.) However the customer is charged for the trace even if no investigation is made by the authorities.


This SSL certificate covers dozens of sites including raw.github.com, *.etsy.com, pypi.python.org, etc. Is this safe?

The reason the certificate is invalid for cnn.com is because cnn.com is not on the list, perhaps due to delays in processing CNN's signup for Fastly. Its not because certificate is revoked.

I see a huge security risk of this, and this is if the CDN operator creates a agreement with a untrusted individual.

Lets say Phisher creates a account with Fastly.
He creates a phishing domain like lhglfglhggddlghd.com and does the neccessary agreements with the CA to add the domain to Fastly's certificate.

Then he uploads a github phish login page to the CDN, and it possible gets a url like lhglfglhggddlghd.com/fe9f667fe9fe6f8ecd7a93332326768

Then he sends out a phish email with:
raw.github.com/fe9f667fe9fe6f8ecd7a93332326768

and people will 100% fall into the trap since both the domain and the cert will match up and even a computer savy person will think its genuine.
(Note that CDNs are often using anycast, and they must optimize their servers well, so often they don't even implement any host: checking, instead they just give each resource a unique URL)

But I think that they have mitigated the issue by implementing a strong KYC before signing someone up as customer for Fastly. Eg, only well vetted, good companies that have a business-need of using Fastly as CDN will be accepted as customers.


What information can WiFi devices leak without actually connecting?

Mr. Paranoid's device will do two things to scan for networks: passively listen for beacon frames and send probe requests to a null BSSID. The second technique is active and therefore detectable. Windows 10 (1611) and iOS 8, for example, randomize the MAC addresses used in these probes to decrease the ability to track users, but one could certainly detect that someone was probing for APs.


More than one admin required on site to login to a database/resources


Separate server between web server and database server

This sounds a bit like "Turtles all the way down". I think it depends on how you tier your application and webservers and how your application is designed. In most environments I've seen there are multiple tiers (which are segregated by eachother):

Loadbalancer
Web tier (generally manages SSL/TLS and static content as well as caching)
Application tier (this runs your dynamic content)
Database tier (generally sits in an isolated database segment)

This is a common architecture. My assumption is that he's thinking if your web-tier (closest to the internet) is compromised that you wouldn't be able to directly compromise the database as there is an app-tier in between.

The reason some consultants assume this is correct is because there might be different technologies used. For instance your web server maybe running on Apache Webserver but your app-tier may be on SpringBoot.

It is a similar story where people tell you to get two brands of firewalls after eachother, just in case one gets compromised.

Is it a good pattern? It is. is it fool proof? Probably not. I think it's something you can consider, but review whether it makes sense financially to add these tiers versus the risk you are running. Depending on the nature of the data and the cost involved re-engineering you may choose not to follow his advice.


What is the difference between $200 and $1,000+ Firewalls?

One of the biggest and most important factors between firewall hardware is maximum throughput and typical latency. Low-cost firewall hardware usually has a maximum throughput of less than 100Mbit/sec even though the network adapters might theoretically support more than that. This means that the firewall becomes your network bottleneck in many scenarios. Determining the throughput of your firewall involves more than just looking at the port speed.

Processing data quickly requires fast CPUs, high-speed interconnects and plenty of fast RAM, and very high-quality network adapters. Just the hardware alone for a firewall capable of passing data at 1 Gbit/sec with minimal examination can put you up in the several hundred dollar range. Furthermore, the more examination you do on passing traffic, the more CPU power and memory you consume. Adding complex filtering logic will significantly increase the CPU and RAM utilization. And any resource exhaustion will result in delays or dropped packets.

Doing stateful packet inspection and particularly application-level protocol logic is possible even on a $60 home router, but the performance impact at high utilization would be severe.

The interface for your hardware is generally not a major expense, but since most people equate the quality of the interface with the quality of the hardware in general, companies with deep interest in the survival of their product generally will put some extra effort into making the interface easier to use. At least, that's the theory. Sometimes companies like Juniper and Cisco make me doubt that assumption.

Also bear in mind that some companies build an entire business around not only providing firewall hardware and software, but also in providing regular updates to the OS, the filtering rules, patterns for spam and malware, and so forth. If you want that kind of service, you have to help pay the salaries for the people who provide it.


How does binary code execution vulnerability work on a modern OS?

The execution of the Binary Assembled instructions works by exploiting the vulnerability in the Application Program.For example inserting malicious code into a PDF,if there is a flaw in the PDF Software the Code from the Data Section can be executed.

Now coming to your question.As far as i know after 8086,Intel  started employing 4 levels of protection.The inner level is for Kernel Level processes and the outermost level is for User Level Processes.There are separate stacks for both the processes but the Memory space is shared.
A user level process(caller) cannot directly perform a privileged task,it needs to call a trusted code that does the work for the caller.But for the user level process to call the trusted code say  to write a data item X,it should have the permission to do so(indirectly).

There are some exploits commonly called as Trojan Horses that allow the User Level process to use a Trusted Code to do stuff it is actually not allowed to do.

So if the Application program itself has vulnerabilities,combining that with such exploits can get the desired code in execution.


Opened port leads to a collection listing

What is this port open for/what is it?

From Apple's support site TCP and UDP ports used by Apple software products:

  8443  - TCP - iCal service (SSL) -  pcsync-https
    Mac OS X Server v10.5 or later (JBOSS HTTPS in Mac OS X Server 10.4 or earlier)

Thus, it looks like a calender service which explains names like .calendarsystem_version.

  Would it be a good idea to close this port?

This depends if you need this service or not.


What's the goal behind signing a CRL with an old certificate key?

Correct.  There is no reason to invalidate all issued certificates when a CA decides it needs to re-key - that would simply cause chaos.  As such, all those extant certificates need to be managed throughout their life-cycle.  In order for clients to continue to carry out revocation checking on any of these certificates the CA must continue to sign a CRL with the original key-pair; as well as a sign a new CRL with the new key-pair.

The CA will now be signing multiple CRLs and clients will need to access the correct version.  Therefore the crlDistributionPoint extension on certificates signed by the new key-pair will have a different URL to the certificates signed by the original pair.  For example, Microsoft's ADCS appends a (n) to the filename for each re-key, where n increases by one each time.


List of valuable folders for preventing their deletions

Any path could easily be something the user doesn't want to delete. The user should not run your tool on a folder if that folder should not be deleted. Probably it is enough to always warn "THIS WILL DELETE ALL FILES IN /path/given/by/user, ARE YOU SURE?" and then rely on the OS (either through file permissions or access controls like SELinux) to protect them from anything stupendously dumb.

This does of course assume your app doesn't require superuser access to run, so that it will normally only be running as a normal user.


New trend? Recognizable and specific subject in Spam / malware mails

This is not new over a few weeks. I have been dealing with these across dozens of orgs since October 2019. The account is compromised, and a reply is made to an existing email thread.
What is common to all of the ones I have seen is that they include a button (or link) that is supposed to allow the user to access encrypted content or "the rest" of the content. It's the button (or link) that's the threat and it is the code that allows for the compromise.
This button has a name: RGB Button
In one org I look after, I had done a wave of special awareness campaigns and special messages on RGB. But the CFO in one org clicked the button and their account was compromised. When I sat down with him to hear his story, he said that he had been corresponding with a supplier, who told him that they would send documents shortly. 20 minutes later, the RGB Button email came through. Without any need for suspicion, and since many vendors use special file hosting services, he clicked the button. It was perfectly reasonable for him to do so in that context.
The subject line is just a factor to reduce the target's resistance. The threat is in the email body or the attachment, and that's not new. So don't focus on the subject line, focus on the threat and focus on supporting your users when it's perfectly reasonable for them to interact with a phishing email.


Strategies for preventing Social Engineering attacks on my Facebook app

You didn't state how big is your company or how many people will have access to the Facebook account, so I'll try to answer based on the rather broad information you provided.

First of all - Social Engineering in general isn't too hard to prevent, it all comes down to the training you give to your staff. Teach them that they're not supposed to provide any secret information - account names, passwords, security questions, etc to anyone without receiving your permission. Here's an article that discusses this topic.

Second of all, as was mentioned in the comments - don't use an everyday account. Create an account that will be used purely for managing the page and known only to the staff that are supposed to manage the Facebook app.

Finally, you need to enable as much security as possible. Use a complicated password (I actually wouldn't recommend a Password Manager here if multiple personnel can access it, as that increases the likelihood of one of them being victims of social engineering) with upper case and lower case letters, numbers and special characters (see Computerphile's recent videos on this, they do a good job covering the topic). Also, enable two factor authentication when logging in to the account.


How do you change the password of an IoT device like a DVR box?

What does it mean by credentials

A lot of devices like this will have a main interface and a web interface, which you normally use to update the device or check status. This usually has a login, which uses the creds described above. Examples of devices like this I have seen left using default credentials:

Cameras
Printers
Routers / APs / Switches

The problem is that if someone can get to the admin interface they can configure the device to do whatever they like, or install backdoors, hence the advice to completely reset the device and start from a clean slate.

Part of the appeal of these devices is that they can be used in a plug and play way, you just connect to the WiFi and they work, the problem with this is that it is very easy to not change the default password.


Strange bug in ModSecurity with the rule 950901

I haven't looked at the debug logs yet to see how these config settings work, but I think your problem is the "SecPcreMatchLimit" and "SecPcreMatchLimitRecursion" settings being enabled in your CRS_10 file(s). I've recently enabled them and see similar matches in our logs. It's about the only config settings I've changed after updating ModSec binaries.

Either try setting the numbers very high (100k-1M to start), or disable (comment the lines out) and restart Apache. (I'd recommend disabling.)


How should I tunnel arbitrary protocol traffic over HTTPS?

Why not look into stunnel?

This will allow you to tunnel a protocol over TLS/SSL. You will need a public endpoint on your Linux box at home to listen on port 443 and then you can connect to what you need through that.