Firewall design for big enterprise business I am wondering if there is any best practice firewalling rules that should be put in effect in most modern networks.

For example should the network atleast have the following firewall zones?

Client network
DMZ
Customer facing network (internett)

Is it considered best practice to keep and maintain firewalls inside the zones (on each individual server) aswell as on the zones itself?

I would appriciate any tips regarding best practice designs of firewalls.

'Best' is probably not the right word here, as the specifics vary with needs, however 'standard' industry practice for enterprise level financial services organisations (a good benchmark) includes:

Client network, with segregated access-controlled subnets for specific key assets (usually customer databases, HR data, financial data)

FIREWALL

Multiple DMZ's - usually split either by function or risk profile (eg a DMZ for transactional services, one for remote access for staff, and another for 3rd party connections)

FIREWALL

Internet, remote clients etc

Firewalls should be from different vendors eg Juniper, Cisco, Checkpoint etc. to increase the time an attacker would take to get past them both (would require two exploits)


Realistic: Exploiting a computer on BIOS/ hardware level in less than an hour? (Infinite preparation time) I wonder how hard it it to infect a laptop or netbook in 60 minutes or less in a way the victim cannot easily clean their machine by wiping hard disk drives.

Let's assume the following:

The attacker has physical access to the machine. I.e. they wait until their victim leaves their desk. They know how long their victim will be away. (I.e. 5 minutes or an hour.)
The machine is either turned on (and must stay that way) or turned off (and must stay that way), or the victim will notice.
The victim's machine has USB-ports, ethernet cable connection, wireless LAN and (possibly) Bluetooth enabled.
The attacker has as much time to prepare their attack as they need, even some years. They have several chances to try, as long as they don't break anything.

The hack must result in the following:

The victim will not be able to remove the infection by reinstalling their system or securely wiping the disk or buying a new hard disk. (1)
The victim will only be able to remove the infection by using a completely new mainboard, or at least flashing the BIOS chip (just resetting shouldn't help).
The attacker will be able to steal the victims data (minimum requirement), for example passwords or company data. They must at least be able to use keylogger-like functionality, better gain complete control over the victim machine.
No dirty old never-updated-Windows exploits. The victim is running a regularly updated Unix derivate (i.e. latest OSX or Linux).
The victim would notice an attack if there was anything to notice. Nothing remotely visible must change. The victim expects being attacked, and will assume a technical error is an attack, no matter how unlikely it seems to be. The victims skill level is a somewhat experienced coder, but not in the hardware field. The victim, however, trusts their coworkers to a certain point, i.e. leaving their machine for lunch.
No fance UEFI things here. Plain old BIOS, with a lot of data available about it. (It isn't a new laptop.)

I leave the methods the attacker uses in detail completely open.

Their skill level however should be assumed to be extremely high. (For example, someone with 20+ years of experience, good at ASM, C++, and C, with a high knowledge of hardware as well as software and very good Unix skills. Fascinated by exploits and hacking for all their lives, and having succeeded pretty often breaking into hard- and software systems, as well as at reverse engeneering. I.e. they might pull off anything a single person is able to do, and will find their tools. However, if they found a tool which would get them the job done in 5 minutes, they'd use it. They're pretty pragmatic.) Let's say they are a (secretly criminal) programmer who's more experienced than anyone else on the team, the only one who is not just a "web guy" or sysadmin.

If you were such an attacker, how would you do it? Would you think it's possible, and how would you try? (The requirement "a new harddisk and wiping all data including backups won't help" must be fulfilled. The rest is up to you.)

(1) An easy "software" way to do this would be to infect a file the victim will keep accessing over and over again, either remotely or locally. This, however, does not fulfill the requirement. The infection must persist even if all data is wiped completely, and the machine will never access the company network again.

This video demonstrates a complete re-soldering of a laptop BIOS chip in 10 minutes: https://www.youtube.com/watch?v=HMAxv6lgSuw

Joanna Rutkowska (girl behind the Blue Pill rootkit) discusses the feasibility of a "Ring -3" rootkit of the SMM which resides on the BIOS chip: http://theinvisiblethings.blogspot.com/2009/03/attacking-smm-memory-via-intel-cpu.html

And this presentation talks about the implications of hacking the SMM, giving you full access even remotely, fully undetectable.  Even the user monitoring network connections for suspicious traffic could have an SMM rootkit fool the network card beyond the driver level: http://me.bios.io/images/6/61/Ring_-3_Rootkits.pdf

The attacker, knowing the laptop beforehand, would use the technique to hack SMM on a chip he got for cheap off eBay, then bring in the chip and a soldering iron for the actual attack.


BREACH attack and content length I've been researching BREACH, and while I can understand how it might work if you have access to the the browser (to send crafted requests) and the wire (to capture compressed response length), I haven't seen a way to do this without access to the wire, aside from a fragile timing attack on response time. You can get Content-length with this code, but it only works if the site enabled CORS and isn't used a chunked Content-length.

var req = new XMLHttpRequest();
req.open('GET', document.location, false);
req.send(null);
req.getAllResponseHeaders().toLowerCase();

There's also an iframe approach, but I'm not aware of a way to get the Content-length for an iframe, and again, this fails if it's chunked.

Am I missing something? I there a technique I haven't covered for getting the Content-length? It doesn't seem to be a viable attack without both access to the browser and access to either that, or to the wire.

The BREACH attack is a Side-Channel attack. You need some way to access the side channel.

On page 13 of the presentation, you can see what BREACH needs the attacker to set up:

A web server serving the site the browser visits.
A callback where the javascript on the victim's browser notifies the attacker that the request completed, giving time information about when the packets with the currently tried string went through.
A MITM for monitoring the length of the sent packets.

So, in other words, you need access to the wire.


How dangerous is game guard? Game guard is an anti-cheating application used with MMORPGs . I have read that such applications  acts as rootkit over the pc. How dangerous it is to play MMORPGs that uses this application? How could it be exploited (either by the company it self or by a malicious hacker) who hacks into the pc or the main company?

When you accept to run software from anyone, including the game itself, you are already trusting that software. If the software publishers are intent on attacking your PC, then they can do it from the main game binary; they don't need to use Game Guard for that. As a corollary, refusing to run Game Guard will not protect you from that company.

One case could be made that Game Guard, being used by many games, becomes a higher-value target: successfully planting a backdoor in Game Guard would give access to a lot more machines than a backdoor in just one game. In that respect, Game Guard comes close to operating systems.

How dangerous Windows is ? (or Linux, or MacOS X,...)


Wireless Adapter + Arduino 'Bug' First, I am new to ethical hacking. And also I just realized that I need a wireless adapter for wireless attacks. I'm currently mastering Python, and some basic knowledge in Bash and Arduino.

What I Need

I need a sort of 'bug' or gadget to connect to via wireless adapter and can be placed and hidden it somewhere, or at least to get some distance from my target (for now let's just say my friend's house). Or maybe (if possible) make a fake Wi-Fi Router with a fake SSID. With this, I can monitor and scan and possibly hack the network around the bug/gadget. This gadget should be small enough so I'm thinking using a Wi-Fi Adapter and Arduino + Wi-Fi Shield or 2 Wi-Fi Adapter and Arduino with some sort of Battery or solar panel.

The Question

Maybe a visualization will help understanding of my idea:

-------   _
|  a  |~~/b\~~>to c        -some distance-                   _
|     |                                           from b ~~>/c\
-------

where:
a. Target's House        |   ~~> or ~~ : connected wirelessly
b. The Bug or Gadget     |
c. My Laptop             |

Is this possible?
Does this thing already exist? This is maybe
because I'm new and don't know.
How should this be working?
What do I need?

If you are thinking of Arduino + bits, I'd recommend using an ESP8266. These are just a few dollars and come with Wi-Fi and an embedded microprocessor similar to an Arduino.

Wemos do a small fully configured ESP8266 device and a battery charge/use addon that will support LIPO batteries.

However, those might be rather restrictive in terms of what you can run on them in order to run Wi-Fi audits.

So probably better would be an SBC - Single Board Computer. Raspberry Pi's are possibly the most famous and the cheapest of those is only around $10. But there are many more. You would need to add battery and Wi-Fi (some SBC's come with that built in) and an SD card. They typically run Linux though a Pi will run Windows 10 Core if you like :-)

You would still need to get/write some software but as you are running a fairly standard OS, you can run standard network scanning/auditing tools and the like.


Is it ok to delete SSH configuration files? From what I read, SSH is mainly used for remotely accessing a machine. If I don't want anyone remotely accessing my machine, nor myself included, is it ok to delete these configuration files from my Linux system? Can doing so break the integrity of any secure network or system protocols I have by default?

I'd ultimately remove each file by first getting to the file's directory and using sudo rm

If you don't want a SSH server running on your system at all, the better approach is to remove the package that provides the SSH server software. Doing so will remove it cleanly, though it is possible (depending on your distribution) that packages depend on the SSH server packages for some reason. If you just remove its configuration files, odds are good that the system will try to start it anyway, and it will start logging errors (which will clutter up your logs and ultimately might hide something actually interesting).

To do this, use your package manager to remove whichever package provides the SSH server. On Debian and Debian derivatives, you'll likely want to remove openssh-server as seen by searching the list of packages for OpenSSH packages: dpkg -l '*openssh*' by running sudo apt-get remove --purge openssh-server Other systems are likely to be different, so adjust accordingly.

Removing the SSH server shouldn't break anything else as long as the package manager doesn't want to remove additional, unrelated packages; and you can always reinstall it later if you want to.


Site accepts creation of long password, but not usage There is a website my company uses for personal data provided by a second party. In the password creation page it is possible to create a 30-character password, but attempting to login with this password throws an invalid password error. Using shorter passwords are possible.

Should my company be concerned? Is this indicative of deeper flaws in their security?

Obviously whoever built this was not very good at what they were doing and/or not really paying much attention to detail. When working with security critical things like authentication, that's not great.

Think of it like this: If you found that your electricity guy had accidentally installed the outlet sockets upside down, that in itself isn't the end of the world. But wouldn't it make you a little bit worried that he messed up something else more critical and your house will burn down?

Also, short limits to password length might be an indicator of a legasy system with no or bad hashing. Even worse, as jrtapsell highlights, the fact that the password is accepted when set but not at logg in could be a sign that it is truncated when inserted into the database and hence stored in plaintext.

So while this is proof of nothing, it should still set off your alarm bells.


HDD Good for Encryption? Ok so I keep second guessing myself whether of not I should use encryption on this drive. I just found out it's not an SSD and here I was asking questions on encryption on SSDS. Huhh..... But yeah, just curious if this drive should be ok for disk encryption. I am concerned about wear leveling, etc.

Hard Drive Specs

 sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
    Model Number:       WDC WD10JPVX-75JC3T0
    Serial Number:      WXJ1E744R55H
    Firmware Revision:  01.01A01
    Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
    Supported: 9 8 7 6 5
    Likely used: 9
Configuration:
    Logical     max current
    cylinders   16383   16383
    heads       16  16
    sectors/track   63  63
    --
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors: 1953525168
    Logical  Sector size:                   512 bytes
    Physical Sector size:                  4096 bytes
    Logical Sector-0 offset:                  0 bytes
    device size with M = 1024*1024:      953869 MBytes
    device size with M = 1000*1000:     1000204 MBytes (1000 GB)
    cache/buffer size  = 8192 KBytes
    Nominal Media Rotation Rate: 5400
Capabilities:
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, with device specific minimum
    R/W multiple sector transfer: Max = 16  Current = 16
    Advanced power management level: 254
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
    Enabled Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    NOP cmd
       *    DOWNLOAD_MICROCODE
       *    Advanced Power Management feature set
            Power-Up In Standby feature set
       *    SET_FEATURES required to spinup after power up
            SET_MAX security extension
       *    48-bit Address feature set
       *    Device Configuration Overlay feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
       *    General Purpose Logging feature set
       *    64-bit World wide name
       *    IDLE_IMMEDIATE with UNLOAD
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Host-initiated interface power management
       *    Phy event counters
       *    Idle-Unload when NCQ is active
       *    NCQ priority information
       *    Host automatic Partial to Slumber transitions
       *    Device automatic Partial to Slumber transitions
       *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
       *    DMA Setup Auto-Activate optimization
            Device-initiated interface power management
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT Write Same (AC2)
       *    SCT Features Control (AC4)
       *    SCT Data Tables (AC5)
            unknown 206[12] (vendor specific)
            unknown 206[13] (vendor specific)
            unknown 206[14] (vendor specific)

Looking at the specifications you've posted, its a SATA 3 compliant disk supporting 6 Gbps signalling speeds. That matches up to most current generation desktop/laptop hard drives which are quite capable in terms of I/O speeds.

The additional overhead of Disk encryption is actually placed on the processor and lesser overhead on the drive.  If you're going to be using CPU intensive workloads coupled with disk I/O intensive workloads on your system then, disk encryption will definitely slow you down. To mitigate this somewhat you can switch over to the latest generation intel Broadwell processors have improved AVX instructions which speed up encryption workloads.

But when evaluating whether to deploy disk encryption, consider the costs and the impact of a possible data theft vs. cost of the solution and cost of performance penalty on the system.


Is symlink race a very common vulnerability in UNIX systems As far as I know, when I am creating a new file or directory in a directory that can be written by multiple users (and thus an adversary can have made a symlink there), the only way to protect myself from symlink race is creating a file with enough random name.

Well, some app might have checked if such file already exists, but I am not aware of any mechanism that is both atomic and able to detect symlinks.

So, when there are many non-random (or even reused) filenames in /tmp from various apps, it means all these apps are vulnerable to symlink race, doesn't it? (Well, it can't be simply decided if the vulnerability can be easily abused, but I don't care about practical exploitability for now.)

I hope I must be somewhere wrong.

So this should answer the question of "is symlink common?"

A search on the MITRE database shows there are 4 CVEs for a Linux Symlink Race condition vulnerability. For comparison, there are 2749 Linux CVEs known to MITRE.

Linux at the kernel level has protections against this. Kees Cook created a patch for Linux to prevent this problem:

  The solution is to permit symlinks to only be followed when outside a sticky
  world-writable directory, or when the uid of the symlink and follower match,
  or when the directory owner matches the symlink's owner.


Why do bots visit my website even though it hasn't been shared with anyone yet? Is this usual? These bots hit my website every 15 minutes and they're the only visitors I get since I haven't shared the website with anyone yet... How do they even know about my website?
What is the purpose of this, are they trying to scrape info off of my page or something? Is this a privacy issue?

Why do bots visit my website even though it hasn't been shared with anyone yet?

Various reasons, mainly to scan and index the internet (companies like google, bing, yahoo, etc) and to find vulnerabilities to hack your website and use your servers for their own purposes.

Is this usual?

Yes.

How do they even know about my website?

There are many ways they can learn about your website, one of the more common is they watch new domains as they are registered and scan each as they come online.

What is the purpose of this, are they trying to scrape info off of my page or something?

Information and hacking mostly as described earlier.

Is this a privacy issue?

That depends on what you have on your website.  Anything you put on the internet shouldn't be considered private anymore.  Most websites that curate private information (social media, banks, email) create logins to keep the scanners from gaining access to items that would create a privacy issue for your users.


how to do 2 way ssl authentication without using a self signed CA I have a requirement to set a 2 mutual ssl authentication between our apache and an application. I have purchased a cheap SSL from rapid SSL in order to do this.
RapidSSL sent a zip folder with

CACertificate-1.cer  (RapidSSL SHA256 CA - G3)
CACertificate-2.cer  (GeoTrust Global CA)
ServerCertificate.cer (Actual Certificate)

But I am stuck at the point where I need to create client's certificate. The cafesoft.com tutorial I am following makes use of the CA's certificate key to generate/sign the client's certificate. Obviously I don't have the CA's Certificate key. How to go about this? Should I just gave up and use a self signed CA or there is a way to do this?

Thanks in advance,

The server certificate and the CA certificate used for authenticating your clients are two different things.

First, you need to have your server certificate installed (SSLCertificateFile and SSLCertificateFileKey). You should already have that.

At this point, you have your server presenting his certificate to clients.

Now, you need to generate a CA (self-signed) and tell your Apache instance that this is the CA you want to use for authenticating clients. (SSLCACertificateFile and  SSLVerifyClient require)

You just have to sign your clients csr with your newly created CA.

Cheers.


Perfect Forward Secrecy cipher suites I have not found a straight forward way to determine where a given cipher list supports PFS or not. For instance, how can I use output of:

$ openssl ciphers -v aECDSA:aECDH:kEDH:kRSA

to determine if any of the configurations supports (non) PFS based communication?

Perfect Forward Secrecy is obtained by using Ephemeral Diffie-Helman keys (DHE or EDH). So to get the cipher suits in that list that support PFS you could do:

$ openssl ciphers -v aECDSA:aECDH:kEDH:kRSA | grep DHE

This will include ciphers based on ECDHE (Elliptic Curve) as well as DHE (RSA). An advantage of ECDHE is that it is a lot faster than DHE. However in the list generated by that command there are still quite a few weak ciphers that use weak or no crypto: DES, RC4, SSLv3, NULL.

All of those happened to have SSLv3 in common, so by excluding SSLv3 you get a list of 12 solid ciphers:

$ openssl ciphers -v aECDSA:aECDH:kEDH:kRSA | grep DHE |  grep -v SSLv3

  ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
  ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
  ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
  ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
  DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
  DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
  DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
  DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
  DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
  DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
  DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
  DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256

Do note that you are excluding 4 PFS ciphers with your aECDSA:aECDH:kEDH:kRSA selection.

  ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
  ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
  ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
  ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256


Did iOS 11.1 fix KRACK for only iPhone 7 and newer? This security article from Apple says that 11.1 fixes the KRACK vulnerability for iPhone 7 and newer devices. But what about the older devices? Has Apple not fixed them or does the vulnerability not affect these devices?

It seems, that you were spot on with your questions. Several news sites report the same, for instance ArsTechnica mentions:

  Update: As Ars readers have pointed out, Apple's support documentation states that the iOS KRACK fix is available for iPhone 7 and later, and for the early 2016, 9.7-inch iPad Pro and later. It is unclear whether this means previous devices are still vulnerable, or they had previously not been vulnerable and thus didn't need an update. Ars has reached out to Apple for comment.

EDIT:
I dug through the comments on ArsTechnica and found this post. It states the following:

  For iOS, the bug was fixed in iOS 10.3.3. I was able to establish a theory based on firmware analysis and tested the theory on a few devices running older and newer iOS firmware. The pattern was that devices with A8 processors were vulnerable (crashed the Wi-Fi chip) if running iOS 10.3.2 or earlier, but models with older processors were not vulnerable for any iOS version I could test. (I wasn't able to test any A9 or newer models running iOS 10.3.2 or earlier, but firmware analysis points to them being vulnerable as there were fixes in 10.3.3.)

In the macrumors forum I've found this post, which says something else, I wasn't able to find the part in the transcripts until now. Maybe someone else can shed some light on this.

  Yep apparently in the older devices iOS WPA2 implementation was not correctly done and as a side benefit are not vulnerable to KRACK. According to Steve Gibson of Security Now, iOS was not vulnerable to KRACK because they misimplemented the WPA2 specification. My guess is iP7 and up is when WPA2 was fixed and therefore now those devices need the patch! Perhaps Apple will relay this information soon to clear it up for all. That could mean the non iOS11 compatible devices are all fine as well.

So that might be the reason why there was only a fix for the newer devices.
In the KRACK paper itself, the iOS 10.3.1 was marked as not vulnerable to the retransmission of the 3rd message of the 4-way handshake.

Quote from the paper:

  In particular, Windows and iOS do not accept retransmissions of message
  3 (see Table 1 column 2). This violates the 802.11 standard. As
  a result, these implementations are not vulnerable to our key reinstallation
  attack against the 4-way handshake.

But:

  Unfortunately, from
  a defenders perspective, both iOS1 and Windows are still vulnerable
  to our attack against the group key handshake. Additionally, because both OSes support 802.11r, it is still possible to indirectly attack them by performing a key reinstallation attack against the AP during an FT handshake.

1 This is iOS 10.3.1

So both OSes are still vulnerable, but not what is "commonly" known as KRACK - which would be exploiting the 4-way handshake. I guess iOS 11.0 had a correct implementation of the 802.11 standard and this is what was now fixed. (The description in the patch notes sounds a bit fuzzy to me tbh.)

Here's a screenshot of that fancy table:


PCI Compliance ISP requirements I am setting up a PCI compliance call center. I am wondering if my internet service provider has to be certified PCI compliant? I am only connecting to a cloud service that uses SSL and that cloud service is PCI compliant. Will I run into any issues if the ISP is not certified?

No, the ISP does not need to be PCI compliant in this regard. If you were not communicating over a secure channel (i.e. TLS) then you would be violating the data-in-transit requirements of PCI DSS anyway.

Another way to think about this is from the customer perspective - if there's a PCI DSS complaint public-facing website, does the customer's ISP have to be PCI DSS compliant? No - the onus is on you to ensure that the transport layer is properly encrypted.

In such cases, TLS is considered a compensating control, meaning that something that you are doing would not strictly be compliant (e.g. sending card data in transit through someone else's public network) but you have implemented additional security controls that mitigate that concern.

As an aside, keep in mind that the PCI council is in the process of deprecating TLS 1.0 (all prior versions are already deprecated) such that you will not be compliant if TLS 1.0, SSLv3, or SSLv2 are enabled on any service on your network.


What are the risks of making a mobile phone an access point for non-trusted users? I was on the train last night, and what appeared to be a business man asked me if I could give him wifi access. I declined due to battery consumption and the fact that I am little paranoid, but would like to know if I would be risking anything if I let him (apart from him accessing dodgy sites which could get me in trouble). By the way my Iphone is updated to its latest version and isn't jailbroken.

The main attack vector that has been opened up is that you are now on the same LAN. I don't know how your smartphone implements some security measures so i'll assume it behaves like a PC. Being on the same LAN means that he could read sensitive information not sent over https. He could also perform standard network attacks like ARP spoofing between you and anyone else on the network to intercept and block traffic.  Apart from network manipulation, if you phone has services exposed that contain exploits, they could now be attacked while before they could not.


How to view all SSH authorized_keys for a unix server How would I view all the authorised SSH clients from a unix server?

I know that cat ~/.ssh/authorized_keys shows authorised keys if logged in from root.  Can other users set their own authorised keys too?  In which case, how would I view all system authorised keys?

To answer your questions in order:

You can see all authorized keys by running the following script with root privileges.

#!/bin/bash
for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do
    if [ -s "${X}/.ssh/authorized_keys" ]; then
        echo "### ${X}: "
        cat "${X}/.ssh/authorized_keys"
        echo ""
    fi
done

Any valid user may create a $HOME/.ssh/authorized_keys file and add any number of public keys to it.  Someone with the corresponding private key will then be able to log in as that particular user.  The process sshd follows is like the following.  When a new connection comes in sshd asks the client for the username.  If the username exists in /etc/passwd, sshd then reads the name of the user's home directory from the sixth field in /etc/passwd.  It then checks if .ssh/authorized_keys exists in that user's home directory and if permissions are correctly set on both the .ssh directory and authorized_keys file.  If those conditions are met, sshd will then attempt to authenticate the client's private key against the public key stored in $HOME/.ssh/authorized_keys.  If the client possesses the matching private key, sshd will allow it access.
You may use the script above.

S.L. Barth makes an excellent point about root access.  It is considered a risk to allow root access through ssh.  The generally accepted practice is create a user account, grant it root access with sudo or a similar tool, and disable root logins through ssh by adding the following line to /etc/ssh/sshd_config and restarting sshd.

PermitRootLogin no

Chances are almost 100% that if your machine is on the Internet that the "Hail Mary Cloud" will be knocking at your door.  For Linux, iptables, and sshd where you allow password based logins, you will probably want to install and configure something like fail2ban so it's harder for attackers to brute force your machine.

And, since we're already talking about ssh keys, and because this was posted today, you probably want to add UseRoaming no to the Host * section in your /etc/ssh/ssh_config


How to deal with third parties in physical pentests? From my previous question, I've seen that a "Permission to Attack" slip is crucial in ANY Penetration Test. However, that question and its answers and comments have only discusses interactions between the Pentesters and the client's party (their staff).

How should we deal with 3rd parties such as:

"Casual" targets

Neighbors
3rd party staff (real elevator maintenance, real CISCO staff, etc)
Non-staff people (customers of the company, guests, patients in a hospital, etc)

Dangerous people

Local law enforcement (the police)
A real possible criminal (having both a Red Team and real criminals breaking in at the same time sounds tough)

I've seen (read articles) some say that we should always tell the police the truth rather than try to social engineer them. I've also heard people talk about themselves tricking local police like staffed security. Some also say that we should present and confirm our Permission to Attack with local law enforcement beforehand as we would with the employer.

It depends very much on the situation and your contract.

Usually, reputable companies who conduct physical pentests have extensive guidelines for their pentesters in many situations. Such instructions are to be followed. I'm going to give a rough overview over possible ways such third-parties may be interacted with:

Local Police

Local Police is to be treated like police is treated anywhere else. A Permission to Attack means that you are legally allowed to conduct a physical pentest, not that you have the authority to ignore the police. Should a police officer instruct you to identify yourself or similar, you have to follow suit.

In fact, the fact that you are conducting a pentest is completely irrelevant to any police interaction. Interact with police in accordance to local laws.

Neighbors

Neighbors are people that have nothing to do with the pentest you are performing. You can't be granted any authority over them, just like the company that hired you to perform the pentest has no authority over them.

That doesn't mean you can't strike up a friendly conversation with them if you happen to see them doing some garden work across the street and see what kind of information you get out of them. But for the purposes of your assignment, they are not any different from regular people you meet on the street. Again, your involvement in this pentest doesn't change anything.

Third-Party Staff

This should be covered either in a general policy of your employer, or specified in the contract of the assignment. In general, they are likely to be treated like any "regular" employee of the customer.

For example, if you can walk inside the perimeter together with the guy who was hired to fix the printer, all the better.

Non-Staff People

Tread carefully! Attempting to social-engineer customers, guests, patients, etc... can very quickly become a very difficult subject for you. This should actually be discussed with the client beforehand, and be explicitly written down.

For example, interacting with patients in a hospital may make them and their families feel disrespected, and you want to avoid that.

Emergency Personnel

In case of an earthquake, a pentest would be the least of my worries. Should emergency personnel appear on-site, aid them as best as you can. You don't know the situation, and somebody's life may be in danger. A pentest can always be done again tomorrow.

Real Criminals

Contact security or law enforcement immediately. Don't play hero, just do your job.


Using weak Veracrypt password safe? Is it safe to create a Veracrypt partition (on a USB) such that

it takes up the whole device (ie. not a "file", but using the USB as the storage container)
it contains only a standard volume (no hidden volume)
it uses a weak password (eg. 123456)
it is quick formatted (ie. not overwritten with garbage)
no one obtains the volume header during this time (while the weak password is in use)

I then easily mount and dismount the Veracrypt container adding files. After I am done (eg. after a few days or a week), I change the volume password (eg. from 123456 to Zdbze5CVPFTPUrPbxzM4GG3N8sTnAktRRcFyYftkdWsUg).

I am concerned that by initially using a weak password then changing it to a sufficiently strong password, the security is reduced.

In particular, if an attacker tries to recover the volume header (of the weak password) from the start and end of the partition, they can use either the complex password (Zdbze5CVPFTPUrPbxzM4GG3N8sTnAktRRcFyYftkdWsUg) or the weak password (123456) to unlock the Veracrypt container.

Generally the master key is encrypted (wrapped) using the password. If this wrapped key is overwritten by the same key wrapped with the secure password (using password based encryption, as Veracrypt uses) then the result should be secure.

The problem with flash based storage is that it may not actually overwrite the password but write it to another page (because of wear leveling). Direct access to the flash may then be used to retrieve the old wrapped password, and a brute force attack could then be used to retrieve the master key. This will not be easy to do, but it isn't impossible.

More information in this answer.


What hashing/encrypting to use for publicly shared string matching a secret code I am looking for the database-free way how to validate a secret code that was sent to user's mobile phone by RESTful web app, in a 2-factor authentication process.

At step 1, the user provides login name and password that is validated with the data from the database. Now the system generates a code that is sent to user's mobile phone. For convenience, the code should be relatively simple, let's say 5 numeric digits. User must provide this code in order to complete the authentication process.

I'd like to avoid the trips to the database as much as possible, so I use JWT to keep the state. But it would be absurd to store the secret auth code in the JWT, because it can be easily extracted at the client side. Therefore, it should be stored in hashed or encrypted form. I am considering salting the secret code with strong salt (known only by the server) and then store the SHA256 hash of the result (bcrypt hash is no good here because it contains the salt). That would make the secret code hidden from any prying eyes, but still useful for validating the code when provided by someone who knows it. And the server can happily forget the code meanwhile.

Can this approach be considered secure for the given purpose?

You're looking for message authentication codes, not pure hashing. You could probably do something like the following:

The server generates a code. It also keeps a secret (that's basically what you meant by your secret salt). Then it calculates

mac = hmac-sha256(code, secret)

mac is stored in your jwt. When the user enters his code, the server uses it and the secret only the server knows to calculate mac2, and if mac2 matches mac, the user entered the right code.

Edit: You've correctly pointed out that this can be exploited because the same code always yields the same mac. So you can correct for this problem like so:

mac = hmac-sha256(code || salt, secret)

Now you have to store salt along with mac in your jwt. Choose a new random salt every time you generate a new mac. I think the above construction is safe, but you might want to google a bit to make certain.

HMAC is a protocol to use to generate message authentication codes (macs), see Wikipedia for more information. Most programming languages offer a library to work with HMACs.


What kind of requests are those? I receive a lot of requests like this:

ip-10-80-XXX-XXX.eu-west-1.compute.internal:80 110.249.208.XXX - - [11/Dec/2013:10:27:17 +0000]
"GET http://mn.sina.com.cn/news/xianchang/2012-06-07/212535.html HTTP/1.1" 200 9515
"http://mn.sina.com.cn/news/xianchang/list.html" "Mozilla/5.0 (w3660t by Kev++)"

I don't understand what this request want. And what can I do against it using Apache. Currently it seems they are all coming from the same IP address block. I'm using a AWS server. I have some proxy functionality enabled on Apache.

ip-10-80-XXX-XXX.eu-west-1.compute.internal:80 110.249.208.XXX - - [11/Dec/2013:10:27:17 +0000]
  "GET http://mn.sina.com.cn/news/xianchang/2012-06-07/212535.html HTTP/1.1" 200

They are fishing for an open HTTP proxy, and your 200 response code says they found one.

By operating an open proxy, you're enabling people to launch any number of web attacks through you; it's even worse if you don't include X-Forwarded-For headers with their source IP.  Do you really want to enable other people's (potentially harmful) activity with your web server?

If you must keep proxy functionality on the server and want to stop the abuse, at least configure it with one or more of:

HTTP Authentication
An IP ACL which limits proxied traffic to a trusted block of IPs (incorporating Shadur's comment)


What cryptographic flaw was exploited by Flame, to get its code signed by Microsoft? Today, Microsoft released a security advisory warning that the "Flame" malware exploited a weakness in a cryptographic algorithm used by Microsoft Terminal Server Licensing Service, and was thereby able to get some of its code signed so it appeared to have come from Microsoft.

Here's what Microsoft wrote:

  We have discovered through our analysis that some components of the malware have been signed by certificates that allow software to appear as if it was produced by Microsoft. We identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft. Specifically, our Terminal Server Licensing Service, which allowed customers to authorize Remote Desktop services in their enterprise, used that older algorithm and provided certificates with the ability to sign code, thus permitting code to be signed as if it came from Microsoft.

See also this blog post from Microsoft.

So, what was the exploitable cryptographic algorithm that was used by Microsoft Terminal Service Licensing Service?  What was the cryptographic weakness that was exploited by Flame?  Are there any lessons we can learn from this incident?

Update: Microsoft published a report which confirms the guesses in this posting and gives a great level of details.

Certificate Purpose

There are multiple purposes a certificate may be used for. For example it may be used as a proof of identity of a person or webserver. It may be used for code sining or to sign other certificates.

In this case a certificate that was intended to sign license information was able to sign code.

It might be as simple as Microsoft not checking the purpose-flag of customer certificates they signed:

  Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing.

MD5 collision attack

The reference to an old algorithm might indicate a collision attack on the signing process: There was a talk at CCC 2008 called MD5 considered harmful today - Creating a rogue CA Certificate

Website
Slides
Video

In that talk the researches explained how to generate two certificates with the same hash.

The generated a harmless looking certification request and submitted it to a CA. The CA signed it and generated the valid certificate for https-servers.

But this certificate had the same hash as another generated certificate which had the purpose CA-certificate. So the CA signature of the harmless certificate was valid for the dangerous one as well.

The researches exploited a weakness in MD5 to generate collisions. In order for the attack to work, they had to predict the information the CA would write into the certificate.

Lessons learned?

Microsoft already checks that the root of code signing certificates for Windows Update is a Microsoft CA. So certificates signed by other rouge CAs cannot be used.
Don't forget legacy code and services
If there is enough motivation even impractical theoretical weaknesses, will be exploited. (The original title of the talk was "Doing the theoretical possible").

Update

Microsoft has confirmed both issues (one issue alone is sufficient for an exploit):

  The Flame malware used a cryptographic collision attack in combination with the terminal server licensing service certificates to sign code as if it came from Microsoft. However, code-signing without performing a collision is also possible.

Update 2

Microsoft published the details:

The vulnerability of not checking the certificate purpose properly only effects old versions of Windows.
The collision attack was used manipulate the certificate extensions, so that current versions of Windows are fooled as well.

Update 3

The researchers of the original md5 collision attack published that the attackers used a new variant of the known md5 chosen prefix attack, which implies that they have very deep knowledge about cryptography.


How does the Windows 10 picture password work? I have been researching on how Windows 10 built their picture password, but there is not much content online.

Can anyone here help explain how the picture authentication system in windows 10 works?

Identifies certain elements in the users face that appropriately matches the saved hash of the owners system. It removes the need to use passwords which users previously had to recall or write down and improves the user experience of its customers.

Windows doc explains it more. Here is a quick link:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication


How we can PoC our product that needs training data for our machine learning algorithm of the the bank clients? Recently, we have had a challenge with potential future clients which are the bank. Our product requires to gather static data (e.g. address, loans, last 50 transactions, etc) of banks clients. These banks do their PoC in the public cloud, the banks are OK us to work on their data which is not sensitive like clients address but they are not allowing to have data like previous loans as this classified as sensitive. We are stuck at this time and don't know how to convince or offer the right way for banks to provide us the data for the ML algorithm.

This is not just an issue with 3rd parties - banks have strict regulations about what PII they can use in development environments if controls are not up to the same strictness as production environment.
The usual route is anonymisation or pseudo-anonymisation. From https://gdpr.report/news/2017/11/07/data-masking-anonymisation-pseudonymisation/:

With anonymisation, the data is scrubbed for any information that may serve as an identifier of a data subject. Pseudonymisation does not remove all identifying information from the data but merely reduces the linkability of a dataset with the original identity of an individual (e.g., via an encryption scheme).
Both pseudonymisation and anonymization are encouraged in the GDPR and enable its constraints to be met. These techniques should, therefore, be generalised and recurring. Those in possession of personal data should implement one or other of these techniques to minimise risk, and automation can reduce the cost of compliance.

If those are not possible, have you looked at allowing your learning phase to be run within the bank's secure testing/development environment? Worth considering it.


Sniff LAN SSL requests When I log in into Facebook, using Wireshark in the same machine, I can read the request data in plain-text.

That doesn't happen when I'm sniffing my LAN: I can read the SSL packets but they are already encrypted.

The only way to read these packets in a LAN environment is intercepting the POST request before it goes to the router?
Only after that the packet will be encrypted?
Or the packet is encrypted just right before the request leaves the client device machine?

SSL/TLS encryption is done end-to-end, meaning only each end can successfully decrypt the session.  The point of it being that Wireshark, or other network capture/sniffing tools, cannot eavesdrop on the data contained.

In a LAN or corporate environment, SSL interception looks like this:

Client workstations tries to go to https://somesite.
Inspection appliance sees this, and on-the-fly replaces https://somesite's certificate with a corporate certificate.
Each workstation on the network trusts the corporate certificate, so no error is displayed.
The client then encrypts the request with the corporate certificate, allowing the internal appliance to decrypt and inspect the traffic.
If all is well, the inspection appliance will re-encrypt the data using https://somesite's certificate, and then pass it on to the destination, and replies back to the workstation.

In such a way, the endpoints are really https://somesite and the inspection appliance.  Another session happens between the workstation and the inspection appliance which is essentially relayed to its final destination.

Essentially, the inspection appliance in this case is performing what is known as a "man-in-the-middle" attack, except ostensibly with permission to do so.


Letting client encrypt his/her data. How to ensure the client doesn't lose his/her private data? I am designing a web service where the client is allowed to encrypt his own data on client-side software & then send it to our server, so they can be sure their data is private on our side. Then, if client has encrypted values, we transfer some of server functionalities to client-side where the data is known. We are using AES encryption with salts.
I have three questions,

People are forgetful. If client forgets the encryption key, I believe it's our fault not providing them a workaround. their data will be lost. So is it reasonable that client-side software can remember the password? does this introduce new vulnerabilities? (I am thinking about keeping unencrypted backups client-side, but isn't it the same as keeping the password alone client-side)?
When user wants to change the password, his old data should be downloaded to his client-side software, decrypted with old password, and re-encrypted with new password. Is it reasonable? am I missing something in privacy?
Should Salts be kept server-side?

Thanks.

Is it safe to store passwords on the client?

Yes, if done correctly. Depending on the client, they might have access to a secure storage offered by the operating system. Using this storage will allow you to store passwords/keys safely.

Does storing passwords on the client introduce vulnerabilities?

Yes. Knowing a password is always safer than writing something down. Malware on the client PC might be able to read it out, but this is turning into the realm of possibilities.

How should changing the password be implemented?

Downloading the data, decrypting it with the old key and re-encrypting it with the new key is not a good idea. It's not wrong, in the sense that it has some privacy impact, but it's not feasible for large data.

Imagine that your client has to deal with a 2 GB large file. First they would need to download 2 GB, then decrypt 2 GB, then encrypt 2 GB, then upload 2 GB again. And that's just for one file.

A much better approach would be to create two keys: A data encryption key (DEK) and a key encryption key (KEK).

The DEK is chosen randomly through a proper cryptographically secure pseudo-random generator. When implemented correctly, the DEK is impossible to crack. You can either choose one DEK per user, or one DEK per file.

The KEK is derived from the user-supplied password through a modern key-derivation function, such as Argon2d.

As their names imply, the DEK is used to encrypt the actual data. The KEK is used to encrypt the key. Given that the key is rather short (in comparison to the data you might encrypt) with 128 or 256 bit, decryption will be very fast.

When the user wants to change their password, all they have to do is decrypt the DEK with the old KEK, create a new KEK and use it to re-encrypt the DEK. The data never needs to be touched.

How to treat salts?

AES does not require salts. You have no benefit of adding salts. Salts are used to counter pre-calculation of hashes of weak passwords.

Please make sure you understand the reason why certain cryptographic measures exist before attempting to implement them yourself. I personally would suggest contacting a company of security consultants and have them review your cryptographic concept. They will be much better equipped to find flaws and nuances in it, as they will have full access to your concept, rather than limited information on a public site.

What if a user really forgets their password and we don't want to store it?

I would display a warning to the user that appears as follows:

  Encrypting your data can lead to irreversible data loss if your key is lost!

  <Our Company> treats privacy very seriously. For this reason, we do not ever store your key on our servers. This means that if you forget your password, we have no way of recovering your data.

  Please ensure that you use a safe passphrase when encrypting your data, which you will not forget. For more information please click here <link that will lead to some password best practices>


Why is it called WEP? The WEP standard is called "wired equivalent privacy"?

Why does it include "wired"? Does have it have to do with ethernet codes or something else?

Wired Equivalent Privacy (WEP) is a security protocol that is designed to provide a wireless local area network (WLAN) with a level of security and privacy comparable to what is usually expected of a wired LAN.

Source

So as the name states, it's an equivalent of the wired network (LAN). It is supposed to provide the same level of security and privacy, but unfortunately it does not.


Security and privacy issues with Telegram Recently I signed on Telegram using my TextNow
number.

When I signed in, I was assigned the profile of an existing user! I have access to the profile of this user, including the contact list of the user, subscribed channels, and session history with geographical information.

Apparently TextNow reassigns unused numbers to other users, which is quite understandable as there is a limited amount of them. However I am very surprised that a supposedly privacy oriented service allows me to unintentionally access other users' profile  and, even worse, to have access to the phone numbers of in the contact list this user.

I could set an additional password and become the sole owner. On the other hand, if I change the username, I will still be on the contact list of unknown people and Telegram will notify my new username to them.

It is a fact that, when you get a new phone number, you are not necessarily the first owner.
Using an old owned number reduces this possibility, but Telegram would advertise your presence to old coworkers or occasional friends, who are not in your circle any more and you don't want to be.

Is there a sane way to use Telegram without giving up to your privacy and security? (I don't think that Skype has these issues). This accident and the resulting attitude of Telegram toward (two factor) authentication worried me. Considering that one can lost the ownership of a phone number (for a number of reasons), is it sufficient to add a second level of authentication to stay safe?

You can set a password as a second factor; this way, no one else will get an access to your account even if they will somehow obtain your phone number.

What you really see here is good old security/usability tradeoff. Most Telegram users probably never cared that much about the security of their account, and neither did previous owner of your number. Forcing them all to remember passwords would have undermined the growth of a messenger's user base.

At that point, Telegram decided to let the users choose themselves. In future, this may, but seems to be unlikely to, change. Whether a decision making of that sort is appropriate for you is completely up to you to decide.

What I can still suggest is to evaluate your own risks and threats in order to find out if you're fine with a platform that wouldn't enforce the most secure option as a default, or not. Here's an article on how to apply a context-centered approach to messaging platforms, it might help somewhat to understand the challenges of picking a messenger which fits your threat model best.


Create a certificate signing request can someone please tell me a few tools that can be used to create a CSR ?

OpenSSL can do CSR's: OpenSSL: Documents, req(1)


Is signing android apk file with SHA1 digest secure enough? Google command line example for signing apk files:

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name

source: http://developer.android.com/tools/publishing/app-signing.html

As you know, both MD5 and SHA1 are considered seriously flawed (With MD5 badly broken in practice too). So is signing android apk files with SHA1 hash secure enough? If no, Google guys should know about that and I am wondering why they have provided such an example. Can I use another algorithm for signing android apks?

MD5 and SHA-1 have flaws with regards to collisions (in the case of SHA-1, these flaws are "theoretical" in that no actual collision has been produced yet). Collisions are not necessarily a problem, depending on the context.

A collision is a pair of inputs m and m' that are distinct, but hash to the same value. Since signature algorithms operate on hashed messages, a signature on the first message of a collision pair would also be valid for the other message, mechanically. Collisions are distinct from second preimages in the following sense:

in a second preimage, the attacker is shown a message m and is challenged with finding a distinct m' that collides with m;
in a collision, the attacker chooses both m and m'.

Currently, there is no known second preimage attack on SHA-1 and only a very very theoretical second preimage attack on MD5 (effort of more than 2120).

App signing is about accountability. Normally you would not want to install an app that may do bad things; the signature does not guarantee that the app does not do bad things, but it gives the user retaliation power: the signer should not be able to deny having signed the app. This is important to remember: the signature does its job as long as it allows tracing back to the culprit.

An attacker might want to make two versions of his app, the two versions hashing to the same value, and thus using the same signature value. One version would be "honest", and the other would hijack your phone or enact similar naughtiness. But what it would gain to the attacker? If application m and application m' share the same signature value, then the signature "proves" that the author of the application really wrote both... which is entirely true! The security property of the signature, the accountability, is still valid in the presence of collisions.

What the attacker really wants is a second preimage: he wants to make a bad app which is signed by somebody else. For that, he needs to take an existing "honest" app, and make a new one that hashes to the same value, thereby allowing him to borrow the signature value. Right now, nobody knows how to do that with a RSA/SHA-1 signature (or, for that matter, with a RSA/MD5 signature).

Collisions can be a problem when the attacker gets to choose what will be signed by somebody else. This is what happened with a demonstration involving RSA/MD5 and certificates. This, however, does not apply to your context, when what you sign is your own app. Collisions on MD5 or SHA-1 would be relevant if we imagined a situation that would go thus:

Attacker makes a pair of apps, an honest one, and a malicious one, that hash to the same value.
Attacker submits the first app to someone who can sign app.
The signer inspects the app code thoroughly, sees that everything looks fine in it, and signs it.
The attacker then reuses the signature value on his malicious app.

Even in that case, while the signature would point at the signer, that signer would know, in case of trouble, that the malicious app is not what he signed. In fact, he would simply exhume the "honest app" from his emails, show that both the honest and malicious app are a colliding pair for the hash function, thereby demonstrating the malicious intent of the app author (you don't get collisions out of bad luck; you have to do it on purpose).

Summary: known flaws of MD5 and SHA-1 with regards to collisions do not endanger the security model of app signing. It still is a nice idea to investigate usage of more modern and robust functions such as SHA-256, but there is no urgency.


vulnerability scanner report to SIEM Our partners require such configuration as

1) vulnerability scanner A (well known in CIS area)

2) SIEM B (leaders of the market)

And they should perform a scan of the network, get a report then forward it to the SIEM supposedly to challenge the findings against IOC's.

They insist to get the report into the SIEM -- we don't want to argue with them.

Does challenging the report against IOC's via SIEM sound right to you?

Feeding vulnerability reports into a SIEM is normal practice.

As for comparing data found by scans against IoCs, that too is normal practice. Where that is done (in a SIEM or not) really doesn't matter.


Authorization before Authentication? From a conceptual point of view, can authorization occurs without authentication taking place first?
I'm thinking about few cases where authorization seems to occur without authentication taking place first:

A web application denying access to a protected page to an unauthenticated user;
A firewall denying access to host

Authentication is about proving the identity of a requester. "Identity" can be a specific property or requirement, e.g. "being a US citizen" or "being 21+ years old" (to take some examples from @David's answer).

Authorization is about deciding what a specific identity should be allowed to do. For instance, an authorization rule can state that "whoever is 21+ years old can buy beer".

In general you will need both to be granted access. In the beer example, the bartender needs to make sure that the putative customer really is 21+ years old, and he must also, at some point, get the information that beer can legally be sold to customers who are 21+ years old. The order in which he does both operations is not relevant, as long as they are both fulfilled. In fact, the beer-selling example is a prime example of authorization occurring before authentication: the bartender learns about the authorization rule ("21+ -> OK") way before he meets the customer.

In many computer systems, we prefer to do authentication first, for the following reasons:

Getting authorization rules for the request at hand may be expensive. We do not want to do that for any as-yet-unauthenticated requester, because it could become a Denial-Of-Service.
Sysadmins are usually nervous about making their authorization rules known by and large. Gathering authorization information before authentication can leak such information to just anybody.


Removing malware from a malicious PDF file I have analyzed a large PDF using Didier Steven's pdfid tool. I get the following result:

Now that I know there is malicious content in the PDF, what can I do to remove it? I would still like to view the contents of the PDF. Unfortunately, I am not confident in my ability to remove all the malicious content with technical tools like pdf parsers. I am looking for another method where my lack of experience will not be a big liability.

Here are some of my ideas:

Upload the document to Google Docs. I assume that Google has one of the most secure PDF viewers out there.
Open the PDF in a virtual environment and somehow save the PDF page-by-page. At the very worst, I could write a script to print screen each page and make a new PDF full of images.
Use Firefox's pdf.js or some other browser-based viewer

Another question I have: How reliable is the pdfid tool? For example, if I get a result with no Javascript, OpenAction, etc. can I be sure that it is safe?

Since there's absolutely no way to tell what's inside that file and what it's capable of, I'd recommend cutting your losses and nuking it from the get-go. With most PDFs (and, infact, any file really) you can recover relatively quickly as the PDF is bound to reside somewhere else (either an earlier draft or an un-modified version).
That being said, you seem very keen to open this PDF so I'm assuming it has some sort of uniqueness to it. You'll need to forgive me for putting my day-job hat on but usually this means a user hasn't saved or backed up their documents when they should have. If that's not the case, and this is truly the Dead Sea Scrolls of the PDF world, let's see how we can open/clean these files without damaging them or, indeed, yourself.
Using a browser to recover the PDF
You've brought up opening them in a browser several times:

"Upload the document to Google Docs. I assume that Google has one of the most secure PDF viewers out there."

and

"Use Firefox's pdf.js or some other browser-based viewer"

As I said at the beginning, we've no idea what we're dealing with at the moment. Opening it a browser (at this stage) wouldn't be recommended. Also uploading it to Google is a little bit unethical since you know full well that there's something suspicious going on with the PDF.
Even if you were somehow able to know exactly what that PDF file's malicious content is capable of, there's no way to ensure it hasn't been tampered with to masquerade.
Using a VM/isolated machine to recover the PDF
You touched on it in the middle of your question, using a VM or isolated machine is obviously a far safer way of opening that PDF.
Now you might be thinking that's a lot of time to spend setting one of those up but if you keep a snapshot of clean, portable, small systems taken immediately after the installation has completed, we can almost safely open the PDF, print the contents to file (as @KnightOfNi has already alluded to) without the PDF editing capabilities. Why not go one step further and actually print them on a closed loop with a USB printer and rescan them? Might seem like a massive hassle but we're dealing with a time-bomb of unknown magnitude. It could destroy your system, steal your data, crypto-locker your stuff, or simply be a lemon - the point is we have no idea.
"Can I be sure that it is safe?"
From your question:

Another question I have: How reliable is the pdfid tool? For example, if I get a result with no Javascript, OpenAction, etc. can I be sure that it is safe?

Again, not really - but there are ways you can test to see how accurate the tool is.

If it's Open Source, have a dig through the code and make sure it's not just spitting out any old garbage and barely touching the files.
In that VM/isolated machine lab, why not throw it some good/bad/ugly files that are known to be infected with a certain strain of malware? You can roll your own or you can reach out to the researcher community who usually have a few examples to download online.

To be honest, it all depends on how much you want to recover that PDF. For most people- it's way more hassle than it's worth... but then again, that depends on the contents.

What I'd do:

Isolated virtual machine on an isolated physical machine (sounds like overkill but that's how I tested my first experience with CryptoLocker - glad I did it that way).
That means no file sharing (i.e. share desktop -> desktop on VM)
Go for an odd OS. The odder the better. Most of these PDF viruses are targeting specific users of specific versions of an operating system. I doubt they've thought about Kali, TAILS, or similar
Deactivate plugins/delete any known areas or apps of concern (flash, etc.)
Open a test PDF and set all the security settings to max before opening the target document
Open the target document, physically print it, scan it back in.


Why isn't WPA2 more secure? Follow-up from this question. I just learned that all one needs to decrypt WPA2 traffic is the network key. So for example if I go to a coffee shop and they have the key on the wall I can listen to everything, and if people are visiting sites over HTTP I can MITM them. My question is: why??? Why can't the router and client exchange a secret using public key crypto and encrypt their connection so that other people on the network can't listen? And then each packet or whatever could have a MAC so MITM would be impossible.

From my knowledge WPA2 does this (encrypting the connection between client and router with a key different for each device)

WPA2 uses the authentification handshake to generate multiple keys. 2 of these are:

Temporal Key (TK) – Used to encrypt/decrypt Unicast data packets
Group Temporal Encryption Key

The first one is used to encrypt unicast connections like communication between client and router. The second one is used to encrypt multicast/broadcast messages.

In the case of the mitm attack the attacker persuades the victim to think he needs to send specific/all packets to his address. So the client encrypts the packets with a key the attacker is able to decrypt because the client thinks the attacker is the one he wants to talk to.

Think of it this way: all letterboxes in a city (wifi-network) can only be opened (decrypted) by the correct owner. You want to send secret data to your friend Joe who lives at Goodstreet 1. But you don't know that. So you ask the people of the city where he lives. Alice (also living in the city) convinces you that your friend lives at Badstreet 1. So you put your letter in the letterbox of Badstreet 1, Alice reads it/alters it and forwards it to Goodstreet 1. So even when the letterboxes are secure Alice managed a mitm-attack.

Edit: Professional routers/network equipment have countermessaures against things like ARP-poisoning to try prevent MITM-attacks.

Saying "So what's the point of encryption then? MITM renders it useless!" is not different than saying that a burglar alarm is useless in a public building or theft by a friend you invited to your house.


Is Google Chrome a more secure browser? I was amazed that IE 8, Safari, Firefox were hacked so fast at Pwn2Own 2010. Is Chrome really so good or was it not tested?

Has anyone other results of independent investigations about security of web browsers?
Is these a list of "problems" or weaknesses by browser types?

Many bugs/vulnerabilities have been found in Chrome, but, as user Arda Xi has said - Chrome's security heavily relies on sandboxing. So, that's why there are no live known exploits - it is nearly impossible to exploit those vulnerabilities. You can read more about Google Chrome's sandboxing here:

http://blog.azimuthsecurity.com/2010/05/chrome-sandbox-part-1-of-3-overview.html.


Are there different degrees of "confidentiality"? What is the best way for a psychologist to maintain confidentiality of communications with patients? A non-tech savvy friend of mine is a psychologist. She has many patients who constantly invite her to communicate through all sorts of mediums such as text, email, voicemail, and other mediums. But she is concerned she is not knowledgeable enough about information security and would like to learn more.

As a doctor (a practicing clinical psychologist), she has two primary goals:

To be able to preserve the confidentiality of communications with her patients.
To make intelligent choices about how she communicates so that, if information must remain off the record, she knows how to communicate in a way that remains off the record.

Given the problems with information security these days, she doesn't know what the best way is to achieve these goals, so I suggested bringing the question to Information Security SE.

Obviously, my friend isn't likely to want to read lots and lots about information security. She also is looking for information tailored to those two particular goals, which are probably common for all psychologists.

My Question:

What is the best way to achieve the two goals stated above?

I would like to disagree with the idea that email could be safe enough for confidential information exchange of any kind particularly between a psychologist and her patients.

An often quoted rule is that you should always treat any unencrypted e-mailed communication to be about as confidential as if you wrote it on the back of a postcard. In reality it's a bit worse than that since it's a fair amount of work to index, search and filter messages on post cards (especially since you need to make copies first) while it's trivial to do the same thing for email.

At the very least you have breaches of confidentiality at both the psychologists mail provider and the patients mail provider. To make matters worse the patients mail provider might be his employer who might actually have interest in the information being exchanged, and worse still if their internal policies are set up in ways many are, might have a legal right to inspect that email.

I would also like to disagree with the idea that "There is no incentive for an attacker to read someone's life story", quite the opposite. As an example consider a politician who might say be going to counselling for alcohol abuse. I'm sure an opposition politician would find information about that to be worth a lot of money. The same might be said for many other cases, be it employees with symptoms of work related diseases developing or parents in a divorce fight.

Last but not least (disclaimer: I'm not a legal expert and my knowledge of HIPAA is cursory) I think there is a very good chance that HIPAA does apply and very probably regulates which things can be communicated to a patient through email if any.

All in all I think it would be advisable not to use unencrypted email communication for anything short of setting up appointments and even for that I would be extremely wary. On the off chance your friend would consider setting up certificates for herself and her clients and using encrypted email she should bear in mind that subject lines of emails are never encrypted.

EDIT I realize this isn't really an answer to the question I just wanted to make sure disagreement with email was voiced. I will write up a more comprehensive answer later when I have more time.

EDIT2 So having spent a lot of words destroying an idea let's try and be constructive. If you can't use email (unencrypted) what can you use?

Well the "easiest" solution would be encrypted email. Assuming you make sure to not put any sensitive information in the subject fields this is a very secure solution when set up right.

The usual problem with using encrypted email is that both parties need to have certificates, and need to have correctly set up trust chains. This is usually a fair amount harder then would seem especially when the certificates aren't managed centrally. Encrypted emails work pretty well within an organization where everyone gets issued certificates on a regular basis preferably by internal IT and where that same IT ensures their email, computer and what have you is set up correctly. Sadly lacking that most people tend to struggle with certificate management and use. Still assuming the people are able to deal with these obstacles using encrypted email used properly and consistently is really quite safe.

Another alternative I would consider is setting up a normal webserver which only allows connection using HTTPS reasonably hardened, and on that server set up a very simple messaging system. Each client gets to choose a user name and a password first time they come. This password is then used to log them into the system over HTTPS. The website then does very little other then save and display messages sent between the client and the psychologist. Now this can be implemented very well but will probably be overkill for a single doctor. Done well it could easily serve many though.

To round it off with something that is certainly not perfectly secure but might solve your problems with a reasonable degree of security, a lot better then mail anyway. If your friend only needs to send confidential information quite rarely one very easy and free way to do that is using encrypted zip archives. All up to date zip programs (winzip, 7-zip,gzip even) are capable of state of the art symmetric encryption with key derived from a password. You are left with the problem of distributing the keys ofcourse, but that can be handled either using predetermined keys (a bit kludgy) or by sending the keys for example using SMS (not very secure). While using SMS to send the keys is certainly not particularly secure it does split the data and the key over two different channels at least and if you want to get to the message you have to do a decent amount of work. It still isn't safe against the feds,NSA, local police or probably even a really dedicated private investigator, it's still miles beyond just sending the message using email only.

Personally if I were your friend I would look into seeing if they can't possibly join up with some already set up secure messaging solution possibly used by other doctors in the area or maybe even available through a health care insurer they might have a contract with.

Last but Most important whatever solution they choose to go with I would strongly advise to consult with someone who has extensive knowledge of the HIPAA regulations. Haven't looked up a few things online the penalties for non compliance can be extremely painful this article http://www.aaos.org/news/aaosnow/aug12/managing5.asp talks about $50'000 fine.


Boundaries of Personally Identifiable Information - PCI-DSS I am attempting to ascertain the boundaries of personally identifiable information.

For example does the combination of John and Doe equate to personally identifiable information since there could be several thousand John Does?

My understanding of Personally Identifiable Information (PII) is when an individual (not deceased) can be sufficiently identified. So if I had the name John Doe plus a social security number or email address, it would be deemed as Personally Identifiable Information.

In the context of PCI-DSS, are there specific requirements in the storage, transmission, destruction, utilization of such data?

I am attempting to ascertain the boundaries of personally identifiable
  information.

That is a legal question, and varies by jurisdiction.  Perhaps the best known is California:

  (a) The term “personally identifiable information” means individually
  identifiable information about an individual consumer collected online
  by the operator from that individual and maintained by the operator in
  an accessible form, including any of the following:

  (1) A first and last name.

  (2) A home or other physical address, including street name
  and name of a city or town.

  (3) An e-mail address.

  (4) A telephone
  number.

  (5) A social security number.

  (6) Any other identifier that
  permits the physical or online contacting of a specific individual.

  (7) Information concerning a user that the Web site or online service
  collects online from the user and maintains in personally identifiable
  form in combination with an identifier described in this subdivision.

Later case law has added zip code to the list.

  In the context of PCI-DSS, are there specific requirements in the
  storage, transmission, destruction, utilization of such data?

The only overlap between PCI-DSS and PII is the cardholder name.  The PCI DSS does not concern itself with PII; it concerns itself with "Account Data", which consists of the following elements:

Certain PII elements that may be included in credit card processing, such as billing address and zip code (you may have had to enter your billing zip at a gas station?) are not even mentioned by the PCI DSS.  And even for the one clear overlap, the cardholder name, it's fair to say that one's management of the data may be fully PCI compliant but egregiously lacking compliance with applicable PII regulations.  You should not consider PCI controls when determining if you are protecting PII correctly.

Following up to comment:

  Are there defined controls in protecting PII that also overlap with
  PCI-DSS controls?

The problem is that PII laws are punitive rather than prescriptive.  They define what PII is and state who is responsible for handling it correctly.  They don't define how to handle it correctly; they indicate what sorts of results a correct handler provides and state that failing to provide those results indicates a violation of the law.

The PCI-DSS, on the other hand, is much more prescriptive.  It goes into some detail as to the protections expected.  It doesn't say what encryption you need to use, but it says you need to use encryption for this and that and correct encryption has to meet reasonable standards.

Could PCI-DSS controls be used to apply to PII data?  Sure... you could treat PII as if it was PAN (Primary Account Number) data; make sure it's encrypted whenever stored, etc. etc.  However, you'll probably have more trouble because the use cases for PII are different than for PAN; with PAN, you pretty much need to send it to the processor and that's about it.  With PII, you may have lots of employees needing to reach in and look at it for one reason or another (customer support? snail mail campaigns? data analytics?) and those people will either be inconvenienced by the encryption, or the protection around the encryption will be weakened by the increased number and variety of access.

There are many criticisms of the PCI-DSS, but perhaps its best defense is, "It's better than nothing."  It's a standard, it's imposed by the card brands, and it lays down an acceptable minimum of security controls.  There's no equivalent document for PII - all the more so because PII is so jurisdiction-dependent.


What value security wise, if any, does a digital handwritten signature have? Here's an example of what I mean:

(It's basically the same thing as a traditional signature.)
Given I've never seen someone fail this control, it's unclear to me what real security such a system would provide. Am I missing something?

A signature is gold standard for authenticating paperwork.   Really I see this is an evolutionary artifact of progress technology.  For so many years we didn't have anything better,  and so it has been "grandfathered in".

I have heard of credit card companies performing automated analysis on the transaction and signature to see if it is a fraudulent purchase, but this is a very difficult problem to automate.

Personally I think signatures are nearly useless.  Perhaps they are most useful as evidence to be used in court.   If you clone a credit card,  the only evidence of the transaction is a grainy security camera,  and a signature of the transaction.


Encrypting data and SSO I provide a service in which users can store data, files, etc in an encrypted form.
The service that I have built has two applications for the user's password with which they login to my service: 1) authentication and 2) the password is used as the base for the secret encryption key for data they store with my service.

I am integrating with another service whose users need to be able to access my service via SSO, either OAuth2, SAML or some other standard. The obvious problem is that the user's password is eliminated and thus cannot be used as a secret key.

A few questions:

Can the user's password from the parent service be passed to my application allowing for it to be used as the secret key for encryption?

If a secret is randomly generated when the user registers for my service via SSO, can this be stored anywhere securely?

Currently my service employs AES-256 symmetrical encryption. Is there a better encryption scheme for my use case?

Any ideas for a string other than the user's password that could be used as a secret key?

Can the user's password from the parent service be passed to my application allowing for it to be used as the secret key for encryption?

No.  That is sort of the point of the protocol.

  If a secret is randomly generated when the user registers for my service via SSO, can this be stored anywhere securely?

Secure from whom?  I'm guessing that your system was designed so that even you couldn't decrypt someone's private files.  If that is the case, then no, there is nowhere you can store it where you can't also get it, unless you pass it to the end user and ask them to store it.

  Currently my service employs AES-256 symmetrical encryption. Is there a better encryption scheme for my use case?

Even AES128 is plenty strong.  Without knowing more about your system, it's hard for me to say whether it would benefit from some aspect that uses a public/private key.

  Any ideas for a string other than the user's password that could be used as a secret key?

If it were me I wouldn't want you to use my password (which is pretty short).  I would want to be able to type an arbitrarily long passphrase into a large, multi-line textbox.  I would probably paste in a couple pages from a book I like, which makes it easy for me to recover.

You could also randomly generate a value and save it as a cookie or file for the end user to keep.


How does Amazon Fire TV know my name/account? I bought a Fire TV stick and inserted it into the HDMI-port of my TV. I was presented with a dialog to select my wireless router so it can connect online.

Just after I did that, it asked me if I am who I am.

So they were able to deduce my account just from my Wifi?

I didn't go to amazon from my "IP of the day" that day before.

How did they match my identity from my wireless network. Did my laptop communicate the ESSID to Amazon before?

The Amazon Fire TV is pre-configured with your account:

  Pre-registered to your Amazon account so you can enjoy favourite titles and personalised recommendations

They configure this with your details taken from the account you used to order the device.


Can the Internet Achive capture anything malicious? I have been using the site Internet Achive when I was researching a domain name and found an older version of the domain I was investigating turned out to be a NSFW web site it seemed like it was going to show a pop up because my browser blocked and warned me about it.

This had me wondering can the Internet Archive pick up anything malicious while it was archiving a site say for example:

A site was attacked by an XSS someone archived the site while the attack was active assuming the Internet Archive captured the code can viewing that archive trigger the attack or what about an archived site that had a drive by attack enabled?

The Internet Archive stores whatever was on that site at the time it crawled it so yes, there could be malicious code there. I understand they make some checks, but you should always assume that it is as malicious as a current site, although likely with older malware :-)


Evading IDS in exploit development In the context of buffer overflow exploit development, I was asked:

Discuss how your exploit may be modified to evade an Intrusion Detection System.

I'm not asking for my homework to be done, but after using my best Google-Fu, the only answer I can find is to use encoders (like shikata_ga_nai).

Are there other methods in exploit development for evading IDS?

Given the context, it seems unlikely that this is the only thing I should discuss, but as I said, after spending the evening on it I can't find anything else.

While the other answer focuses on modifying the exploit itself, you can also modify the transport of the exploit, so that the IDS will not detect it (Disclaimer: some of this points to my own research).

Some examples on how to do this on the application layer with HTTP (i.e. for drive-by-downloads while browsing the web etc):

Use a valid but less common HTTP compression method, which is supported by the browsers but often not by the IDS. Often a simple Content-Encoding: deflate is enough, like with ZScaler or Comodo Webinspector or Sophos UTM (fixed).
Combine HTTP compression, e.g. use a Content-Encoding of deflate, deflate or gzip, deflate. IDS like Bro, Snort, Suricata or even VirusTotal only look at the first or last compression scheme, while browsers like Firefox or Google Chrome accept content which is compressed multiple times.

Similar evasions can be done by playing with content-transfer-encoding when sending the malware by e-mail.

And then there is a nice research about evading IDS at the transport layer. There is a paper about Evading Deep Inspection for Fun and Shell and also a video from Blackhat 13.

And of course you can also modify the exploit itself. Here is a nice description of how to modify existing exploits so that common AV will not detect them any longer.

Other evasion techniques use social methods to evade IDS, like putting the exploit into an encrypted ZIP file, attach it too a mail and write the password into the mail too. If done well the victim will be seduced to open the file with the supplied password just to get the content (like the alleged salary lists of his company or similar traps). Because the password is not known to the IDS it can not detect the malware.


Why is SHA-3 (keccak) considered more secure than DES when you can attempt to crack it 3x faster? Hash.Type....: descrypt, DES(Unix), Traditional DES
Speed.GPU.#1.: 6215.8k/s

Hash.Type....: SHA-3(Keccak)
Speed.GPU.#1.: 20514.1k/s

see: http://hashcat.net/forum/archive/index.php?thread-2085.html

It looks like you can make attempts crack SHA-3 (keccak) 3 times faster than DES.
While Keccak is known as a very strong crypto and DES a very weak crypto.

How do you explain this?

SHA-3 is a hashing algorithm. DES is an encryption algorithm. The two are not comparable. They do different things and do them in different ways.

It's a bit like asking why your blender is faster than your bicycle.


Should I be afraid of biometric IDs? The Israeli Minister of the Interior is pushing legislation to introduce biometric IDs.  On the one hand I hear his argument that it can help to prevent identity theft.  On the other hand, something makes me very nervous about having my biometric "password" in the hands of any government.  And I worry what will happen if a hacker somehow steals that "password", because I can't change my DNA and get a new password.

My discomfort is largely emotional, though, because I don't fully understand the real risks of biometric IDs.

Can anyone please explain clearly what the risks are, if any, with biometric systems?

A few thoughts about that:

Biometric data is easy to access and should not be used as a password, only as additional authentication.
As Freedom explained quite well your government already tracks you.
Biometric data like fingerprints are mostly not stored as raw images but in form of hashes. An algorithm extracts certain characteristics. You cannot restore your fingerprint from this data.  Still, it might be possible to trick some authentications with this data.
Biometric data could be misused. DNA markers could contain information about medical issues or ancestry. Currently forensic teams are trying to reconstruct how a person looks from their DNA.
Data that is not needed should not be stored. Especially not centralized.

I am against this because: Freedom before Fear.

Update because of comments

With "Freedom before Fear" I tried to translate the German "Freiheit statt Angst" slogan. We tend to give up freedom because we fear terrorism and crime. The Freedom is in this case the control over your private data. Data you can not change. Data that defines who you are. This data might stop someone from copy a passport or it might not. In anyway it does not stop terrorism but it does create the risk that the data is miss used.

A database of DNA where you could look up all foreigners. What could a dictator do with this? A database that tells an insurance that you could get a sickness. Who knows what will be possible with this data in the future?

If you create such a database there is always a chance it will be used for evil. How and in what way is impossible to tell but it would not be good for you.


Send a form with sensitive information via SMS attachment A prospective business associate wants me to send an image of an application with some of my important self-identifying information via SMS as an attachment, e.g. image or PDF of the form. This doesn't sound secure to me. I have no reason to believe that the recipient, nor I, has a particular issue with being the subject of a hacker, but in general, this doesn't sound like a good practice. Should I look for an alternate method to send this form?

When the channel is seen as untrusted, a common way is to encrypt the information and send the password over a different channel.

Some examples actually used:

send the encrypted information by mail or via a web site, and the password on a physical paper send via postal mail
send the encrypted information by mail, and give the password by phone - this assumes that the phone is not a smartphone than can be used to read the mail...


What is my recourse if someone made a gmail account with my name? Much of my personal information is available online. That is not a particular issue for me, but someone used my name to make a gmail account with my specific name on it (it is an unusual name), and ordered some game codes from ebay using my email address, which was somehow linked to my credit card. Visa, Ebay and paypal refunded me, but the gmail account still remains, with my home address attached to it. Google says they can do nothing to shut this down unless I file a court order. Is there anything I can do short of this? I see that there is a similar question here but it is asking something different.

Your issue is not that someone made a free email account with your name. There are hundreds of "John Smith"s, "Jay Kim"s, and "Maria Garcia"s with that issue, and they manage to live just fine.

Your issue is "which was somehow linked to my credit card". Focus on finding out how that happened, and fixing it and then let the email account worries be a distant second worry compared to that.

It is very unlikely that you will succeed in getting the account disabled unless you can prove some fraud activities are taking place.


Documentation for risk assessment in ISO 27001 structure We are currently implementing the ISO27001, I have a question regarding the documentation of the risk assessement.

We choose EBIOS to be our risk assessement method, and I found some templates of the mandatory documents in the ISO 27001 context and in the EBIOS context, they are very different from each other.

My question is: do I need to produce two types of documents even though they have the same content, or the EBIOS documents are sufficient in this situation?

To fulfil this aspect of chapter 6 in the norm you need to document that you have an objective way to assess risk and which method you choose to do so. The results from the risk assessment should be reproducible (i.e. if I do a risk assessment and you do a risk assessment of the same process, we need to end up with the same risk 'scores').

Which method you use and how you document it, an auditor will not care. As long as you achieve what I described above and you can explain why that specific method is adequate for your organization.


Exchange of public keys with DHE-RSA The paper "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" by Adrian et al claims that the NSA might be able to eavesdrop on a large percentage of TLS connections, because they managed to crack certain Diffie-Hellman groups.
Now, I assume a situation where a client is connected to a server via DHE-RSA. What I don't understand is why, in this situation, cracking Diffie-Hellman alone would be enough to eavesdrop. Wouldn't it be necessary for the NSA to also get ahold of the private RSA key of the server? Put in different words: When the client sends his DH public key to the server, doesn't he encrypt his DH public key with the RSA public key of the server? (If not, why not?)

In case of DHE-RSA the RSA part is only used for authentication that the client speaks with the proper server. While it might be used to detect modifications of the key exchange it will not detect passive analysis of the key exchange, i.e. protect against attacks which only require to sniff but not to modify the data. An attacker who has managed to crack the specific DH group used by the key exchange (or has a planted a cryptopgrahic backdoor in it) does not need to actively fiddle with the connection but only needs to passively sniff on the connection in order in order to get to the exchanged key and decrypt the traffic.

It is known that the Five Eyes (i.e. NSA, GCHQ,...) but also other government services in various countries have access to a large part of the internets core systems and can thus passively listen to these data. Combined with weak or backdoored cryptography this makes it possible to sniff and decrypt the traffic without changing the traffic and in a way that sender and recipient will not notice it.

To address the question in the comment on why RSA is not used to protect the key exchange: one might argue that the knowledge of the servers RSA public key by the client would make it possible to encrypt the part of the key exchange which is send from client to server since the server might decrypt this part using its private key. While this would be possible with RSA it would mean that the DH key exchange is too much bound to the use of RSA and no longer a more or less independent mechanism. For example it would require the client to know the servers public key first. While is possible with TLS 1.0...TLS 1.2 where the DH key exchange is only done after the certificate of the server is known this is no longer the case with TLS 1.3 where the DH key exchange starts before the certificate is known. Also, more modern authentications mechanism based on ECC (i.e. ECDSA) are designed for signature only but not encryption which would mean that they could not be used to protect the DH key exchange anyway.