Monitoring system calls (in a reliable and secure way)

On Linux, you can reliably monitor a selection of system calls or file accesses with the audit subsystem. Make sure the auditd daemon is running, then configure what you want to log with auditctl. Each logged operation is recorded in /var/log/audit/audit.log (on typical configurations).

You'll find simple examples of auditctl usage on this site, on Server Fault, and on Unix Stack Exchange.

strace or associated programs using ptrace are reliable ways of monitoring system calls, but I would be wary of using them on a malicious program. I couldn't tell you how off the top of my head, but it should be possible for a monitored program to make the right ptrace calls to evade monitoring.

Note that a malicious program could spawn a process that is not audited and can execute code that won't be logged. For example, it could use mmap to write to a file without the file contents ever appearing as the arguments of system calls, make this file executable and spawn a process executing it. The spawned process can typically break the process tree with something like ssh localhost. If you audit all the processes executed by a given user (as opposed to only a single process and its descendants), you'll be able to log everything.


Which is the easiest secure file transport protocol to implement (SFTP, FTPS, HTTPS, FTP over SSH, FTP over IPsec)

If you have OpenSSL then use SSL/TLS: the protocol which is simplest to implement is the one which is already implemented. SSL just offers a raw tunnel, so you would have to include some kind of management protocol which organizes the actual "file transfer", e.g. HTTP. HTTP within SSL is known as HTTPS: that's standard, so the hard work of specifying the protocol is already done.

Without OpenSSL, I would still personally recommend SSL/TLS for the following reason: I have done it (SSL client and server for embedded systems, each fits in less than 20 kB of code). So I know it is doable. Also, there are other SSL/TLS libraries targeted at small systems, e.g. CyaSSL or axTLS.

Reimplementing the SSH protocol should not be awfully harder than reimplementing SSL, but the SSH specification is bigger (it begins at RFC 4251, which describes the architecture, and the actual protocol is spread over several subsequent RFC; on the other hand, SSL/TLS fits in the single RFC 5246). That's obviously a not-very-objective way of choosing a protocol, but it is not totally uncalled for either.

For SSL/TLS, I suggest the following:

Use TLS 1.2 and do not bother with previous versions (you control the client and the server, so you can enforce a specific version). TLS 1.2 requires the implementation of only one hash function, while previous versions required both MD5 and SHA-1.
Use a single cipher suite (e.g. TLS_RSA_WITH_AES_128_CBC_SHA256). This simplifies things quite a bit and allows you to hardcode things like block size or MAC length.
Use RSA key exchange and arrange for your system to be the "client": this allows it to use RSA in encryption mode only, which is notably simpler to implement than decryption. Also, the client needs not store an asymmetric private key, which is good since secure key storage is difficult.
Do not try to decode certificates. In normal SSL/TLS, the server sends its public key to the client as part of an X.509 certificate chain; the client is supposed to validate the chain with regards to a hard-coded public key. Just cut the middle-man, and hardcode the server public key in the client (X.509 certificate chain validation can be done -- even in 6 kB of code -- but it is utterly tricky).

Either way, without a crypto library on hand, you will have to reimplement a few basic algorithms, and that's known not to be easy (especially if you want to avoid side-channel attacks, which are always a concern with embedded systems). You will also need access to a cryptographically secure source of random number: on a pre-boot system, this may prove difficult. But it is extremely important for security.


Is it possible to track someone by sharing a youtube link with timestamp?

Yes, you give someone a unique timestamp, and then that URL can be tracked with the timestamp like an ID value.

But you would have to be able to track URLs, too.


What security attacks is my simple cart system open to?

As the commenters have pointed out, you've got some essential work to do (move everything to HTTPS, make the cookies Secure and probably also HttpOnly, etc.) and should avoid reinventing the wheel if possible. Also, you're at risk of all kinds of standard web application security vulnerabilities (cross-site scripting, cross-site request forgery, clickjacking, SSL stripping, etc.); you'll need to be careful of those.

A few specific issues that jump out at me while reading your description:

SQL injection. If you're looking up the cookie value in a database, that's an obvious injection vector. Use parameterized queries / stored procedures, or at least make very damn sure you validate the cookie's contents before checking the database (don't rely on sanitizing/escaping the cookie; better to just drop it on the floor if it is even slightly incorrectly formed).
Token prediction. You describe the cookie value as a hash (though I'm not aware of any hash function with a 70-character digest even in hex encoding); what are you hashing? Is it something that an attacker might be able to predict, like some combination of constant values and maybe a sequentially-increasing ID value or the like? If two people have the same things in their cart, are their cookie values the same? If not, what distinguishes them?
Session fixation / cookie planting. If cookies are used to identify carts (rather than users with payment methods), an attacker could try to add items that the attacker is selling to other peoples' carts, by figuring out what the hash for (for example) a cart with 10 AttackerThings in it is, and then putting that cookie on as many users as possible. Some of them may make their purchase without looking closely at what-all they're buying, causing them to overspend and give the extra (via your store) to the attacker.

Web apps are, unfortunately, really easy to get wrong. Languages like PHP make it easy to develop a web app but don't help secure it (indeed, the PHP language is notorious for all the insecure web apps written by people who think learning PHP means they know everything they need about how to write web apps). Good for you, thinking about security at this point, but you need a lot more than just having the basic business logic be secure.


HTTP authentication - the HTTP header name is Authorization - why?

I don't think there is a deeper meaning behind. The usage is consistent with the English language. The Oxford English Learners Dictionary defines authorization as:

  [countable] a document that gives somebody official permission to do something.

  Can I see your authorization?

The HTTP specification for headers dates back at least to RFC 2068 from January 1997 which clearly states:

  Authorization = Credentials

On the other hand, first security standards that laid ground to ISO 27k series were codified in 1999-2000.


How to prevent man-in-the-middle attacks beside of SSL?

Well, there are many options other than SSL to prevent a man in the middle attack, but most all of them have a similar cryptographic basis.  Fundamentally, to ensure that a communication can't be attacked by a man in the middle you must be able to prove that a) both parties can validate the other and b) that no other party can monitor the communication.

Both of these are most commonly accomplished through a shared secret.  Asymmetric cryptographic operations can also be used where both parties have a trusted public key for the other, however this is much more difficult (computationally) than exchanging a shared secret and then using that.

The shared secret can either be pre-shared, such as in the case of an encrypted wifi network, or it can be negotiated through an authentication process.  For example, with SSL, the server validates itself to the client through signing the public key, the client then establishes a shared secret with the server by using the server's trusted certificate and the server then validates the client through a traditional login (or possibly a client certificate in rare cases.)

This general process is not unique to SSL, but the basic steps of verifying identity of one or both parties and establishing a secure communications key is the critical bits.  If, however, the root of the trust for that certificate was compromised, it would be possible for someone to man in the middle since they could pretend to be the server and open their own connection with the server and their own connection with the client.

In the event of a private key leaking, the certificate should be revoked via a revocation list.  This is generally published by a CA and is included as part of the signed certificate.  As a condition of validating the validity of the certificate, the revocation list should be checked for validity.


Brute Forcing LUKS Full Disk Encryption - Time?

If that 20 character password is completely random and uses any of the 95 ASCII characters. Then you'd have 9520 (3.58×1039) possible passwords.
How many SHA1/SHA512 hashes can we do per second? Let's assume we have the following computer:
PC4: Ubuntu 14.04, 64 bit
Catalyst 14.9
8x AMD R9 290X
stock core clock
oclHashcat v1.31

SHA1    29976 Mh/s
SHA512  4576 Mh/s

Source: http://hashcat.net/oclhashcat/
So if you're using SHA1 with 500k iterations, you could try 59952 passwords per second.
With SHA512 and 250k iterations, you could try 18304 passwords per second.
SHA1: 9520 / 59952 = 9.98×1034 seconds = 1.89×1027 years.
SHA512: 9520 / 18304 = 19.59×1035 seconds = 6.21×1027 years.
Even if you had a billion of these machines with 8 video cards in them each, you wouldn't even come close.
If you use only 1 iteration and a 10 character random password:
SHA1: 9510 / 29976000000 = 2 billion seconds = 63.34 years
SHA512: 9510 / 4576000000 = 1.31×1010 = 414.9 years
So if you'd then attack that with a thousand of those machines (8000 video cards), you'd get it down to a manageable 23 days / 151 days.
A 20 character random password is about as difficult to bruteforce as a 128 bit AES key.
2128 roughly equals 9520. So impossible.
This is trying to bruteforce the key by going through the entire key space. You could also attack the hash function and try to calculate the preimage. This is however not applicable for disk encryption because the hash is not stored, it is generated on the fly and the output is used as the encryption key.


Is the (SSL3-based) SSTP VPN protocol vulnerable to the POODLE attack?

I suspect that it's not realistically possible to use this exploit against SSTP.
According to that answer, the attacker needs to be able to do two things in order to be able to exploit this vulnerability:

inject data of their own before and after the secret value that he wants to obtain;
inspect, intercept and modify the resulting bytes on the wire.

The reason that the answer says:

  The main and about only plausible scenario where such conditions are
  met is a Web context: the attacker runs a fake WiFi access point, and
  injects some Javascript of their own as part of a Web page

is that you need access to the data both before and after it's encrypted. Javascript in a browser is perfect for this as you can actually form the malicious request and send it all in your own execution context.

The only way to do this in the context of SSTP would be to have some kind of compromised access to the windows machine that was trying to initiate the SSTP connection, and if you're in that situation you have far greater problems to worry about!

TL:DR The POODLE vulnerability needs some specific circumstances to be exploited, which are not provided by the standard use case of an SSTP VPN.


Why does Firefox claim that my connection to Google is insecure?

Kaspersky, like most AV products these days, is performing a local MITM against your secure HTTP traffic. It does this in order to be able to scan payloads in HTTP transactions, be it in the request or the response.

In order for this to be done correctly, Kaspersky has to generate its own root CA certificate, and generate spoofed certificates on the fly, feeding them to your browser. Kaspersky also has to install this CA into your operating system's Trusted Certificate store.

The reason why it needs to install it into the OS certificate store is because this is where most software looks to validate that the Certificate Authority who has issued the certificate it has received is a valid, trusted Authority. If that authority is not there, boom, you get this error.

FireFox is the only mainstream web browser that is paranoid. It refuses to trust your OS's cert store, precisely because its so easy to simply install a fake CA into it and start MITM'ing peoples connections. Instead, FireFox is distributed with a complete list of all CAs that Mozilla trusts.

What's cute about this is that it's not actually adding any security whatsoever. You can simply compile the open source Mozilla NSS package and, included in it is a utility called CertUtil that can transparently inject certificates, even root CAs, into FireFox's trusted cert store. This does not require the user to accept it, nor does it even alert the user that this has happened. You can see how easy this is to do in a C# function I wrote here.

So what's happening here is that Kaspersky is not properly MITM'ing FireFox, so when FireFox gets fed certs issued by Kaspersky's CA, it's throwing all the alarms and screaming at you that you're under attack.


Why aren't sessions exclusive to an IP address?

First, linking a session to an IP address will not make it secure since the server could see many different users as using the same IP address for various reasons (all types of proxy servers, for instance: client, reverse proxy, CDN, etc.).

Second, the same user could very well use different IP addresses for the same session. For instance, someone could be switching between networks from the same device.

So, since it's not effective and it causes usability and scalability issues, that is not an feature that is usually enabled.


Can an OCSP response be issued by a subca of the Root CA that has issued the certificate?

You just answered your question, it is possible (though, strongly discouraged). Even RFC6960-conformant clients should support this scenario.

For example, Microsoft CryptoAPI allows this scenario even when OCSP signing certificate chains up to different root (which must be trusted) by default. Source: What’s New in Certificate Revocation in Windows Vista and Windows Server 2008

  Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.

Microsoft do not fully support RFC2560 nor RFC6960, because they rely on their own RFC5019 in reagrds to OCSP.

This means that you should take into consideration deployment environments and their specifics.


This answer will only explore privilege escalation to install the keystroke logger at root level or above. Other options are offered as part of parental controls or custom keyboards, but I will not explore those.

For the most part, performing clandestine keylogging I believe to be effective must be installed and operated with "higher privileges". This would for the best part involve privilege escalation which involves "exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user".

The privilege elevation could be archived by iOS jailbreaking, a method of privilege elevation with the purpose of removing software restrictions imposed by Apple. Jailbreaking will allow root access to iOS which will allow us to install a keylogger within iOS's file system. Which will make the device seem like nothing has changed, and it's a stock version of iOS shipped by Apple. This is not the scenario, the kernel verifies the file system on startup against checksums. Hence, we must reverse engineer and rewrite the kernel with a "custom" kernel to allow for this privilege elevation and the keylogger at root level to be maintained.

If the kernel is not patched for the modified file system it will not boot. The difference can be explored further by reviewing the difference between tethered and untethered jailbreaking.

With this knowledge, software keylogging on the kernel or root level is possible. Despite the pedanticism that must be dealt with to get this level of "undetectable" access on Apple iOS, it's completely possible.

With the use of reverse proxy(s), VPN and/or a darknet service, the keylogger can "phone home" reporting the intercepted keystrokes, without risking their anonymity.


My congratulations. You seem to be a very informed developer in terms of security and that is always good to see :)
The Difference Between WHO and WHAT is Accessing the API Server

Now I would like to get a understanding how to mitigate the risk, that someone like me can have access to these used API keys.

First I would like to clarify a usual misconception that arises often among developers of any seniority level, that is about knowing the difference between who vs what is in an API request.
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So, think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
Now, I hope we are in a better mindset to find some possible solutions to your questions.
Locking Down the API Backend to the Mobile App

How to properly store and transmit API keys within mobile applications?
What is the best practice to communicate via a mobile app with a remote API, that requires an API key?

So, usually mobile apps use the API key to identify themselves to the API backend, but this not enough for the API backend to have a very high degree of confidence that the request is coming from what it expects, a genuine and unmodified instance of the mobile app.
Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:

reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.

...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.

WAF - Web Application Firewall:

A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.

UBA - User Behavior Analytics:

User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.

All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So, you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the attackers.
A Possible better solution
Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.
I recommend you to read this StackOverflow answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
In a nutshell, the Mobile App Attestation solution will allow the API backend to identify with a very high degree of confidence that what is making the API request is indeed a genuine and unmodified instance of the mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps
OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.


TLS 1.2 Server certificate and signature_algorithms

The ECDHE-RSA-AES128-SHA cipher suite means that the key exchange will use a dynamically generate ECDH key pair, that the server will sign with its own RSA private key. The server's certificate will thus contain a RSA public key, regardless of how that certificate was signed by its CA.

I suppose that the certificate you use contains an EC key pair, thus not compatible with the ECDHE-RSA-AES128-SHA cipher suite. It is kinda dumb from the server to start up at all with the provided options, since, in effect, it supports no cipher suite at all. But software is known to be dumb (at times).

So while the client is perfectly able to understand ECDSA signatures (and states as such in its signature_algorithms extension), the list of supported cipher suites that you configured prevents it from accepting any ServerKeyExchange message which contains anything else than an ECDH public key signed with RSA.

Also, the signature_algorithms extension is only partially related to this. With this extension, the client may announce the signature algorithms that it supports, and this is meant to help the server select an appropriate certificate chain, and algorithms for messages that need to be signed. If the client says "RSA only", then the server should strive to use only RSA signatures, both for what it signs itself (e.g. ServerKeyExchange message) and for the certificate chains is sends (all CA certificates should be RSA based).

That's, in practice, wishful thinking. Most servers have only one certificate, and that's the one they will send, regardless of the signature_algorithms extension. And most clients will adapt: if the client really supports RSA signatures, then it will process the RSA signatures on certificates and on TLS messages. This is the normal behaviour in the absence of the signature_algorithms extension.

The real usage of this extension is not to limit possible signature algorithms -- these are constrained by both the cipher suite and the kind of certificate that the server actually owns -- but to help the server choose hash functions to be used with signature algorithms. When the client says: "I support RSA with SHA-256", it is really telling to the server "if you must use RSA signatures, then you can do it with SHA-256 as support hash function, I know how to handle it".


Using TLSv1.2 on Weblogic server for outgoing transactions with IBM JDK

Please try disabling Lower protocol in java.security file.

Property Name jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1

Your minimum java version should be 1.7 to use this property.


Certificate Setup Over Many Remote Resources

You can add - inside your app - a trusted certificate to the chain, and you can use a self-sustaining private CA. Even more I'm encouraging you to do so because of security, encode a key's checksums inside your app and verify them too.


The basic idea of the web of trust, as used in PGP to send messages, is peer validation:

Alice knows Bob, Bob knows Cindy, but Alice does not know Cindy. Cindy wants to send Alice something privately, but first needs to be "introduced" to Alice.

Cindy begins by first asking Alice for her public-key certificate. Alice sends it; it's public information, so she can broadcast it to the world. Included on this one certificate would be a number of digital signatures, each from a person Alice knows, including Bob, who is vouching for the accuracy of this certificate. Each signature is unique to the combination of the certificate and the signer, and the creation of a signature requires a private key known only to that signer. Once created, anyone who knows the public key matching the signer's private key can use that key to verify that the signature matches both the message and the signer (or that it doesn't).

As such, the evil Eve cannot hope to alter the message in such a way that the signature(s) would still match, nor can she change the signatures themselves, without having compromised the private keys of all signers. The worst she can do, given that someone else already knows and is vouching for Alice's identity, is corrupt the certificate causing Cindy to reject it, preventing the intended communication.

Alternately, Cindy could ask all her friends if they know Alice, and any that do, including Bob, can each forward Cindy a copy of Alice's certificate with only their signature on it. This reduces the number of signatures that have to be included on a single certificate to provide a good chance for Cindy to recognize one; since Cindy's asking her own friends, who would only respond if they did indeed know Alice, Cindy only receives signatures from people she knows and ostensibly trusts. But, it could cause a flood of data to be sent to Cindy if Cindy and Alice have a lot of mutual friends.

In either case, Cindy scans these signatures for signers that she knows. She find's Bob's name, validates his signature of this certificate, and now knows that Bob thinks this is the real certificate for the real Alice. Cindy now has the choice to trust Bob implicitly, and so trust Alice's certificate herself on his word alone, or to partially trust Bob, and look for other people she knows who have signed Alice's certificate. If she finds enough people she partially trusts, or at least one person she implicitly trusts, she can trust Alice's certificate by extension. This is known as the "trusted introduction" and is central to the web of trust.

Once Cindy decides to trust the certificate, she uses its public key to encrypt the key to a symmetrically encrypted message that has also been signed by Cindy with her own certificate. She then sends it to Alice. Alice doesn't know Cindy, and so repeats a similar process that Cindy did to obtain, validate and decide to trust Cindy's public-key certificate (which she does, because Bob has signed Cindy's certificate and Alice trusts Bob implicitly). She uses her own private key to decrypt the message key, then uses the message key to decrypt the message, and finally uses Cindy's public key to validate the message's signature.

Now, that's with three people who are already partially "entangled" in the web and so can trust each other based on peer recommendation. For two people with no mutual trusted friends, such as when a web is just starting or when a new person who's never used PGP before tries to join, this automatic peer recommendation simply won't work; there are no peer recommendations to speak of (there may not even be peers). To spin the first few threads of this web properly, the people wishing to form it must exchange certificate files with each other inside an environment that is inherently trusted (known as a "key signing party"). Otherwise the evil Eve can intercept the certificates being exchanged, replace them with forged certificates, and she becomes a "man in the middle".

The oldest, simplest way to avoid this is simply to meet in person and physically exchange certificate files with each other. Other possibilities, such as secure drop-boxes, exist, but all Eve needs is one second of unrestricted, undetected access to the physical storage of the key to screw it all up.


This was a marketing message sent (and signed) on behalf of PayPal.
It is safe to click the unsubscribe link.

As captured by GMail's excellent summary view:

See the mailed-by section?  mkt2944.com is a part of Silverpop, a Email Service Provider which was acquired by IBM in 2014 and was recently folded into IBM Watson Campaign Automation.

  how is it possible that they can send a digitally signed email from a domain paypal controls?

It's not really possible, though there are some tricks that can make it seem valid (e.g. Mailsploit).  In this case, it's not spoofed because they have permission.  The server at bounce.paypal.mkt2944.com has a DKIM key that is hosted at some paypal.com domain as indicated by the DKIM selector (the s= part of the DKIM-Signature header, so if it were s=foo then the key would live as a TXT record at foo._domainkey.paypal.com).


There are many ways to do this. The term you are looking for is "rootkit" - that should send you down a rich road of research.
As for specifics, the attacker could replace a core Windows program with an infected one so it always gets loaded when Windows starts up normally. Or, the attacker could infect the BIOS. These two methods are impossible for a normal user to detect or to change once infected, which is why strong Anti-malware tries to detect and prevent these things.
A very cool alternative (more theory than actual) was to convert the existing operating system into a virtual machine and install a malicious hypervisor over top. In this way, there would be no change at all to the operating system, and the hypervisor could fiddle with the operation of the machine as it ran. In this case, even the perfect anti-malware program would be helpless.


SQL injection to login when there's no record in the database

This appears to be a case of UNION SELECT rather than inserting your own records.
What you need to do is figure out how many columns are being selected (by trial and error.. SELECT 1,2,3...n until you stop getting an error).

After that, you inject the query so the first part returns false (no username found). The tricky part:
You inject ' OR 1 = 0; UNION SELECT 'banana' AS username, '123456' AS password FROM users LIMIT 1;# into the username field, and into the password field you inject 123456.

You essentially force the SQL query to return any password you want and therefore bypass their conditions :)


Hardening ASP.NET against session fixation: Should I change the session ID despite the additional Auth cookie?

I think you could ignore the report. Tools automate tasks so you should always review the findings, as in this case.
The tool maybe just checks if the value of the cookieA is equals to the value of cookieA after the authentication and then tells you if your app is vulnerable or not.
Probably it doesn't consider how the new secret the server is giving to the user protects it from the session fixation attack.
The prerequisite of the session fixation attack is that the attacker should be able to know a session id value which doesn't change after the authentication (this would occur using only ASP.NET_SessionId).
In your scenario the attacker can't hijack the session because the handling of the session is not based only on one secret but involves 2 strictly coupled tokens and he can't know the secret set after authentication.


Should we be checking password restraints on log in forms?

Checking again an already registered password is useful IF the rules you want to enforce have changed AND you have the possibility to make the user change his password so that the new one complies with the new rules. Otherwise it is a waste of time, and added complexity (complexity is Bad).


There are various VPN technologies and various technologies which are sometimes called a VPN but which are not. A traditional VPN is a virtual network, i.e. it usually works at layer 3 (IP). These VPN do not care about DNS at all, i.e. the system using this VPN decides which DNS servers to use. Depending on the exact setup this might mean that the system is using some DNS server in the local network (usually at the router) which the uses the DNS server of the ISP - i.e. DNS lookups fully bypassing the VPN. This is also called a DNS leak and there are sites which let you check for this. A proper setup instead would use DNS servers which need to be accessed through the VPN, i.e. either DNS servers provided by the VPN provider or public ones like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).

And then there are application level proxies which are sometimes called a VPN too, because they offer the [P]rivate part even though they don't protect a full [N]etwork. Commonly these are HTTP and SOCKS proxies. Properly configured the DNS lookup is only done  at the VPN endpoint using the DNS servers configured by the VPN provider. But improperly configured the DNS lookup is again done locally, bypassing the VPN and causing a DNS leak.


KeePass OTP plugin circumvents inbuilt protections?

KeeChallenge is based on the predictable result of HMAC-SHA1 with a known key. The key in the XML file is encrypted using the result of performing HMAC-SHA1 on the challenge also stored in the XML file. To decrypt the key, the challenge is passed to the Yubikey which performs HMAC-SHA1 to generate the same value that was used to encrypt the key data last time. Once the key is decrypted, a new challenge is generated and the expected response (generated using the decrypted key) is used to reencrypt the key.

The source is pretty easy to follow.


Enabling virutalization, addressing the bluepill risk?

There are two aspects to bluepill: how the infection happens and whether you can detect it once it happened.

The first aspect is the same as for all malware really. The novelty aspect of bluepill was the "it's undetectable" claim.

There was extensive research on that, and several methods have been devised for detection.

You should note that, as of yet, there were no bluepill threats seen on the wild.

Detecting if the OS is running inside a VM

The first published methods for detection involved timing. From an interview with Anthony Liguori:

  Hardware virtualization requires a technique know as “trap and
  emulation”. The idea is that the hardware traps certain instructions
  and the VMM emulates those instructions in such a way as to make the
  software believe it is running in a virtual machine.

  Software emulation implies that these instructions take much longer to
  complete when executed under a VMM then on normal hardware. This fact
  is what can be used to detect the presence of a VMM.

  I approached Rutkowska about this and she attempted to address it in
  her prototype by adjusting one of the processors clocks on every exit.
  However, there is nothing that she can due about external time sources
  and she’s admitted to this on her blog.

  She refers to this as a theoritical weakness in her system but I
  assure you that it is quite practical to exploit.

The original author of the bluepill concept (Joanna Rutkowska) also published another paper (RedPill) which might be leveraged to detect a BluePill rootkit.

I couldn't find the paper, but found this excellent summary:

 int swallow_redpill () {
   unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
   *((unsigned*)&rpill[3]) = (unsigned)m;
   ((void(*)())&rpill)();
   return (m[5]>0xd0) ? 1 : 0;
 }

  The heart of this code is actually the SIDT instruction (encoded as
  0F010D[addr]), which stores the contents of the interrupt descriptor
  table register (IDTR) in the destination operand, which is actually a
  memory location. What is special and interesting about SIDT
  instruction is that, it can be executed in non privileged mode (ring3)
  but it returns the contents of the sensitive register, used internally
  by operating system.

  Because there is only one IDTR register, but there are at least two OS
  running concurrently (i.e. the host and the guest OS), VMM needs to
  relocate the guest's IDTR in a safe place, so that it will not
  conflict with a host's one. Unfortunately, VMM cannot know if (and
  when) the process running in guest OS executes SIDT instruction, since
  it is not privileged (and it doesn't generate exception). Thus the
  process gets the relocated address of IDT table. It was observed that
  on VMWare, the relocated address of IDT is at address 0xffXXXXXX,
  whereas on Virtual PC it is 0xe8XXXXXX. This was tested on VMWare
  Workstation 4 and Virtual PC 2004, both running on Windows XP host OS.

Another method is reviewed in this article is from 2008:

  The idea is to intercept a hypervisor's start by another hypervisor
  (let’s call the latter a Virtual Intrusion Prevention System, or
  VIPS). When any hypervisor (malicious or legitimate) starts, it turns
  VM root mode on. This event can be easily intercepted by a VIPS. So
  what's next? There are 2 ways to handle this event: blocking a
  hypervisor completely, or allowing it to work through emulation.

  The first way consists in emulating a PC with disabled HVT feature in
  BIOS. This will block a HVT rootkit from working.

  The second way consists in allowing a hypervisor to work through
  emulated hardware virtualization (or nesting). This should be done for
  legitimate virtualization software.

  In both cases (blocking or emulating), a VIPS intercepts a hypervisor
  at the moment it tries to start. VIPS can read the hypervisor’s body
  and analyze it. A notification message can be shown.

Is this really a threat

Then there's the practical aspects of the attack to consider.

A bluepill rootkit needs to implement xen or something similarly complex, which is a huge endeavor. Since there really is no guarantee it won't be detected or blocked anyway, attackers will choose an easier path which is classical rootkits.

I believe this is part of the reason why bluepill rootkits haven't been seen on the wild.


Storage of card data is not the deciding factor for PA-DSS scope.  If the application handles card data, even if it does not store it, it could be in scope.

See p. 16 of the PA-DSS Program Guide for the "To Which Applications Does PA-DSS Apply?" section:
https://www.pcisecuritystandards.org/documents/PA-DSS_Program_Guide_v3_1.pdf

Included in that section is a list of types of applications to which it does not apply.

If card data is handled, one of the major factors is whether the
software is COTS - are you distributing non-customized software to
many customers?  If so, PA-DSS likely applies.
If you are creating custom software for a single customer?  PA-DSS
likely does not apply.
If you will be hosting the software as a service yourself and not distributing any components, PA-DSS likely does not apply.  However, you may be in scope as a service provider and need to undergo PCI DSS validation.

If in doubt, it is best to speak with a PA-QSA; that is the type of assessor that performs PA-DSS validations.  They can work with you on whether your application is eligible.

I've said "likely" in many places above because depending on your application's place in the payment chain, certain tokenization models, other "scope reduction" solutions, etc., it can change the situation.  For example, I am aware of some DTMF-oriented payment applications where the solution provider was in scope for PCI DSS themselves, but did not need PA-DSS validation on their software due to the hosting model.


I can think of a couple of options which may help.

1)Keep the config file on the live servers and have the build process copy it to the new deployment folder. As long as you restrict access to the live box, you get away from everyone having access.

2)Encrypt the passwords and have the decryption keys live on the server. anyone without access to the box can't decrypt the file.

3)Use RSA, give the server a private key and store the public key in the app database. The public key encrypts the password file, the app grabs the servers private key and uses that for decryption. This way, anyone can have the config file and anyone with access to the DB can create one. Only people with access to the certificate store on the server can access the decryption key. You can add signing if you want.

You can keep copies of the keys/passwords somewhere with restricted access in case you need to recover them.


Storing opened mail attachments unencrypted in /tmp is a normal thing?

At some point the program needs to store the documents somewhere in an unecrypted format if the document is to be shown to the user. If you want to show the document to the user you need to decrypt it, there is no other way. It can either be stored on disk or in memory in its unencrypted form (although the latter can have severe issues once the filesize starts growing). Hence often the unencrypted file is stored temporarily in a folder where only the owner of the file can view it.

If the permissions are indeed 750 on the folder then it means that only the owner and group members will be able to view the file. This is normal practice as long as all files are removed from the tmp folder after viewing.


Well, in short not yet.

As we harden systems and become better algorithm creators it’s possible that in the future we may have one


Metasploit & openvas error (openvas_connect)

Don't Connect to 9392. Instead Connect to 9390

  openvas_connect username password localhost 9390 ok


Mobile apps that use OAuth2 to offload authentication to a 3rd party: are they misusing OAuth2?

You are correct that oAuth2 only gives your application permission to act on the user's behalf in their API. oAuth2, by itself, has nothing to do with authentication.

If the third party API has any sort of request that gives you a unique ID for the user that you're working on, then their API can be used as a form of authentication, with the caveat that you're putting your trust in authentication into a system that you don't have control over, and a reminder that authentication is not authorization. (Just because they showed a valid ID card doesn't mean they're allowed to walk into your bank vault.)

But yes, oAuth is only concerned with letting you use the third party API on a user's behalf; it has nothing to do with the accuracy and security of that API beyond identifying you as acting on behalf of the user.

As far as whether or not your application should use their API for authentication, I suggest doing a risk assessment. There really isn't enough information in your question for us to inform you of any known risks, as we don't know how sensitive your data is (will people try to steal your users' accounts?), or how secure the third party's API is.


Why can hardware assisted virtualization be a security issue?

My research suggests that you have misinterpreted the meaning of the setting, e.g., see
this thread.

Avast is capable of using hardware-assisted virtualization to provide better anti-virus protection.  However, because this can cause compatibility issues with other software, an option is provided to disable this functionality.

That is, if you turn off the "Enable hardware assisted virtualization" you are not telling Avast to disable hardware virtualization on the PC; rather, you are telling Avast not make use of the hardware virtualization functionality itself.


Forced to use using 2-Step Authentication to keep online profiles safe?

Forced? No. But passwords alone have known weakness. Using 2-factor methods help to mitigate the risks of those weaknesses.

That also means that we can't make it a web standard for every login, because there are instances where it does not make sense in terms of mitigating those risks.

I suspect that the current 2-factor is a stepping stone to better things. Biometrics and physical tokens can be combined to provide something similar to 2-factor and people are working on making that accessible for the masses.


Is Google Analytics tracking actually safe to use on pages with sensitive information?

Every third-party script has the ability to load every page on the same domain so the risk exists.

If you really need to track analytics on sensitive pages, consider doing it server side, and be sure to check that an analytics snippet loaded on another page couldn't load the sensitive page and read its contents (via AJAX, for example).


How long does it typically take to distribute malware signatures?

Exact information on how long it takes organisations to detect and publish signatures to their AV products  will be proprietary and closely guarded by the various AV vendors.

There are number of clues to the general time frame dotted around though. Kim Zetters book Countdown to Zero Day, conducted thorough research to tell the story of stuxnet, in the book she goes into great depth about the workings of the malware industry. In a passage specifically about Symantec she says the following;

  "When the company first entered the antivirus business, it was
  considered a good response time to turn around a threat -from
  discovery to delivery of signatures- within a week. But Symantec aimed
  to reduce this to less than a day. To accomplish this the company
  needed analysts in multiple time zones to spot viruses in the wild
  when they first appeared and to get signatures out to customers in the
  US before they woke up and began clicking on malicious e-mail
  attachments."

So Symantec and I presume their main competitors in the market have a very fast turnaround, when they successfully detect new malware or new strains of malware.

In 2010, which in technology terms may as well be a lifetime ago, there was certain circumstances when at least a week was still  possible for signatures to be published to some AV products for known malware.

Kaspersky Lab created 10 harmless files and flagged them to malware aggregators VirusTotal that Kaspersky considered them as malicious.

According to the Reuters news agency;

  "Within a week and a half, all 10 files were declared dangerous by as
  many as 14 security companies that had blindly followed Kaspersky's
  lead, according to a media presentation given by senior Kaspersky
  analyst Magnus Kalkuhl in Moscow in January 2010."

Another organisation admitted to conducting a similar experiment 3 years ago, they also quoted a week until they saw signatures being published. So not much had changed from the 2010 experiment, which suggests that the procedures and practices of some AV companies don't change that much over time.

Based on this I would suggest that AV signatures from malware detection to the publishing of a signature could be anywhere between 1 day to 1 week, depending on the AV vendor. Clearly this includes a lot of assumptions though.


Shadowsocks: Doesn't communication with just one server look suspicious to the GFW?

Possible? Sure! Will it be done? I doubt.

Unless your traffic is on the top chart, you are a small fish. And they don't have resources or people or willingness to pursue every single private VPN service out there, because there are more interesting things to pursue.

IPv6 addresses are plentiful and cheap this days. If you are concerned about being blocked, rent a VPS or two, with IPv6 addressing, and have shadowsocks listen on every address. Change to a random address at random intervals and you can conceal your VPN a little more.


How attaching to a process with a debugger can compromise system's security?

Your note that it's a "different user's process" is the key here. If the malicious process is limited to that user's context, then attaching a debugger (which usually requires deep permissions) gives the process access to more resources.

While a debugger might be used to prevent malicious activity, there is no way for the debugger to know what exactly you will do. You could simply run the process to completion to analyse the logs later.

The warning is appropriate, although there are possibly ways where it is not necessary. Better to have it in order to remind everyone of the very real problems.


What's the best, most unique (and uneditable) hardware id or key for each computer?

Nothing is "uneditable"; what science can create, science can replicate with sufficient funding and time, particularly with a sample.

The closest you're going to reasonably get is a cryptographic dongle, something like a smartcard you provide with your software, after you've generated keys on said smartcard prior to shipment.  If you get a FIPS 140-2 Validated module which has an Overall Level of 4, that's the best I'm aware of within the United States.

You may not know what hardware is actually running your software, but you'll have a resonable amount of certainty that whatever's checking in via

Server sends app a cryptographically random message
App signs message with smartcard's private key

ECC 256 bit or higher, or RSA 2048 bit or higher
which you'd generated before you shipped the card

App sends signature to your server
Your server validates the signature against that smartcard's private key

does, in fact, have the smartcard readily available to them.

You'll need to work out how to supply replacement cards, of course.

And you'll need to spend some money.  The cheap version of this uses someting like a yubico product and foregoes FIPS certification, which at higher levels includes physical protections against subtle, hidden tampering (for instance, filling the interior with strong glue so it's very difficult to open it up, change it, and put it together again without leaving signs).


Does having a number in your username make it more secure?

Other than the fact that user names are not password replacements, because they are often public (or at least less secured):

No, forcing a user to have a number in the input actually decreases the number of possibilites, thus making it less secure against guessing.

As small example, lets have a password of length 4, where each character can be one of 70 possible ones (26 uppercase, 26 lowercase, 10 digits, and some signs like .,?! etc.). That's 70^4 = 24010000 possibilities.
If one of these 4 characters must be a digit, there are 70^3*10*4 = 13720000 possibilities (the 4 is because the digit can be any of the 4 positions).
So without digit, there are about two times as much possibilities here.

Of course this can be generalized for any set of possible characters (as long as it's significantly more than the 10 digits alone) and any password length.

And yes, the fact that humans are no perfect random generators is missing here - forcing a digit could prevent some people from using eg. their own name. On the other hand, other people will use their name with 1 added. Nonetheless, some people actually use good RNGs (password managers etc.etc.), and like shown the digit allows less possible values.


access-control-allow-headers: * is being ignored

The Access-Control-Allow-Headers header does not support wildcards. You can only supply a list of actual headers that are allowed.

If you still want to allow all headers, you can make your web application look at which headers are present in the request and reflect all these in Access-Control-Allow-Headers.


I'm implementing password validation for AD accounts. Is it dangerous to publish the forbidden words list?

The biggest risk that comes to mind immediately is that this makes a dictionary attack somewhat easier - rather than try every conceivable combination, a bad guy has certain words that they know not to try.  In theory, this would speed up that kind of attack.

That said, it's still a pretty large solution set so we're not talking about a huge time savings.  And if it's on your network, they'd need to already be inside to get the list.

On the flip side, this eliminates the passwords found here, making guessing known weak passwords useless.  Plus, you make available the list of unallowed passwords, reducing user frustration (provided they remember to find it...)  Maybe some of the other folks here will disagree, but I say go ahead and make it available.  It's still a large universe of potential passwords, the passwords in use will be stronger, and your users have the ability to find the list of banned words.


Yes, it is indeed a two step process. That means the target process must indeed provide some means for you to interact with it in multiple steps. Basic exploitation exercises are often limited in that they do not provide much in terms of interaction, but a real target will most often provide some means to establish a session or exchange messages. For example, if your target is a web server, you may send a bogus request to leak a dump of the stack. Then, with another request, you may exploit some write primitives to achieve code execution. Other typical examples include attacking the browser from JavaScript, or attacking the kernel from user space. In these cases, you would code a typical (or not so typical) program that performs service calls to the underlying platform in order to leak information (maybe written to some memory locations that you can read from your program) and eventually exploit some write primitives to gain code execution or whatever you want to achieve.

Information leaks in general could take any form. Any channel through which you can communicate with the server could leak information. Just a random example: imagine a pdf generation service that takes a doc file and creates a pdf. You may provide a bogus doc file that makes the service dump a chunk of heap or stack memory into the generated pdf, which you would then download, and then provide a second doc that completes the exploit.

In general, how you will go from step one to step two is heavily dependent on the target system and the kind of vulnerabilities being exploited. In many cases there will be way more than just two steps, so automation is not a bad idea. If automation is indeed an option, you may want to create a script that performs the steps in sequence. Back to the web server example, you could write some Python or Ruby script that sends the first request, reads the response, extracts relevant information, prepares the second request computing addresses where appropriate, and sends the final request to the server to finish exploitation.


Are MCUs (Like arduinos) effected by Meltdown?

In general, no, for several reasons.

First, Meltdown is an issue with how Intel chose to handle invalid memory accesses during speculative execution.  A couple of ARM designs are vulnerable to a variant of Meltdown, but other than that, it's Intel-only.

Second, Meltdown and Spectre both require that the CPU use a technique called "speculative execution".  This is a great performance boost, but it comes at the cost of a bigger, more expensive, and more power-hungry chip.  Microcontrollers are small, cheap, low-power chips -- exactly the opposite of what would use speculative execution.

Third, Meltdown and Spectre are about getting around memory protection.  The typical microcontroller only runs a single program, so applying memory protection is a waste of time and effort -- any memory a program could read using Meltdown or Spectre, the program could read just by looking at it.


As the O'Reilly book, DevOpsSec details in chapter 2, Separation of Duties (SoD) is a major component of the information-security standards: ISO 27001, NIST SP 800-53, COBIT, ITIL, etc -- and part of the regulatory requirements for (at the very-least): FFIEC, Sarbanes-Oxley Section 404, SSAE 16, GLBA, MiFID II, and PCI DSS.

Developers do agree that read-only environments such as Immutable Infrastructure (i.e., the "No-SSH Movement") are best-practice. You will even see developer heroes such as Martin Fowler directly prescribe the PhoenixServer concept, if not the full ImmutableServer model.

However, in an org where the Three Lines of Defense (3LoD) are instilled (e.g., financial services companies or anywhere that has an internal and/or external audit function), even read-only functionality may not be enough to meet the requirements (and pass an audit).

The DevOpsSec book makes the following recommendations beyond Immutable Infrastructure and SoD (which it also recommends):

Limit access to nonpublic data and configuration.
Review logging code carefully to ensure that logs do not contain
confidential data.
Audit and review everything that developers do in production: every
command they execute, every piece of data that they looked at.
You need detective change control in place to track any changes to
code or configuration made outside of the Continuous Delivery
pipeline.
You might also need to worry about data exfiltration: making sure
that developers can’t take data out of the system.

Another compensation control is Rotation of Duties (RoD), which often goes along with SoD. If you rotate people out every-so often and avoid situations of collusion, then this can compensate and back up the other strong controls. A final piece would be two-party integrity where a full checks-and balances system includes the ability to prevent trusted insiders via the "No Dark Corners" paradigm.

Here also are some fresh perspectives from Ben Tomhave, an industry expert on DevOps and application security -- http://www.newcontext.com/devops-and-separation-of-duties/


Okay, this is very easy if you are the GSM base station as the phone sends unique codes on first contact to that base station. However the legality of setting up your own base station and such may be problematic, depends on country, frequency, power and what radio spectrum licenses you have. As for anonymously doing it, fundamentally, you want to track phones uniquely in your area someone else can track them too, from that data. In fact, phone operators deliberately designed it not to be anonymous so they can track phones for charging the going rates for placing calls and the like.


Usually it's a mix of black and white listing to avoid that specific problem. Occasionally mistakes are made but they are usually resolved very quickly.

I can't speak for any particular vendor but there are a lot of good free threat intelligence feeds that many organizations contribute to to minimize accidental blocking of valid addresses.The way any specific vendor handles the trust rating and what to publish is likely different from vendor to vendor but generally they've all been working through those issues for a few years and gotten good at it.

Another aspect is the trust rating of any given IP is the network it's from. Large ranges of IP's can be attributed to specific owners via their BGP AS numbers. This helps incident responders contact the owner of an IP and it also helps people know if this is an IP run by a risky small ISP known for hosting lots of malware vs. a very reputable organization like a hospital that may have an infected host.

Likewise there are lots of lists for known Good hosts (top Alexa websites) and known Bad/Malicious hosts (Russian Business Network type hosts).

You may want to look into these lists as well

https://zeltser.com/malicious-ip-blocklists/

It's a lot of work to create these feeds but they are very valuable tools to block/slow-down attackers.


Is bcrypt(strtolower(hex(md5(pass)))) ok for storing passwords?

As a password cracker, I encourage all of my targets to use this technique.
This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt.
(EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so none of this should be take to mean that this scheme should be left as is.)
Wrapping an unsalted hash is problematic from a real-world attack perspective because attackers can do this:

Acquire existing MD5 passwords from leaks - even MD5s that haven't been cracked yet
After simpler attacks have been exhausted, run these MD5s as a "wordlist" against your bcrypt(md5($pass)) corpus, to identify uncracked bcrypts with known MD5s
crack those MD5s outside of bcrypt at much higher speed

And yes - you do have to discover the MD5 inside the bcrypt first. But the crucial point is that that MD5 can be an otherwise uncracked MD5 that happens to be present in some other leak, which you can then attack at massively increased speeds.
This is not a theoretical attack. It is used all the time by advanced password crackers to successfully crack bcrypt hashes that would otherwise be totally out of reach for the attacker.
How this attack works is very non-intuitive for non-specialists, so I strongly encourage skeptics to experiment with a real-world scenario to understand how it works:

Hash a 6-character random password with MD5.
Presume that this MD5 is already present in some other list of leaked passwords, proving that it has been used as a password at some point.
Try to attack the MD5 directly with brute force.
Wrap the MD5 in bcrypt and try to attack it directly with brute force.
Attack the same bcrypt-wrapped MD5, but this time pretend that you haven't cracked the MD5 yet, but instead use a "dictionary" of leaked MD5 that includes your MD5.
Once you've "discovered" that you have an MD5 in hand that is inside one of your bcrypts, attack the MD5, then pass the resulting plaintext to your bcrypt(md5($pass)) attack.

Again, very non-intuitive, so play with it (and don't feel bad that it takes work to understand it; I argued vigorously against it with Jeremi Gosney for an hour straight before I finally got it!)
I don't believe that this technique has an "official" name, but I've been calling it "hash shucking" or just "shucking."
So depending on use case, it's totally understandable why wrapping bcrypt can be attractive (for example, to get beyond the 72-character bcrypt maximum, though this can be tricky for other reasons, including the 'null byte' problem), or to migrate existing hashes.
So if someone needs to wrap a hash in bcrypt, the mitigation for this weakness should be clear by now: your inner hash must never appear in any other password storage system that might ever become available to an attacker. This means that you must make the inner hashes globally unique.
For your specific use case - in which you need to preserve existing hashes - there are a few options, including:

adding a global pepper within your web or DB framework - so, bcrypt($md5.$pepper) This allows you to easily migrate existing MD5s, but that global pepper is still subject to being stolen (but if your web tier is segmented from your DB tier/auth, this might be an acceptable risk, YMMV);
adding a global pepper using HSM infrastructure (storing the pepper in such a way that not even the web app can see, so it can't be stolen)
adding an extra per-hash salt (but you'd have to store it outside of the hash somehow, which starts to get tricky and verges into 'roll your own crypto' territory);
hashing the MD5s with a slow, salted hashing algorithm or HMAC inside the bcrypt layer (not recommended, I'm not even vaguely qualified to advise on how that might be done properly, but is possible - Facebook is doing it, but some very smart people designed that);

For more details, including some specific scenarios to illustrate why this is weaker than bcrypt alone, see my SuperUser answer here, this OWASP guidance on "pre-hashing" passwords which supports my assertion with more clarity, and this talk by Sam Croley discussing the technique.
Password upgrading in general can be tricky; see - this answer and Michal Špaček's page on password storage upgrade strategies.


Error-based SQLi relies on a bug found in MySQL concerning the GROUP BY statement (see here and here).

To trigger the bug one must follow the following rules:

Use an aggregate function.
GROUP BY a column that has two identical values on different rows.
The output of the rand() function must appear in the column of point 2 above.

The string

or 1 group by concat_ws(0x3a,version(),floor(rand(0)*2)) having min(0) or 1--

is injected in a WHERE clause, so or 1 (which is equivalent to or true) is used to cancel out the previous conditions and display as many rows as possible. This way, there should be at least two rows with the same value for floor(rand(0)*2)). This takes care of points 2 and 3. We use floor() so that the values returned are just 0 or 1. If we were to use rand directly, it would be almost impossible to satisfy point 2.

We need having min(0) to take care of point 1.

Also, the instance of or 1 at the end of the query is useless and can be removed.


How can I verify that SSLv3 protocol is disabled?

SSL-Session:
   Protocol  : SSLv3
   Cipher    : AES256-SHA

Obviously your server still has SSLv3 enabled.
If you successfully disabled SSLv3 openssl s_client -ssl3 -connect ... should get something like this:

...SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40
...SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
...
Protocol  : SSLv3
Cipher    : 0000

The indicator here is that you get no cipher ("0000").

As for the ciphers itself you don't need to make any changes.


What should you do when you notice weird traffic?

I would do the 1st item only.  Additional logs analysis is clearly prudent to make sure no real compromise has occurred.

Blocking IPs is of minimal effectiveness.  Most cyber-criminals aren't breaking into machines from their home network, they're using another compromised machine or a proxy to hide their identity.  Blocking their jumping off point may slow them down, but that's really just a cat and mouse game.  Maybe they'll get bored and give up, so I suppose it has some value, but if you start blocking a lot of IPs, you might be blocking legitimate traffic (customers, for example).

Contacting law enforcement is something I'd save for after being certain that a compromise has occurred and that there is both substantial evidence and I can demonstrate a financial loss.  Otherwise, there's not much they're likely to do.  Prior to an actual compromise, even if that may technically be illegal, LE is so overworked that it's unlikely they'd have resources to even look at it.

My personal server gets portscanned, dirbustered, etc., multiple times a day.  I don't even blink at those reports, it's just noise at this point.


Is there a way for a "hacker" to know your password length and if you used numbers or symbols

Even most weak hash routines like MD5 do not reveal the length or diversity of characters in your password until the matching hash is found.

This is thanks to something called the Avalanche Effect of cryptographic hashes.

This holds true even more so for strong hashes. The attacker would not have any clues about the password until the brute-force successfully finds a match.

It is important that the developer uses a unique salt per user, so to prevent the use of pre-existing Rainbow Tables.


Monitoring the Bash history is easily done with a shell script, but just checking it for unexpected changes might not be an effective security measure but rather clutter your logs with false-positives.

One obvious way to monitor file system events associated with your .bash_history file would be by using the inotify API. E.g., this triggers on file modification events:

$ inotifywait -m -e modify ~/.bash_history

You could then compare the contents each time to determine changes, or just compare the number of lines to detect if entries have been deleted with a smaller overhead. (Just checking the file size won't work if the history has reached its maximum length and old entries are dropped.)

But note that it's trivial for an attacker to work around that. You have to expect that any reasonably skilled intruder immediately disables the history, rather than removing suspicious entries afterwards. Also, there are many cheap ways to bypass Bash entirely without provoking log entries (change to Bourne shell, execute from within vi, etc.).

Generally, I'd consider monitoring the Bash history for possible tampering too unreliable and error-prone to be a useful security measure. Instead, I'd first make sure to cover the logs where it's easier to identify security-relevant incidents (/var/log/auth.log, etc.).


Sent images on company WiFi network by accident

When connecting to a corporate network, wired or wireless, it's possible for their IT department to intercept your traffic and/or get details of what you're doing on the web -- but in BYOD environments, this possibility can vary greatly.  Security varies widely, but there's intrusion detection systems, SSL interception (although this only works from corporate-managed devices), DNS and traffic logs that might reveal what users have been doing on the internet.

Each individual app that you install will have different security standards, depending upon the app vendor's practices.  In this case, you identified Grindr in the comments as the app.

A quick web search reveals an evaluation of Grindr security: https://www.os3.nl/_media/reports/grindr.pdf  in which you'll find that Grindr does in fact use SSL/TLS for its connection to the Grindr server, where all data is sent/received from (including pictures).  Since your smartphone is BYOD, it likely doesn't have corporate master SSL certificates installed.  In this case, your employer cannot intercept the SSL traffic.  However, if your employer has installed an app to manage your phone or otherwise enforce BYOD policy, this might not be the case. Thus, based on the information you provided, it seems that your connection to Grindr and the data you sent/received is likely secure.

However, your DNS queries and the IPs of the Grindr webservers may be flagged, or website information derived from the SSL certificate exchange before communications are encrypted, so it's possible the employer may (through use of IDS or other sophisticated security apparatuses) know you had been using Grindr, but not what you had sent/received, or what your login information is etc.

So, it may be possible that the corporate network knows you're using Grindr, but likely not your naughty pictures or any other information.


Identifying a script used for vulnerability scan

Is there a way to identify the script that was used ...

Technically, the answer is "yes". You need to look for the specific signature of the methods used and look those up. There is not much more to say about that without any more details about the attack.

Unfortunately, the likelihood of identifying the type of attack from just your web server error logs is very, very low. There is likely not enough to build a signature from and you will not be able to distinguish a custom script from well-known tools at default settings.

Years ago, I did a forensic analysis on a massive dump of packet captures and was able to determine, from the network packet details, the exact tools used, even down to the version ranges they were likely to be. While fascinating and a cool rabbit hole to fall down, the exercise was ultimately not a good use of my time.

  ... knowing that it was a common kit/dictionary with the default settings
  would be reassuring; knowing that it was custom would be alarming.

I hear this a lot from people, and while wanting to quantify your threats is often a good thing, there is not a lot of value in this particular threat analysis.

If someone is holding a gun to your head, does it matter if the attacker made the gun or bought it off the shelf? Are you aware that even the most elite hackers will use off-the-shelf tools at default settings because there is often no need to "get clever" because the basic tools work, especially at the initial stages of an attack?

How would your response be any different as a web admin if the attack came from a default kit or from a targetted attacker? You are being targetted by both types of attackers every second of every day, whether your logs show it or not. Your response to these threats is not to assume all attacks are elite hackers and then freak out, but rather to acknowledge that the Internet is an inherently hostile environment and to make sure you are running a tight ship and resilient processes, because any weakness will be discovered and exploited by someone, expert or noob.


How protected are files within a running encrypted VM on a possibly non secure hypervisor / host?

It is not clear from what kind of attacker your are trying to protect. But to make some guesses what could it be:

If the attacker gets inside your VM all files are there in plain because they are transparently decrypted when read.
If the attacker is root on the VM host instead he could capture the credentials you need to enter on start of the VM if the encryption key for the disk is password protected. If the encryption key is not protected and resides on the system where the VM is running it will be even simpler for root on the system to get it. Once the attacker has access to the credentials he could decrypt the disk.
If the attacker is not root on the VM host then he should not be able to read your VM image in the first place, i.e. proper file permissions should be sufficient protection.

In other words: I don't think you gain much with your proposed method.


PGP Encryption - Whats the need to encrypt using random one time key?

There are two reasons:

RSA and other assymetric algorithms are very slow. It is faster to encrypt a small key using the assymetric algorithm, and encrypt the message using that key with a faster and symmetric cipher.
In its default setup, RSA is insecure. It needs a padding scheme to get full security. This "random key" method is part of such a padding scheme.


The general term for having your own people take the role of the "bad guys" in order to improve quality is Red Team, and every company that is serious about security does it. But there are a few rules to follow:

Keep it professional
These are company-sponsored attacks; the company is the target, not the individual. Do not attempt to collect personal data, passwords, or secrets.
Keep the lawyers in the loop
Your legal counsel is there to keep everything above-board and prevent things from getting out-of-hand and causing legal trouble. They set the rules, you follow those rules, everybody stays safe.
Run post-mortem analyses on successful attacks
The whole point is to make your company safer by finding and fixing weaknesses. If the attack that worked last week works again next week, then you haven't made progress. It's time to stop what you're doing and fix the problems. (NB: Your problems are your processes, not your people.)
Shaming your employees doesn't help
Pointing out the employee who clicked the phishing email this week does not prevent employees from falling for phishing. Even the most vigilant user can be fooled; it's human nature. You need to equip your users with sufficient technical controls and safeguards to help compensate for human fallibility.
Make it a positive experience
Recognize people for doing the right thing, not for doing the wrong thing. Competition can be helpful in keeping a topic present in people's minds, but you want recognition to center around success not failure.
Get everyone involved
Some of the most successful Red Team operations allow normal users to periodically rotate through the program and attack their co-workers in a safe and supervised environment. Getting a chance to be the attacker helps users better understand and appreciate the security measures that they have to live with. Further, if everyone is used to fending off and reporting attacks, it's much harder for a real attacker to go unnoticed.


Can trading cryptocurrency using Binance be a security risk?

Cryptocurrency is complicated. If you don't know what are you doing, it's very insecure. If you know the fundamentals, it's very secure. But it's a very bad idea to use a business server for that. Why don't you use another computer for that?


What's a secure firewall rules using UFW?

The general rule with firewall configurations is that you should allow as little access through the firewall as possible.

In the ruleset you've listed you're allowing access to 5 services from anywhere, so if you're on the Internet and there's no NAT device or other firewall between you an the general 'net then anyone can access and attack those services.

It may be of course that, that's intentional (i.e. you're offering public services which should be accessible from anywhere on those ports) however if this isn't the case I'd recommend restricting those to the minimum possible.

As an example if you're not intending to offer any public services (which most client systems won't be) shouldn't be allowing any inbound traffic (apart from responses to connections you start).

Also if these services do need to be accessible but only by certain people, consider restricting the source addresses that can connect to them.


sqlmap unable to find SQL injection vulnerablitity

Lets try to add --level=3 --risk=3 to you sqlmap command. If you increase the risk and level, then sqlmap tries more clever stuff to find and exploit. It means sqlmap will try to not only visible sql injection potential but also blind stuf..

Again same result you can add * to your vulnerable parameter in order to identify if sqlmap is posting to correct parameter or not


WireGuard: what's wrong with this automatic IP assignment

The problem boils down to your third point. You do not know what it does without reading it in detail and it contains quite a lot of unclean code.

It probably "just works", but if anything fails there is no error handling implemented. In addition it screen scrapes a few shell utilities without knowing if their output format is fixed. Maybe you upgrade your distribution, get a new version of one of the tools and suddenly the script fails.

  What is the worst case

Some of the output parsing fails and the next command gets garbled output and deletes /home. Not as an actual result of analyzing the script, but something which could happen with shell scripts without proper error handling and did in the past (I.e. rm -r $uninitialized/*).

The most likely error to happen is leaving you with broken network and as you have to ask for explanation of the script (which is fine. I would need to study it quite some time before fully understanding the risks of it) this would probably force you to reboot to get the system into a consistent state again.

This is not per se insecure, but it is sloppy and may be insecure. For a script which runs as root and setups important things there should be careful error handling for each thing which may fail.

The general devise is that everything has a risk of being insecure until proven to be secure. You could try to verify the script if it is secure, but it is not worth it as there are several anti-patterns (i.e. parsing output which is not guaranteed (yet) to be stable, processing IPs with regex, no cleanup when a line fails) which make it advisable to rewrite it in a more secure manner.

People may for example rely on the VPN to prevent sending confidential company data unencrypted over the internet. When the VPN script (silently) did not succeed setting up the VPN, the data may get sent insecurely.

  Is there a way to fix those issues?

Rewriting it with careful error handling after each command.
Probably in a better suited language than bash and reading the data using an API instead of screen scraping other programs.


Google Chrome browser warning for goo.gl

Google's Diagnostic page says:
http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http%3A%2F%2Fgoo.gl

  Part of this site was listed for suspicious activity 1 time(s) over the past 90 days.

URL-Shorteners are often used to obfuscate malicious links. Google's own link shortener is no exception.

Maybe the safebrowsing blacklist overreacted and just blacklisted everything below goo.gl


Does browser 'view-source' mode avoid scripting attacks?

Yes, it is absolutely safe (in Google Chrome) to open an untrusted website in view-source mode. The key point to note here is that you should "open" the page in view-source mode, meaning you should not allow any rendering to happen by normally loading the webpage first and then viewing the source.

An example in Google Chrome would be view-source:http://www.badjs.com/

By design, Google Chrome will initiate a new GET request to the server and provide the client browser with the unrendered version of the webpage when in view-source mode.

You could also use a No-Script extension or add-on for your specific browser to prevent any scripting attacks.


Just to be clear, it's explicitly not an SSL replacement.  It's a replacement for CAs, with the explicit design goal of not forcing some giant IPv6-like "change the world" rollout.  It's based in large part on earlier work on solving the SSH Host Key validation problem - see http://www.usenix.org/event/usenix08/tech/full_papers/wendlandt/wendlandt_html/

In Convergence, there are some number of network topologically distant "Notary" services, run by a diverse collection of different organizations.  The (self-signed) SSL certs for each of the Notary endpoints are baked into the browser.  When the browser hits an https site for the first time, it fetches the cert and then dials out to all N of its Notaries, and says "I went to talk to www.example.com:443 and got back this SSL cert.  Is it good?".  The Notaries issues a yay or nay.  If all the Notaries say "yay", the browser caches the cert up to the cert's natural expiration date.  On subsequent requests to www.example.com:443, the browser compares its cache against the cert it just received.  If there's a mismatch, it dials back out to the Notaries again.  Since sites don't do cert rotation that often, and browsers can do super-aggressive cert caching (and key-rotated certs get cleanly invalidated from the cache), it's not an inherently un-scalable solution.

The Notaries are free to set whatever policy they want for what constitutes a good or bad cert.  The suggested ones are "Notary's servers poll site", "Notary consults the EFF SSL Certificate Observatory", "Notary checks for what cert is on file in DNSSEC", or even "Notary does traditional CA validation".

I think it's the most unintrusive solution to the CA problem ever.  Aside from convincing MS/Apple/Google/Mozilla to jump on it (and the Citibank problem), there were two issues that bugged me.

First one is captive portals (e.g., airport or hotel wifi).  He handwaved past that a bit, and proposed using DNS as a fallback protocol to communicate with the Notaries.  But, there are numerous captive portals that'll just eat DNS records other than A & CNAME.

Second one is what's the financial incentive to run a Notary?  To scale, there are going to have to be tons of these things.  Some orgs might run them out of the kindness of their hearts, much as DNS roots are done, but I think the architecture of DNS scales quite a bit better than Convergence.


It's true that you can use a random string for the magic link and it'll work just fine. However there are a few benefits for choosing to implement it using JWTs:

JWT validation doesn't require a call to the database. This is perhaps the main benefit of using JWTs at all. Depending on the number of users this can mean a significant performance difference.
It is easier to integrate with existing login mechanisms such as identity providers (possibly 3rd party) that already handle creating/verifying/storing tokens. This is useful for example if your application is already using tokens for logging in users with the traditional username/password combination and want to add magic links as an additional option.

As for your question on the algorithms, for RS256/HS256 in JWT the purpose is not for encryption but for signing. The requirements on the algorithm for secure encryption and signing are different (and even more different if talking about password hashing).
As an additional note the reason to choose between RS256 and HS256 is whether or not you intend to allow others to verify your token.
For RS256 you create a public/private key pair. You generate the signature using the private key while a third party can verify a token you created using your public key. For HS256 the key for signing and verifying is the same so normally you keep it secret meaning only you can verify the token.


Is there any advantage of bcrypt over multiple iterations of SHA-x/MD5?

Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.

Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.


What risk does Carrier IQ pose, exactly?

Let's break it down by category.

What information does Carrier IQ monitor? Trevor Eckhart says (depending on the phone manufacturer) it receives each key pressed/tapped, the location of any tap on the screen, the contents of all text messages received, the name of each app that you open or switch focus to, information about each call you receive, your location each time location is updated/queried, the URL of each web page visited (including URL parameters; yes, even for https URLs), and possibly other information about each HTTP request.  I have not seen anyone dispute these claims.

Note that this is information that is monitored by the Carrier IQ application; that doesn't necessarily mean that the application does anything with the data, stores it, or allows it to leave your phone.

What information does Carrier IQ record on your phone? It is hard to get clear information on what  information might be stored in your phone on persistent storage or log files.  Does Carrier IQ log the information that it receives?  I don't know.

Carrier IQ says that their software "does not record, store or transmit the contents of SMS messages, email, photographs, audio or video", and they have said "we're not storing" keystrokes and that they "do not record text messages".  However, they also say that they do "record where you were when [a] call [is] dropped, and the location of the tower being used". Lookout says "it doesn't appear that they are sending your keystrokes straight to the carriers".  Dan Rosenberg seems to suggest that the Carrier IQ application is "recording events like keystrokes and HTTPS URLs to a debugging buffer", but it is not clear to me where that debugging buffer is stored (just in the memory of the Carrier IQ application? or on persistent storage of some sort?), and it is always possible I have misinterpreted his statement or read too much into a brief phrase.  Dan Rosenberg subsequently elaborated, finding that on one particular phone, CarrierIQ can record URLs visited (including for HTTPS), GPS location data, and phone numbers, but not all keystrokes, not the contents of SMS texts, and not the contents of web pages browsed.

CarrierIQ has subsequently clarified that their software does record "the telephone numbers the SMSs are from and to".

Trevor Eckhart said that the Carrier IQ software on his HTC phone recorded a lot of personal data (keys pressed, SMS texts, etc.) into a debugging log file, so this information is stored in the clear on his phone.  Carrier IQ has subsequently confirmed this finding.  Carrier IQ says this is because the debug capabilities remained switched on; it sounds like they are blaming HTC for not deleting or disabling the debugging code in the Carrier IQ software.  It is not known whether a similar problem may be present on phones from other manufacturers, or if this is limited to just HTC phones.

What information is transmitted to carriers? Carrier IQ says that only diagnostics information and other statistics leave your phone: "For example, we understand whether an SMS was sent accurately, but do not record or transmit the content of the SMS. We know which applications are draining your battery, but do not capture the screen."  Dan Rosenburg says that the software can also report your location (GPS) in some situations.  Carrier IQ has confirmed that their software captures phone numbers dialed and received and all URLs visited, if enabled by the carrier.

However, Carrier IQ also says that the amount of information that is sent to carriers is up to the carrier, and agrees that the Carrier IQ application has the capability to transmit what applications are being used and what URLs the user visits.  Some of the carriers have not been very forthcoming: e.g., Sprint says they "collect enough information to understand the customer experience with devices on our network and how to address any connection problems, but we do not and cannot look at the contents of messages, photos, videos, etc., using this tool" (not very specific); AT&T says their use of Carrier IQ complies with their published privacy policies, but hasn't said anything more.  Other carriers have been more explicit: Verizon and RIM say they don't use Carrier IQ and they don't pre-install it on any of their phones.  Apparently T-Mobile uses Carrier IQ, but I have not yet found a statement from them.

Carrier IQ has subsequently disclosed a bug in their code which may cause it, under certain special circumstances, to capture the content of text messages and inadvertently transmit it to the carrier, as the result of an unintended bug in their code.

How is the information transmitted to carriers? Carrier IQ says says that any information that is transmitted off the phone is sent over an encrypted channel to the carrier.  I haven't seen anyone dispute this statement.

Can carriers or others command the application to change any of this? I don't know.  I can't tell if there is a way that carriers or Carrier IQ can send a command to the Carrier IQ application to cause it to collect, record, or communicate more information than it does in its normal operating mode.

Trevor Eckhart says that carriers can "push" a data collection profile to a phone.  He also says that the profile specifies what data is collected, stored, and transmitted off the phone by the Carrier IQ application, and that any data that is received by the Carrier IQ application is potentially eligible to be transferred off the device, if the profile specifies that.  He suggests that a "portal administrator" (at the carrier, presumably) thus has the ability to target a particular subscriber, push to them a profile that causes the phone to transmit a broad variety of information (keys pressed, contents of text messages, URLs, etc.) off the phone, and then can view this information.  If this is accurate, it suggests that, even if the application does not normally transmit this information off the phone, the carrier has the ability to force the application to do so.  It is not clear if there is any notification to the user or any attempt to gain consent before this occurs.  I have not seen any independent analysis of these claims.

CarrierIQ has subsequently confirmed that it is possible to send control messages to the CarrierIQ software via SMS, to command the CarrierIQ software to perform certain tasks.  CarrierIQ has not clarified what is the full range of commands that can be sent, or how the CarrierIQ software authenticates these command SMSs to make sure they are not exploited by attackers, so it is difficult to assess the risks associated with this feature.

Other information sources. Wikipedia has a page on Carrier IQ, which includes some updates, a list of carriers and handset manufacturers who do or don't deploy Carrier IQ, some reactions from policymakers, and lawsuits against Carrier IQ.


Depends on what you want to "test"

If all you care about is port scanning, then the two above-mentioned addresses are perfectly fine. It demonstrates how nmap works, and you can use these hosts to try out some further scanning techniques (Service Detection, OS Detection, etc.)

You can also port scan some internal devices, such as:

PC
Laptop
Smart Phone
Game Console
Router (Internal & External IP)
Printer
"Smart" Devices (Fridge, TV, Lightbulb, etc.)

Since you are the owner of these devices, you can scan them freely as you want. You'd be surprized what you can discover there.

What if you want to "test" more invasively?

Port Scans are kind of a grey area, depending on the applied jurisdiction. Some consider it a crime, some don't regulate it at all. And while it may not be legal, a lot of port scans happen all the time over the internet. That doesn't make it alright of course, and you should not interpret my previous statement as "It's alright to do it". The golden rule of ethical hacking is to never attack a system you don't have permission to attack.

But what if you want to do more invasive testing? You have several options:

Install a local vulnerable system

You can install intentionally vulnerable distributions such as Metasploitable or insecure services like OWASP Juice Shop. These are designed to be learning tools for people interested in learning penetration testing. Since these run locally on your own system, you can freely test them however you want.

Use a remote vulnerable system

Services like Hack The Box offer similar vulnerable "boxes", which you can attack within the permissible parameters of their EULA. These are generally designed as explorative teaching tools, meaning you will learn new things as you try to exploit them.

Participate in a Bug Bounty program

Some companies offer bugs for vulnerabilities in their programs or services. It's possible that some company explicitly allows you to test for e.g. XSS vulnerabilities on their service. In that case, you do have explicit permission to test that.


Can Internet logins occur from the private IPv4 address range (10.x.x.x)?

Well, it can be a misconfiguration of a webserver if the client uses proxy to reach the outer world and proxy adds a header 'Forwarded' - see the wikipedia example here - it can look like 'Forwarded: for=192.0.2.43, for=198.51.100.17' - and it's totally OK for private network addresses to appear in for-part of the header. If the webserver tries to separate users originating from the same IP but having different LAN ip's in an old way - it can result in such a metrics. However, to be fully correct, an external IP address should be shown as well.


How to use a port scanner in a hostile manner

Those are vulnerability scanners, not just port scanners. People use them to find vulnerabilities in systems. It doesn't matter what their intentions are. If there are vulnerabilities, there's a fair chance the scanner will catch it. A hacker can chose to exploit any exploitable vulnerabilities. The scanners themselves don't exploit the systems; an attack would need another tool, such as Metasploit.


Thunderbird - what happens if Gmail SSL cert gets spoofed?

Thunderbird will complain if it gets a "wrong certificate". A "wrong certificate" is a certificate that either contains the wrong name (i.e. it does not designate the expected server name), or cannot be validated by Thunderbird (not signed, directly or indirectly, by a root CA that Thunderbird trusts; not valid at the current date; or any of the other hundred tests which lurk deep in X.509 validation process).

Thunderbird, by default, trusts about 80 root CA. Claiming that none of them may be bribed or conned into emitting a fake certificate is a kind of leap of faith. You can, though, trim that list at will (Preferences -> Advanced -> Certificates -> View Certificates).

Also, when Thunderbird complains, it does so in a non-fatal way: the user can still override, and it is as simple as clicking on a "do it now you moron" button. Refusing the certificate means not reading your emails; the email-reading urge is such that many users will readily bypass the security warning without remorse, often without even reading the warning message.