The valid role of obscurity That security through obscurity is A Bad Thing is received wisdom and dogma in information security. Telling people why something is to be avoided can be considerably more difficult when there is no line delineating what you are trying to ban from apparently effective strategies.

For example - running ssh on a non-default port and port knocking are both suggested as ways of improving ssh security and both are criticised as being ineffective security through obscurity.

In this particular case both solutions reduce the visibility of the system to automated attempts. This does nothing to improve the effectiveness of ssh as a tool or reduce the need for other ssh security measures. It does provide a way of separating serious attempts from automated passers by though, which improves the manageability of the system.

Besides manageability/effectiveness what distinctions describe the boundary between valid/invalid uses of obscurity?
What analogies describe effective use of obscurity or draw the distinction between this and ineffective use?
Which analogies apparently supporting the effectiveness of obscurity don't hold up and why?
What other specific implementations are examples of the valid role of obscurity?

Interesting question.  My thoughts on this are that obscuring information is helpful to security in many cases as it can force an attacker to generate more "noise" which can be detected.

Where obscurity is a "bad thing" can be where the defender is relying on that obscurity as a critical control, and without that obscurity, the control fails.

So in addition to the one you gave above, an effective use of obscurity could be removing software name and version information from Internet facing services.  The advantages of this are:

If an attacker wants to find out if a vulnerable version of the service is in use they will have to make multiple queries (eg. looking for default files, or perhaps testing timing responses to some queries).  This traffic is more likely to show up in IDS logs than a single request which returned the version.  Additionally fingerprinting protocols aren't well developed for all services, so it could actually slow the attacker down considerably
The other benefit is that the version number will not be indexed by services like Shodan.  This can be relevant where an automated attack is carried out for all instances of a particular version of a service (eg. where a 0-day has been discovered for that version).  Hiding this from the banner, may actually prevent a given instance of the service from falling prey to that attack.

That said, it shouldn't ever be the only line of defense.  In the above example, the service should still be hardened and patched to help maintain its security.

Where I think that obscurity fails is where it's relied on.  Things like hard-coded passwords that aren't changed, obfuscating secrets with "home grown encryption", or basing a risk decision on whether to patch a service on the idea that no-one will attack it.  So the kind of idea that no one will find/know/attack this generally fails, possibly because the defenders are limiting their concept of who a valid attacker might be.  It's all very well saying that an unmotivated external attacker may not take the time to unravel an obscure control, but if the attacker turns out to be a disgruntled ex-employee, that hard-coded password could cause some serious problems.


Should I present forged documents in a Penetration Test/Red team engagement? A previous question of mine lead to this discussion which mentioned the subject of Document forgery.

I've seen many people (in videos) forge IDs and employee badges for such engagements so that seems fine as a test. However, if asked to present a more critical/serious document like a "Permission to Attack" slip (when caught), or asked by a police officer to present some ID, should we test them by first show them a forged "Permission to Attack" slip or ID and only show the real documents if caught?

It depends on the scope of the engagement.

If the customer wants you to focus on one specific task (e.g. bypassing locks, social engineering, etc.), then that's all you're authorized to do and all you are legally allowed to do.

If the customer wants you to use "anything that's legal", in order to best simulate a real attacker, them you can indeed present a forged permission to attack, possibly even with instructions added that you should be left alone during the engagement.

Why would you do that? In order to check if security personnel actually verifies of a Permission to Attack is valid or not. Otherwise an attacker could present a forged Permission to Attack and use this to gain entry to the company?

What about law enforcement?

Never show law enforcement a forged document or lie to them about who you are or what you are doing. You are testing the company, not the law enforcement.

Or to put it in simple terms: When you talk to the police, you're no longer a pentester.


How secure is AES-256-CBC with user provided password and initialization vector From my understanding the IV is used as a previous block for the first block only.
But since each block is used by the following this adds significant security is a IV is provided and not based on the password.

Thus I implemented a login system when the user provides both, distinct with a minimum of 8 characters using any characters they care as long they use at least 3 types (upper, lower, numeric, special, non ASCII).

But now someone told me that by defining the IV I weaken the encryption as that would make the password sort-of useless.

I did not exactly understand his explanation.

My code looks like this:

$hash = openssl_encrypt($username, 'aes-256-cbc', $password, false, md5($iv, true));

Yes I am encrypting the username
Both the password and IV are user defined
Yes I am asking them for two passwords
I'm wrapping the IV in RAW md5 to ensure I get a standard 16 chr length

Can someone clarify if the IV use in this manner is a good practice and is this idea is strong enough.

My suspicion is: you're doing it wrong™.

This is why I think so, from the top of my head:

The variable holding the ciphertext is called hash.
You are encrypting the user name.
This looks like an XY-Problem.
You do not (show how you) derive the key from the password (the openssl_encrypt password is the key, according to the docs. So unless you are deriving a key from the user supplied password, that's not going to work out.)
You are not using a CSPRNG to get an IV for AES-CBC.

  But now someone told me that by defining the IV I weaken the encryption as that would make the password sort-of useless.

That someone was right. See the linked question on crypto about using a CSPRNG with AES-CBC to learn more.


What is the role of ARP poisoning when doing a DHCP spoofing attack My Current Background on the topic

DHCP Spoofing is done by a rogue DHCP server on the network which replies to DHCP requests from hosts(Attacker can run a DHCP starvation attack on the legitimate DHCP server to stop it from handing away IP addresses).
The rogue server can spoof the gateway & DNS servers therefor all DNS & Traffic going away from local subnet will start to flow to the attacker. The attacker then forward the received traffic accordingly so the hosts won’t notice any disruption in connectivity and effectively pulling off a MITM attack.

In ARP Poisoning, attacker send spoofed arp messages to the network and arp cache of the switch will have wrong information so the switch starts to send traffic to the attacker (which should originally go to another host or default gateway)

DHCPDISCOVER, DHCPOFFER, DHCPREQUEST & DHCPACK are broadcast messages so typically all hosts in the local subnet will receive all this messages anyway. Even if the attacker has already done some ARP poisoning on the local subnet it won’t affect the process of DHCP.

ARP is used for resolving Internet layer addresses into link layer addresses.Since ahost does not have an IP address until DHCP process is completed ARP attacks seems useless on DHCP

My Question
As per my understanding These two attacks are two different ways that can be used to achieve same results. But I need to clarify this without any doubt.

Is there any way you can pull off a DHCP Spoofing attack by using ARP poisoning?

I just happen to be writing a series of articles covering such network attacks from a practical point-of-view. Here is the article on DHCP, ARP will follow.

DHCP and ARP are indeed two different attacks allowing the attacker to achieve a MITM within a subnet.

  DHCP Spoofing is done by a rogue DHCP server on the network which
  replies to DHCP requests from hosts(Attacker can run a DHCP starvation
  attack on the legitimate DHCP server to stop it from handing away IP
  addresses). The rogue server can spoof the gateway & DNS servers
  therefor all DNS & Traffic going away from local subnet will start to
  flow to the attacker. The attacker then forward the received traffic
  accordingly so the hosts won’t notice any disruption in connectivity
  and effectively pulling off a MITM attack.

This is right.

  In ARP Poisoning, attacker send spoofed arp messages to the network
  and arp cache of the switch will have wrong information so the switch
  starts to send traffic to the attacker (which should originally go to
  another host or default gateway)

The classical ARP attack doesn't target the switches but end-devices.

Each devices given an IP, need to obtain the corresponding MAC address to establish a communication. This is what the ARP is for.

The attack consists in forcing a device into resolving an IP as the attacker's MAC address instead of the legitimate one.

Nevertheless, there is also a less common attack targeting the switch, making it believe that a certain MAC address can be reached through the attacker's port instead of the legitimate one.
This attack is less convenient and reserved for situations where the previous one doesn't work (MAC address hardcoded in devices configuration for instance).

  DHCPDISCOVER, DHCPOFFER, DHCPREQUEST & DHCPACK are broadcast messages

DHCPDISCOVER and DHCPREQUEST are indeed broadcasted, the two other usually aren't.

  so typically all hosts in the local subnet will receive all this
  messages anyway. Even if the attacker has already done some ARP
  poisoning on the local subnet it won’t affect the process of DHCP.

It depends the degree of chaos the attacker has already spread in the network ;) , but fundamentally you're right: ARP is not related to DHCP here.

  ARP is used for resolving Internet layer addresses into link layer
  addresses.Since ahost does not have an IP address until DHCP process
  is completed ARP attacks seems useless on DHCP

I think of two cases where ARP-based attacks may be a good complement to DHCP-based attacks:

DHCP client messages are usually only broadcasted during the initial network configuration, when a network device is brought up (or when the legitimate DHCP server doesn't reply... DOS?). When a device needs to renew a DHCP lease, the DHCP REQUEST message usually isn't broadcasted anymore but is only a unicast message sent to the DHCP server which initially offered the lease.

DHCP MITM attacks are therefore usually only possible during the boot process of a device or when a running device is joining to the network.

Using ARP would allow to impersonate the DHCP server and intercept the client's DHCP REQUEST message. This may be for instance a way to push a new default router IP to a device where the MAC address of the legitimate router has been hardcoded, but its IP hasn't.
More fun: the case of DHCP DOS attacks. Check the DHCPig tool, it is a DOS tool implementing a DHCP starvation attack: the attacker leases all available IP addresses from the DHCP server so that no new address will be available for the other devices.

The core of this attack is basic and only rely on DHCP messages, but DHCPig adds a few features I like, and which involve ARP messages:

Using an ARP scan, DHCPig detects the other currently running devices and their IP and then sends a DHCP RELEASE message to the DHCP server, therefore marking their IP as free so they can now be stolen by the attacker.
Once the DHCP server has been DOSed-out, DHCPig can broadcast ARP messages which will simulate an IP conflict for each IP address composing the subnet. For Unix-like systems, this won't do much, but when Windows systems detect such conflict they immediately drop their current IP address and request a new one to the DHCP server... which is unable to fulfill the request, leaving the Windows client unconfigured. In other words, the ARP packets allowed to kick the Windows devices out of the network.


WDF-based vs WDM-based drivers What pros/cons of WDF driver model vs. WDM for rootkits and antivirus drivers. From what I've seen and from personal experience (though I'm still a newbie) WDM is good in that you have to do most of the stuff manually and at the same time you are given the right foundation elements so it is like building a Lego. On the other hand I haven't seen any WDF mentioning in terms of a rootkit being written in WDF ? Is there any particular reason why WDF and more specifically KMDF (and why not UMDF even?) are not widely (at all?) used for development of rootkit/security type of software ?

A friend of mine answered the question:

  It's like with security, really (e.g. using PGP as opposed to no
  encryption). Add more security and it has to become a little more
  inconvenient and the person who does it has to know some level of
  details. Make things convenient and they become less secure.

  With WDF you are giving up power (and possibilities). So like with
  security the convenience comes at a price.

  But let me liken the WDF / WDM discussion to something that is
  perfectly within the realm of antivirus software. File system filter
  drivers (FSFDs). Legacy FSFDs are difficult to write, to debug and to
  maintain. Some details change in subtle ways depending on the patch
  level of the OS, not to mention broken APIs or that certain APIs only
  exist at certain OS versions. The easier method - and used by the
  majority of AV vendors I am aware of - uses mini-FSFDs, where, similar
  to the WDF, btw, another driver sits in between you and the kernel
  from the logical perspective (you can still make direct calls) and
  abstracts away a lot of the difficult details.

  If someone were to write a rootkit in WDF - which has probably been
  tried - it would be easier to catch, btw. Remember that one of the
  main objectives of a rootkit is to go udner the radar.

  Also keep in mind that MS has two objectives by introducing new driver
  models:

  cater the needs of devs to have simpler ways of doing stuff and shipping faster
  making it easier for them (i.e. MS) to test drivers (the driver models usually abstract away complexities)
  provide a stabler OS to end users (BSODs are more often than not blamed on MS instead of the vendor that created the driver!)


How can I distribute highly confidential keys for a symmetric cipher? Say I want to exchange a key with someone for a symmetric cipher (say AES) without meeting them in person. What would be the most secure way to do this over the Internet? My first instinct would be using a custom RSA channel over HTTPS to provide the most security.
I need the most future-proof method possible. (keep in mind this only needs to be done once, so even an "insane" method can be considered an answer.)

For your problem, the easy way coming to my mind is PGP: both the sender and the receiver exchange asymmetric keys and can then send each other private messages. You can validate each other pulic key other the phone to make sure no one messed with it (see MitM).

For all I know, using WhatsApp or Telegram might also be secure enough as they use end-to-end encryption (the message decryption keys are on your phones only).


Windows Certificate Store - Generating / importing personal certificates using a smartcard? I think we all know Windows can store and handle certificates which is a nice feature as this enables many appliations to rely on this (like Putty-CAC).

Now I'm having the problem, that I own a smartcard and I want to use it with Windows (7). However my card doesn't support ex- nor importing private keys (which is a feature, not a bug), I can only generate them on the device.

The problem I'm facing is that I want to have my personal (/client-) certificate (which is signed by my personal self-signed root CA) being accessible by Windows.

There are multiple options I've explored so far:

Try to use certmgr.msc to generate my own certificate / private-key pair, which needs some strange setup I don't understand.
Use XCA, to manage the CA and generate a key on the device, later being signed using the CA key (using XCA). Then import the certificate into the Windows Store (without the private key) and hope things work. (Hint: They don't, for one of my personal certificates it says "you don't have the private key", the other somehow worked to accept Windows to "own" the private key, but operations using this key seem to fail (Putty-CAC))

Now my question:
What is the best route to get the keys being accepted by Windows?

One last point: I considered posting this at SuperUser, but I posted here, because this requires special security hardware and deep understanding of the security functions of Windows.

For the most part, smartcard integrations requiring pointing your email client at your smartcard reader & middleware, ensuring the proper crypto library is selected.  There is mucho information on doing this with both OpenPGP smartcards and x509 smartcards

Depending on the email client, the Windows trust store can be used, or not used.

Your operating system does not actually require access to the private key.  Instead, you interact with the private key through the smartcard reader and middleware.  Your authentication step (typing in the PIN) enables the smartcard to perform decryption or authentication events on your behalf then.  Performing this crypto-offload on the smartcard is more secure since the private key is on the smartcard, not exposed to the file system, and stealing your private key is no longer easy.

Putty-CAC & Smartcard integration

To register Putty-CAC with a working smartcard, assuming your smartcard reader and middleware are already installed and working:

Execute Putty-CAC
Scroll down to SSH & expand it
select CAPI
Select Cert and Browse
Select the smartcard certificate that corresponds to the cert you want to use
Use that for setting up SSH on the remote host

Technically, this is only RSA based SSH, not certificate based SSH, so you will miss out on some of the nifty security features of certificates

You can find expanded instructions here

Certificate Registration

Some middleware, such as ActivIdentity which is very popular, include a function for registering certificates with the Windows.

Activclient > smartcard reader > My Certificates > Select Certificate > Make available to WIndows

Additionally see the following:

Encrypting Messages w/ SMIME in Outlook Webapp

Thunderbird DoD Smartcard Configuration

Using an OpenPGP Smartcard


Analyze my custom web authentication scheme, based on a token derived from username and password To avoid having the user to login every time his session expires, I want to implement a token based authentication system.

My scheme works like this:

Send the user login (send name + password) via $.ajax() to a https URI
Create a token via $token = bin2hex(openssl_random_pseudo_bytes(16));
Save $token, userid and date in a database (only accessible by SSL)
Echo the $token and userid to the client
Save the $token and userid in html localStorage on the client
When doing an $.ajax() from client always send userid and $token as POST
Serverside, match the provided $token and see if it is still valid (date not expired).
If it's alright, continue to deliver the requested material

Can you analyze my scheme?

Many people advise against implementing custom authentication processes, as they are often vulnerable to attacks.  This makes me suspect that my approach may also have flaws.  Can you reveal these flaws to me?

So there are a few reasons why you don't want to do this, although I do not understand the code you presented as I do not deal with that. You should use a third party library to manage your sessions. There are several reasons...

Code is vetted, tested and improved across a much wider audience when you use a built in or well know authentication scheme.
When and if you leave, someone is not stuck dealing with a custom created authentication mechanism
There are probably vulnerabilities in the code, it may or may not be directly in your code but in a service you call, updating that single service may cause issues through the rest of the code, such as deprecated arguments and variables.  This may not make your program less secure but it may break it.
Self support is tough, especially when you do a good job and it is running without issue for a year or two, then bam!! in the middle of another project something breaks and you have to take the time to troubleshoot it from the bottom up.
CYA, if you make a mistake and something bad happens, you are the one people will come back to and ask, why didn't you use this or that scheme that is not vulnerable to some attack and you will have to explain that.

Anyway, I hope that helps


How can anyone access Intel's "backdoor OS", MINIX? I've read that all recent Intel-based machines include a secret MINIX-based OS, and that it even includes its own web-server.

How does one access this OS's services from the main OS?

Its purpose seems to be to be accessed through the network. How does that happen? Is there a port dedicated to it?

AMT is is hardly a secret. It is a feature for IT departments to get pseudo-console access to PCs over the network and remotely manage them.  (The common term is Out of Band or OOB management.)

It is comparable to HP’s iLO or Dell’s iDRAC, which are for servers. In the case of servers, there is usually a dedicated NIC for OOB. For desktops, that is not feasible. So Intel’s AMT lets the motherboard NIC be shared between the CPU and the Management Engine.

Here are some links to get you started:

https://software.intel.com/en-us/articles/getting-started-with-intel-active-management-technology-amt

https://www.howtogeek.com/56538/how-to-remotely-control-your-pc-even-when-it-crashes/

Note that despite many of the articles you read, not all Intel PCs have this feature. It is typically only found on business CPU/chipsets, as it is one of the differentiating features to justify the price point.


Is it a good idea to notify a user that they signed up with a social-login account? Say my website provides three main ways to signup/signin: Google, Facebook and typical username/password. Is it a good idea to flash "Please login using your Google account" if a user tries to login with their Facebook or native account?

Are there any security implications? Is it as bad as notifying a user that their password is wrong while their username is valid instead of simply flashing that the user entered the wrong combination?

Generally, the fewer things you say, the better off you are. I wouldn't tell the user anything.

Actually, if you are going to use social login, I would recommend not having any other login alternative. All you really need is a user's unique identity (within your system) e.g. their email address. (Note: in some countries, you cannot use email as an identifier).

If you do offer social login, why go through the burden of maintaining username/passwords for those individuals? The day you get hacked, the damage will be minimal.


Is chrome's prediction service for faster page loading vulnerable to attacks? is it safe to leave it on? Chrome offers a "prediction service" for faster page loading. It might load some links on a page before you even click on them:

  Use a prediction service to load pages more quickly: Browsers use an
  IP address to load a webpage. When you visit a webpage, Chrome can
  look up the IP addresses of all the page's links and load the ones you
  might navigate to next. If you turn this setting on, websites and any
  embedded content that are pre-loaded may set and read their own
  cookies as if you had visited them, even if you don't.

The option is in advanced > privacy > Use a prediction service to load pages more quickly

How vulnerable is it to attacks? Let's say someone sends me a link using Facebook Messenger or Twitter, or on other websites. If this setting is on (which is on by default!) then will Chrome open that link?

Will my IP address get leaked because of this? Maybe opening up my browser to even worse attacks and identity leaks?

I just don't understand how can this not be a major security flaw, am I missing something? Is there any protection against these type of attacks in this service if I leave it on?

It does not make sense, in terms of providing faster service, for Chrome to pre-fetch all those pages and process all of them before you visit them.

What happens is that the code is fetched and loaded, but not processed. When you click on a link, then the code is processed. This makes the process faster.

So, if there is malicious code on one of those links, it might get pre-fetched but it will not get executed until you click the link.


How to study for cyber security basic level exam? I have a basic level exam on cyber security, so I was wondering what I should read and learn for the exam. I would appreciate it if you would help me find some study materials to work with.

The best thing to studying for any exam is to find the exam outline. These are the topic areas that are to be covered in the exam. Sometimes known as the Common Body of Knowledge (CBK) or Domains.

Failing that buy a book on the exam and good luck. Without knowning the exam I can't be anymore detailed.


DGA (Domain Generation Algorithm) - malwares Some malwares use DGA (Domain Generation Algorithm) to randomly generate domains in order for the zombies to be able to communicate in a resilient manner with the C&C.

As far as I know, there is no way to acquire a TLD domain but to pay.

When I read on Wikipedia that, for example, Conficker would generate 50000 domains/day, I hardly imagine that those domains have been regularly bought. I'm probably missing something.

Does anyone know how these domains are acquired ?

I assume you are referencing this Wikipedia article for your info. Basically, the malware does not register the domain names, it just generates a list of possible domain names. The attacker registers domain names that are "possible" outputs of the DGA.

For example, if the DGA is something like:

  x = rand(10)

  domain = "xyz" + x + ".com"

  contact(domain)

Now the attacker registers xyz2.com, the bot has a 10% chance of generating the correct domain name to check in. Over the course of a few weeks, it is highly likely that, at some point, the infected machine will generate xyz2.com and contact the C2.

Point here is that the DGA just generates "potential" domain names, one of which will likley (at some point) connect to the attackers C2.


How is security risk of storing authentication token in localStorage compared with cookies? I've read that it's a bad idea to save Single Page App's encrypted authentication token in browser's localStorage because this makes your app  vulnerable to XSS attack, and when the token is stolen, the hacker can disguise as the user and do whatever evil.

But as far as I know cookies are also vulnerable to XSS hijacking.

So I'm wondering what's the difference if any? And how the risks of the two methods are compared

A cookie marked httpOnly, as the name implies, cannot be accessed from javascript.  So a 'conventional' web application using cookies is not vulnerable to naive XSS attacks if that flag is set (assuming no browser bugs expose it of course.)  Notably such a solution is vulnerable to CSRF, so more work is required to mitigate that.

In SPA frameworks you generally need access to the cookie in javascript anyway because they want to put it in an authorization header, not simply rely on "old school" cookie based security.  This has the advantage of now being CSRF resistant.

The basic rationale for an SPA is if someone manages to inject javascript they have won.  You must not have XSS vulnerabilities because the attacker can alter anything about your entire application and simply do inside the victim's own browser whatever malicious thing they would have done with the stolen token.  (or simply alter your app to steal the user's plaintext password...)

Therefore people choose to tolerate the potential exposure of the session token, because the assumed consequence of a successful XSS on an SPA is 100% compromise anyway.

(In my opinion this is by no means a settled topic, people are still having nasty arguments about it.  There's endless blog posts and forum flame wars advocating on both sides.)


Local area network multi-device network communication protocol I am planning to build a local area network that will have one Master device and multiple Slave devices. The communication should be able to handle only ON/OFF functionality of the devices (devices should turn off/on in the "same" time). NRF24L01 does not provide encryption so it would not require much effort trying to resend these commands when captured.

To protect against malicious resending of packets, my idea is to first share some private key with both devices when flashing and after that send command + new private key to the slaves. Is this solution secure against re-sent packets or how is this done in a professional way?

If slave doesn't have to acknowledge that message was received, use UDP protocol and send message to broadcast. About using encryption. I would choose asymmetric encryption (RSA). Master will have a database of public keys of slaves and only recipient (selected slave) could decrypt message while any other slave in network will ignore it. For controlling multiple devices at the same time, you will simply share another private key with several slaves.

About re-sending malicious packets (AKA replay attack). Widely used solution it to add at the begining of communication nonce (random or pseudo random number) and increment it with every command that master send. Therefore you could check if massage was replayed or not.


How to protect my network against local flood attacks? I installed VM centOS 6.8 then I installed hping3 tools.
With this tool, I can take down any PC connection on the network as well as increase CPU and RAM usage with the following command

hping3 --flood -S xxx.xxx.xxx.xxx

I have done a lot of search on Google, and most of the people advise to follow these steps to add/modify the registry

To do that, open Windows registry editor and go to this registry path

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

Create "DisableIPSourceRouting" Data Type " REG_DWORD" Set Value To "2"

Create "IPEnableRouter" Data type "REG_DWORD" Set Value "0"

Create "SynAttackProtect" Date type "REG_DWORD" Set type "3"

Create "TcpMaxConnectResponseRetransmissions" Data type "REG_DWORD" Set Value "1"

Create "TcpMaxHalfOpen" Data type "REG_DWORD" Set Value "500"

Create "TcpMaxHalfOpenRetried"  Data type "REG_DWORD" Set Value "400"

But unfortunately even I have added those, I still can do this kind of attack.

More information, I'm using Symantec endpoint security 14, and I have enabled " Enable denial of service detection "

Any assistance would be greatly appreciated

The registry settings that you list are for particular types of mal-formed traffic that can cause DoS. But what you are doing is sending more traffic than the destination can handle. All the packets are properly formed. There is no registry setting to protect against high-volume floods.

To protect something from a flood, you need something in between that can hold the flood back. Like a router.


Does SSH authorized_keys violate the principle of "re-authenticate before password change"? It is generally accepted that password change mechanisms should ask the user for their old password (e.g. OWASP) The reason being that an attacker who has temporary access to a user's session (be it through XSS, computer left logged-in, whatever) would only have access to that session.

Presumably this principle should carry forward to other authentication mechanisms - certificates, tokens, etc. (although I've never seen this discussed)

However, consider how SSH authorized_keys works. If you have access to a user's login session, but not their keys (e.g. they left their computer logged-in) then you can modify the authorized_keys file. You could add your own key to the file, so you could get access to the account in future. You could also remove the legitimate keys to lock out the account owner.

So should the SSH designers be looking at ways of tightening this? And what approaches could we take to stop this vulnerability?

Yes, you're correct, SSH authorized_keys allow authentication changes without verification if an opponent is granted (or steals) shell access once (or has sufficient file access).

I'm going to go out on a limb here and suggest that SSH authorized_keys was designed as an improvement upon the .rhosts paradigm.  A way to allow seamless access between hosts but with more than bare trust.  So from that perspective, authorized_keys are indeed a great improvement in security.  That's not to excuse the issue you're describing, but to put it in context.

The only approach that will really address this issue is to centralize key authentication.  Instead of using disparate key files, require users to submit keys into a system repository, just as they submit their passwords into the /etc/shadow repository via intermediary programs.  That'll mean code, and file ownership and protection issues, and the replacement of a simple file edit control with a more structured and probably difficult database manipulation interface (one that requires authentication to permit manipulation!).

Doable?  Certainly.  Easy?  No, it'll be a bit of work.  Likely?  Probably not; this area of weakness has been known and accepted for a long time, without new impetus I don't see anyone pushing hard to fix it.


How is AWS app identity verified? So I get the notion of roles and service-linked roles and policies in AWS. However, all of that works only if the principal/identity (and I know there's a difference between the two, but using either term quite liberally here) being claimed by an app can be verified (i.e. app authentication). I am guessing this authentication occurs against the "AWS fabric" and not the target service/resource the app wants to access.

Can anyone share details of how an app establishes its identity and how the "fabric" verifies the identity?

Azure has the notion of managed service identities (based on system assigned identity and VM extensions).

What's the equivalent on AWS? How does the AWS "fabric" assign/verify app identities?
If the only mechanism for verification is an access key and secret key (or a bearer token), I would think that's either a circular problem for credential management or very insecure.

Of course, I could be totally wrong in the way I am comparing Azure identity management to AWS, but it seems that a credential-less verification/assignment of identity as in Azure is probably as secure as it gets.

I've never used Azure, but that looks similar to AWS KMS that apparently also uses HashiCorp Vault. You can see some use cases here.

Take a look at this, I think it explain what you need.

  EC2 auth method Amazon EC2 instances have access to metadata which
  describes the instance. The Vault EC2 auth method leverages the
  components of this metadata to authenticate and distribute an initial
  Vault token to an EC2 instance. The data flow (which is also
  represented in the graphic below) is as follows:

  Vault AWS EC2 Authentication Flow

  An AWS EC2 instance fetches its AWS Instance Identity Document from
  the EC2 Metadata Service. In addition to data itself, AWS also
  provides the PKCS#7 signature of the data, and publishes the public
  keys (by region) which can be used to verify the signature.

  The AWS EC2 instance makes a request to Vault with the PKCS#7
  signature. The PKCS#7 signature contains the Instance Identity
  Document within itself.

  Vault verifies the signature on the PKCS#7 document, ensuring the
  information is certified accurate by AWS. This process validates both
  the validity and integrity of the document data. As an added security
  measure, Vault verifies that the instance is currently running using
  the public EC2 API endpoint.

  Provided all steps are successful, Vault returns the initial Vault
  token to the EC2 instance. This token is mapped to any configured
  policies based on the instance metadata.

  There are various modifications to this workflow that provide more or
  less security, as detailed later in this documentation.


Is it possible to modify jQuery client code to call a remote API in an unintended way? Is it possible for someone to modify the JQuery code of a remote page and make it call the remote APIs in a different way than intended?

Suppose the website www.domain.com has a jquery.js script which calls an API always on domain.com passing a name and a surname:

domain.com/api?name=bla&surname=blo

now is it possible for someone to modify the jQuery from the browser with something like Firebug and call the API without name and surname for instance and thus get a whole list of people without filtering:

domain.com/api?name=&surname=

I could of course check in my API for the two parameters to be present but suppose I have no way of modifying the listening API program.

Could my jQuery script check for the domain from which the script is executed? for instance if someone saved my jQuery file locally and executed it, would it look to the remote API the same as if the jQuery was executed from the intended web page at www.domain.com?

My idea is that a jquery script is always run "locally" whether it is downloaded from the intended page or from a modified version, however some sites seem to be able to let an API be called only from the intended script.

You can't rely on any protection from changes in client side code, you can only do your best to prevent them (ie XSS and CSRF). Anyone can run arbitrary JavaScript code on a page as if it were run by that page itself.

Edit:

As an example, if you're using a modern desktop browser such as Chrome, right-click anywhere on this current page then click on the option to "Inspect" the element. A sub-window should pop up and will highlight the element of your choice. You'll notice that you can directly modify some of the HTML on the page through this interface. Additionally, there will be a console tab (along with other useful debugging tabs). If you go to the console tab, you'll be given a screen where you can directly run JS in the context of the page you're viewing. If you have an element selected in the Elements tab, you can change the background of that element by running the following JS code:

$0.style.background='yellow'

Multiple lines may be used (Shift+Enter) or the contents of an entire JS file may be copied and pasted directly into the page using this console window. You'll probably also notice while using it that it has a feature similar to auto complete. This makes testing and debugging JS code much easier.

It is also technically possible for the request to be simply changed in-transit by an installed browser extension or man-in-the-middle, or the request could even be made using completely different JS code that is injected. So basically the only safe bet is to perform all necessary input sanitation on the server side and only do so additionally on the client-side for the benefit of user experience.

Hopefully this thoroughly answers the question.


SSL with shared webmail URL I have an account with a shared email hosting service (e.g mailcheap) and the the webmail URL is hence https://xxx.mailcheap.co. This webmail has HTTPS.

Now I created CNAME records on my domain to point https://webmail.mydomain.com to https://xxx.mailcheap.co. However, when visiting the webmail through this route, the SSL is broken with a loud in-your-face warning i.e

  "Your connection is not private
  Attackers might be trying to steal your information from...".

I take it because the SSL certificate on the email host's webmail does not cover mydomain.com.

Besides putting up a redirect to send webmail.mydomain.com to xxx.mailcheap.co, is there any other way to prevent that "Your connection is not Private" warning?

I take it because the SSL certificate on the email host's webmail does not cover mydomain.com.

This is correct. To cite from What SSL certificate do I need?: "DNS settings like same IP address or alias (CNAME) do not matter at all, all that matters is the name given in the URL.". And since the name you use in the URL is not covered by the certificate you get the validation problem.

  ... is there any other way to prevent that "Your connection is not Private" warning?

Since you make sure that the URL matches the certificate you need to either change the URL or the certificate. The first can be done with a HTTP(S) redirect as you've already noticed. For the second some service providers might let you setup your own certificate. If this is not possible you might try to setup your own server with your own domain and proxy all traffic to the original web application. Note that this might not work with all applications, i.e. some might have the expected name hard coded somewhere in the application.


This challenge is part of an ongoing French DGSE services challenge. You have one thing that's missing. Check again how you obtained your prime1 number. The parameter went through specific substitutions that can be reversed but not in a simple way.


PIN Entry via HTML rendered Keypad I have a web application that replaces a non-web predecessor.

A low level set of users accessed basic functionality with touch panels in the non-web previous version of the product with the touch panels being secured with a PIN code.

The replacement devices panels will be android.  We have suggested doing this as a passphrase, or as a numeric input, but product management wants an HTML rendered "key pad" screen instead of the normal android input panel behavior.

Gut feeling is that this is less secure than using the OS inputs, but I cannot come up with a concrete reason that it should be that doesn't also apply in either case.

Am I overlooking something or is my initial reaction incorrect here?

There is no huge security weaknesses with them. Actually, a lot of websites (banks notably) are already using web rendered keypads as part of their customer's website authentication mechanism.

While there is still pros and cons, this offers the developers more flexibility than using standard OS input. In particular, the numbers can be presented in random order (preventing shoulder surfing) and it can be made impossible (or at least difficult) for the end-users to copy-paste the password or make the browser remember it.

The main argument I saw against such systems is a direct consequence of the anti-copy-paste feature, since it also prevents the use of password safe software to securely store the password. But this is not a weakness of the HTML rendered keypad per se.

As you said, all attacks valid against the former could also be done against the latter in one form or another.


How does the TPM perform integrity measurements on a system? I am trying to find out how the TPM performs an integrity measurement on a system. It is well-documented in the TPM specification how it seals the data it has measured in the PCRs and how it is updated. But that which I can't find explained is how the TPM actually performs the integrity measurements that it is sealing in the first place. To know if the system is in a given state or not it has to measure it, but how does it do that? And what is it that it actually measures? Most papers seem to gloss over this, and I get the feeling that ready-for-storage-in-PCR-data just appears out of the blue.

There's basically two way of doing this;

SRTM (Static Root of Trust for Measurements) and
DRTM (Dynamic Root of Trust for Measurements).

SRTM takes place at system boot. The first thing getting executed at boot is called the Core Root of Trust for Measurements (CRTM) aka the BIOS boot block will measure the BIOS and send the value (hash) to the TPM in a location called Platform Configurations Register (PCR) 0 before executing it. Then the BIOS measure the next thing in the boot chain and again, will store the value in a PCR of the TPM. This process is executed for each components in the boot sequence (PCI option ROM, boot loader, etc).
TrustedGrub is a TPM aware boot loader that will send the proper measurements to the TPM. It is use to continue the chain of measurements (SRTM) from the BIOS up to the Kernel.
DRTM is very different as it's something happening while the system is running. Intel’s implementation is called Trusted Execution Technology (TXT) while  AMD use the name Secure Virtual Machine (SVM). The goal of DRTM is to create a trusted environment from an untrusted state. Technically, it creates a secure/clean state and will report (provide measurement – hashes in PCRs) on a piece of code someone wants to execute (aka Measured Launched Environment - MLE). Typically, the MLE is an Operating System (kernel, userspace, etc).
Without going into details, Intel's DRTM works by calling a set of new CPU instructions (SMX) which tells the CPU and the chipset to perform a very specific set of tasks (GETSEC) which ensure nothing else than a special code can run, i.e. SINIT Authenticated Code Module (ACM). This part includes disabling all but one CPU and blocking/stopping everything currently running: all other processes, interrupts and I/O (via IOMMU, e.g. to avoid DMA attacks). Then, all CPU rejoin in a clean state - anything executed before is discarded. At this point the signature of this special code (SINIT ACM) gets validated and its identity (hash measurement) is sent to the TPM in the PCR 17. Afterwards, execution is passed to the ACM which then measure the MLE and sends the measurement to the TPM in the PCR 18. Finally, execution is passed to the MLE.
Tboot is a tool created by Intel to do just that (DRTM) and an alternative to TrustedGrub (SRTM).

Here's an example of what PCRs values looks like with SRTM (TPM aware BIOS) but without a TPM aware boot loader (e.g. TrustedGrub) and without DRTM (e.g. Tboot):
# cat /sys/devices/pnp0/00:09/pcrs
PCR-00: A8 5A 84 B7 38 FC C0 CF 3A 44 7A 5A A7 03 83 0B BE E7 BD D9
PCR-01: 11 40 C1 7D 0D 25 51 9E 28 53 A5 22 B7 1F 12 24 47 91 15 CB
PCR-02: A3 82 9A 64 61 85 2C C1 43 ED 75 83 48 35 90 4F 07 A9 D5 2C
PCR-03: B2 A8 3B 0E BF 2F 83 78 29 9A 5B 2B DF C3 1E A9 55 AD 72 36
PCR-04: 78 93 CF 58 0E E1 A3 8F DA 6F E0 3B C9 53 76 28 12 93 EF 82
PCR-05: 72 A7 A9 6C 96 39 38 52 D5 9B D9 12 39 75 86 44 3E 20 10 2F
PCR-06: 92 20 EB AC 21 CE BA 8A C0 AB 92 0E D0 27 E4 F8 91 C9 03 EE
PCR-07: B2 A8 3B 04 BF 2F 83 74 29 9A 5B 4B DF C3 1E A9 55 AD 72 36
PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you can see, PCR 0-7 are filled but from PCR 8 to 15 it's empty - they are still reset to 0. Since DRTM hasn't been used, PCRs 17-22 are filled with 1s (f).

The security of those mechanisms relies on the fact that PCRs values cannot be set (or forged) but only extended (TPM_Extend()). This means whenever a measurement is sent to a TPM, the hash of the concatenation of the current value of a PCR and the new measurement is stored (i.e. new_value = Hash(old_value || new_measurement)). Obviously, there's a beginning to all of this:

With SRTM, only the CRTM can reset PCRs 0 to 15 at boot
With DRTM, only the TXT instructions can reset PCRs 17 to 20 (when in locality 4 (SMX operations)). See this answer, this presentation or the specs for the details.

It's important to understand that while the TPM collects those measurements, it does not take action on them-actually, it can't. The value of those measurements can only be seen with the seal()/unseal()/quote() operations: Now that we have measurements in the TPM's PCRs, we can use the unseal() operation to reveal a secret which is only accessible if the correct PCRs values are in the TPM-they are used as encryption keys. This basically means that a secret can only be accessed if the proper environment was loaded via SRTM (BIOS, bootloader, kernel, etc) or DRTM (SINIT and MLE (kernel, etc)). See this answer for more info.
For more info, I suggest you read this 101 and then this document.


How can I find a CVE ID for "No Translation Available" entries in Foundstone or McAfee Vulnerability Manager? On a recent scan using McAfee Foundstone Enterprise (newer versions are known as McAfee Vulnerability Manager), I ran into a "No Translation Available" error.

It's rather frustrating that these errors leave me without any specific description or resolution details on the vulnerability.  But I find the most aggravating part is that it even leaves out the CVE IDs.  The only identifying information I'm left with is a "Risk Rating" and "Vulnerability ID", both of which seem to be proprietary to McAfee.

Searching online has led me to practically nowhere, except for a couple of un-helpful McAfee KnowledgeBase entries.  What the KB entries tell me is that, while this is occasionally a legitimate problem on the system which can be troubleshot and resolved, the issue is more often due to the way McAfee sends out updates.  Apparently, the language packs are regularly released a week or two later than the content to which it applies.  So, during that gap, the Foundstone scanner knows how to check for a vulnerability but doesn't know how to tell you about it.

Is there a website somewhere that I can use to look up these Vulnerability IDs, and find a corresponding CVE ID?  Google has been no help, and I haven't found anywhere on McAfee's site yet that works either.

One particular example that came up recently was Vulnerability ID 11900, around 1900 EDT on 4/21/2011.

I've often found the MVM reports are lacking when it comes to this.  Especially on the plethora of 0 days that were dropped December 2010 in multiple different browsers and rendering components of Microsoft Operating systems.

This is one of those.

The process I've found that can identify most (call it 90%) of the "No Translation Available" items for Microsoft related vulnerabilities is as follows:

Step 1:  Hit Mcafee labs and run a search on the Vuln ID.
http://www.mcafee.com/apps/search/default.aspx?q=Vulnerability+ID+11900&searchSubmit=Go

Step 2: Hit Technet and search with the string used as the description.
http://www.microsoft.com/technet/security/advisory/2501696.mspx

Step 3: Hit google with the Advisory number and hopefully there's an MS numbered patch released, if not you're likely to get a page detailing mitigation steps that can be taken.

In this case, you're lucky, and there's a patch released.
http://support.microsoft.com/kb/2501696

Step 4: Call/Email your rep and give them the details above and request the vulnerability "recommendation" be updated with the information provided.

If you're looking for it in a language microsoft supports on their main page this will give you an interim solution.  Though honestly CVE's are registered for almost anything, this is probably just Mcafee not doing their diligence to find it.


What's the difference between trusting a key and signing it? What's the difference of meaning between trusting (trust command) a key and signing (sign command) it?

Trusting a key means that you will accept signatures from it. Signing a key means expressing that you have checked that the user really belongs to that key.

So, for example, if I sign your key, I am saying (to myself as well as to others) that this really is your key. That doesn't necessarily mean that I trust a signature from you on someone else's key. That only happens if I mark your key as trusted.


OpenSSL Generate ECDH Public Key I am trying to use the OpenSSL command line to generate a ECDH public key that meets the following specifications:

  Use a Base64 encoded X.509 SubjectPublicKeyInfo structure containing a ECDH public key for group P256

They following commands provide me with a key:

openssl ecparam -name prime256v1 -out prime256v1.pem
openssl ecparam -in prime256v1.pem -genkey -noout -out prime256v1-key.pem
openssl ec -in prime256v1-key.pem -pubout -out pubkey.pem

Key: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE85KGK3YiX7tC7mFm+Te1xRYOeDq23h80MPPt1nMZ/ZRpwjRGPEUr6vaoOCB8QC3uHmaPKOAgQ0Kk9Sc4M1QUmA==

However this key is not being accepted by the API I am accessing.

An example key that is working is:

MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACKoJz0lSBocGMsdl8TiMasRsBOxpMywCqzAoOLwZfUl0=

This example key is 44 (Base64) bytes shorter and has a slightly different SubjectPublickKeyInfo signature.

My question is what is the difference between these two keys and how could I use the OpenSSL command line tools to generate such a key pair.

Try compressed version

What you posted there as "example key that is working" is a base64 encoded EC pubkey without the PEM wrapper and without the usual line breaks. And more specifically it is a COMPRESSED version of the EC pubkey. But openssl writes  UNcompressed keys by default.

You can convert between the compressed und uncompressed versions like so:

$ cat ExampleOfRejectedKey.headerlesspem
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE85KGK3YiX7tC7mFm+Te1xRYOeDq23h80MPPt1nMZ/ZRpwjRGPEUr6vaoOCB8QC3uHmaPKOAgQ0Kk9Sc4M1QUmA==

Make openssl parse in the key

$ openssl ec -inform DER -pubin -in <(base64 -d ExampleOfRejectedKey.headerlesspem)
read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE85KGK3YiX7tC7mFm+Te1xRYOeDq2
3h80MPPt1nMZ/ZRpwjRGPEUr6vaoOCB8QC3uHmaPKOAgQ0Kk9Sc4M1QUmA==
-----END PUBLIC KEY-----

Again but with "-conv_form compressed"

$ openssl ec -inform DER -pubin -in <(base64 -d ExampleOfRejectedKey.headerlesspem) -conv_form compressed
read EC key
writing EC key
-----BEGIN PUBLIC KEY-----
MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgAC85KGK3YiX7tC7mFm+Te1xRYOeDq2
3h80MPPt1nMZ/ZQ=
-----END PUBLIC KEY-----

As you can see: It's a lot shorter now. And closer in length to the working key. Try this. (Why any API would insist on a compressed representation, and not say so, is beyond me.)

Further reading

See this question: 2011-07-12, Is there a standardized fixed-length encoding for EC public keys?


Is it secure to access web with Xubuntu in VirtualBox running in Windows XP? Support for Windows XP is ending soon. Therefore, I am seeking a secure solution to continue with Windows XP.

When I access the web from Xubuntu in VirtualBox running in Windows XP, is the Windows XP environment secure? And if not, how can I make it more secure?

EDIT: I am asking for a level of security for everyday use  - e.g. Firefox or Chrome, reading blogs, viewing emails, Youtube etc. I try to avoid shadier sites like porn sites, executing files from unknown sources etc.

This is mostly fine, but you have to consider a few things.

Firstly, the virtual machine accesses the internet presumably via the host, meaning the host has internet connectivity. This must be suitably firewalled, preferably relying on an external hardware firewall as exploits may be found in the XP (SP3) firewall that won't be patched.

You will probably need anti-virus running on the host machine if you are downloading files in the virtual machine that become readable/executable by the host.

If malware ever infects xubuntu, and this exploit can defeat the hyper-visor provided by virtualbox and then has the ability to infect an XP machine, then of course you'll be infected that way, although this is a rather convoluted and unlikely attack vector. Plus this could still be mitigated by anti-virus running on the XP machine that may prevent exploits even if OS patches aren't provided for them. This is because some anti-virus vendors will continue to create signatures for malware affecting Windows XP, in addition to heuristics.


WPA3 technical doubts(2) This is the second post regarding wpa3 technical doubts that came up when I was trying to understand the principles behind this new  wifi security protocol. I am new to cybersecurity and being self taught so every bit of help is greatly appreciated!

Wifi Alliance has announced that WPA3 will include SAE protocol, which is based on the dragonfly handshake, leaving behind the 4 way handshake used in WPA2 that was vulnerable to KRACK.

From what I could gather, prior to SAE the device and the router  agree some elliptic curve parameters and they apply a known transformation ( e.g. PBKDF2) to the network password and each STA generates the password element (PWE), a secret value(called rand) and a temporal value ( called mask). This values shall not be used in successive protocol runs.

So, once this is all derived, SAE protocol uses two message exchanges  to establish the connection, a commit and a verification message.  STA-A generated the commit message using the PWE and the generated secrets.

When  this is sent if the STA-B  checks that the commit message is not validated ( expects a value in the message that can be computed using the secrets generated in STA-B) then the authentication fails and the connection process is terminated. Otherwise if successful,  a Key (K) is generated, then it is  hashed and from it  a KCK and the PMK are derived.

A verification message is sent to STA-A.  When STA-A receives the verification message, it verifies that the values given match with what STA-A expected, and thus if everyting is ok, then STA-A generates the PMK.

Now with the PMK data encryption using AES can take place. Is what I understood correct?

Also, I have read that SAE provides forward secrecy, so, how is that achieved? Is a new PMK  generated (i.e. key  renovations) each time a message is sent (so does SAE run every time a message is sent)?

Now with the PMK data encryption using AES can take place. Is what I understood correct?

I believe you are correct, though I did not look deeply into the protocol.

  Also, I have read that SAE provides forward secrecy, so, how is that achieved? Is a new PMK generated (i.e. key renovations) each time a message is sent (so does SAE run every time a message is sent)?

It's not SAE itself that provides forward secrecy, rather SAE enables WPA3 to support it. In previous encryption protocols, the password used for authentication was also used for encryption. One way or another, the key used used to encrypt the raw traffic was derived from the access point password. This meant that someone who had recorded traffic and only later discovered the key could retroactively decrypt content going far back, even as far as months or years.

WPA3 is a little different. Because SAE dissociates the password from the encryption key, the device is free to use public key cryptography to exchange a completely random symmetric key. This key is different for each connected device, and changes each time you connect. It is possible that it also rekeys itself periodically, but that is not strictly necessary for forward secrecy. The end result is that an attacker who somehow finds out the key (e.g. by connecting a debugger to the router's motherboard and reading memory) would only be able to decrypt the current session, not past sessions.


Cracking WI-FI password offline at distance, is that possible? Let's suppose I was able to get a handshake from my target's network and I got the .CAP file (containing the handshake), but I would like to crack the password from another location (away from the target network location). Would it be possible, or do I have to be nearby the target network to do that?

You can be anywhere you like.
Once you have the handshake you can crack the password anywhere you like.
The handshake is as if you have a "hashed" password and you want to crack it.

One method of doing this is using aircrack-ng which tries to crack the handshake using a dictionary attack (This is a passive attack on your captured packets). You can view the full tutorial here.


Are passport stamps a reliable security feature? Most countries in the world still place passport stamps on arrival/departure into the country. Theoretically it is then possibly to calculate the length of a person's stay in a specific country.

Is this actually a good security feature? If not, why are passport stamps still used?

As @BobBrown said in comments, we need to ask what problem the passport stamps are supposed to be solving. Turns out it is a security problem, but not in the way you are thinking (I think). Let's say I'm a Canadian visiting the UK. In addition to providing a record for the UK gov - which surely they're also recording in a database - it acts like a receipt for me in case, at some point during my visit, I'm asked to prove that I entered the UK legally. For most airline travelers, the stamp is the only legally-binding entrance paperwork that you're given. The stamp is placed in your passport to tie the stamp to your name and for your own convenience, but I believe many countries will give you the stamp on a slip of paper if you're concerned about the privacy issue of putting it in your passport.

You might think "there should be a central database that tracks entries and exits". Problem: 1) this information is for domestic tracking only, countries will object to letting other countries see their border records, and 2) I - the Canadian citizen - am the person who needs the proof. If it's stored in a UK federal database, why should I trust that it won't be tampered with, or modified to frame me?

"Ok, ePassports now contain smart chips, your entry / exit info should be stored encrypted on the chip". Problems: 1) you - the random citizen - don't have the tech to verify that the entry info placed on your chip is accurate (whereas with a stamp you can look at it when it's handed back to you). And 2) given that every country has different policies about passport stamps (like Israel who gives a separate "Landing Slip" rather than putting it on the passport), and given how much trouble we're having getting the current specs for ePassport adopted by all countries, good luck with that.


Confidentiality of file hashes Context: I have a directory full of sensitive company files. I want to compare these files with a colleague at a remote location, without the need for a secure connection.

Is it safe for me to publicly publish a list of the SHA-1 hashes of these files?

I understand that it's impossible to reverse the hashing algorithm, but since the hashes are calculated from the original file, is there any chance that an attacker could perform some sort of a brute force attack to rebuild the original file? (Note that collisions in this case don't matter.) It's clearly impossible with a 20 page document, but could small files be vulnerable?

What about if I used a more secure hashing algorithm, like SHA512?

(I'm not very familiar with salting, but I think it wouldn't help in this situation because I don't care if an attacker identifies two files as the same, just if they identify the original contents.)

The security you are thinking of with regards to the hash strength and the security you are talking about with the hashes on the internet are two different things. Hashes like SHA* are designed to work quickly so that files you send and the file you receive can be verified to be the same, however, this makes it easier brute force, due to this speed.

What it all boils down to is bits of entropy: the more bits of entropy the file has, the longer it will take to guess. I would say that if your file is more than a (arbitrary limit) 1kb, it should be reasonably safe from brute-forcing.

However, that without a secure connection, you cannot guarantee that the messages have not been modified in transit.

If you are reasonably sure that your hashes are not going to be modified in transit, this should be a reasonable way to compare the two copies of the file.


Safer k128 key schedule Can someone explain to me how safer 128's key schedule works? there are many parts that make no sense because they were not described at all in the paper (pages 3 and 5 in the pdf).
The second paragraph in part 2 is basically the same sentence 3 times. he doesnt describe how the subkeys are put together, as shown in the diagram on page 5. What does the horzonal bracket thing mean? for all i know, it is like a circuit diagram, and it is a jump of some sort. it seems to be neither add nor xor. so what is it?
also, the first bit rotation says Rotate Each Byte Right by 3 Bits, but the rest of them say Rotate Each Byte Left by 6 Bits. how does that allow for both halves to generate the same subkeys?
and yes, i know safer is not safe. im just doing this to learn how the different algorithms work

Page 239 in that PDF has a Turbopascal program of Safer, including the key schedule. So I would start there (the author himself says

  Appendix B contains a TURBO PASCAL program that implements encryption for the full r-round SAFER K-128 cipher. This program should be taken as the official definition of the SAFER K-128 encryption algorithm.

on page 214....)


Scrypt + Bcrypt = cascade hashing I've read here that hashing with differents algorithms would be a good idea.

Can you confirm that?

In your experience, is it useful and safe? Does it entail any security holes?

Generally speaking, cascading algorithms is rarely a good idea. Cascading works very well at making software more complex and less responsive, which is hardly desirable. The usual "justification" of cascading is that it should somehow (possibly magically) resist complete breakage of one of the algorithm, but not of the other. In practice, this is not so, for several reasons:

There are several ways to "cascade" and they do not do the same thing. For instance, if you have hash functions f and g, and you want to protect against preimages, then cascading as f(g(x)) might work; but if you want to protect against collisions, that's f(x)||g(x) which makes sense (i.e. concatenation, not composition). People who request cascading rarely think about what they actually want with sufficient depth in that respect.
Let's face it, this is not 1938 anymore. The algorithm itself is never the weak point; what's weak is how it is (mis)used. Cascading is like looking at a steel door on a wood cabin, and claiming that it should have an extra, heavy padlock in addition. It is a great and time-honoured way to avoid dealing with real security issues.
In the specific case of password hashing, there is one glaring weakness, which is the password itself: passwords are guessable. So we want slow hash functions, and we defeat the attacker by putting more CPU into it ourselves (i.e. we increase the number of iterations, so that the hash is as expensive as possible; the attacker's advantage becomes how much more CPU he can muster when compared to the honest server). The server's CPU is his line of defense. Cascading means wasting precisely that lifeforce, just for the fuzzy feeling that it will make things more resistant to fabled cryptanalytic breaks.

So no, don't cascade. At best, it will just make your life harder. More often, it will more or less directly decrease security.


Firewall Benchmark, Checklist, Guideline? I'm doing some research on checklist, benchmark, hardening guidelines. And I couldn't find specific documents for security checklist for firewall.

CIS had this document, but it was only for Cisco firewall, and also one for Checkpoint firewall.

And I found another one from NIST, named "Guidelines on Firewalls, policy", which was for configuration.

SANS got this nice document of Firewall Checklist, but I'm afraid it's too old, as all the info's are from 2000-2001. Are there any checklist, benchmarking kind of "standard", guide, material?

Here's a good one on filtering your egress traffic.

And here's a whitepaper put out by a firewall provider (they start the sales pitch on page 6, but the rest before it is solid advice).

This is Microsoft's take on the matter.

This is a document written by Kevin Beaver, an infosec professional.

Cover all the bases? :)


Do I need to worry about my SSH keys if my system was vulnerable to Heartbleed? So I'm getting conflicting information from members of my team.  The premise is, if an attacker can keep requesting 64 kb chunks of memory from my server, they could get the entire memory footprint of my server, and thus get the private key I used out of memory.

So, is the private SSH key I used to log in stored in memory?  Do I have to worry about my SSH keys?

No.  OpenSSH uses a very limited subset of the OpenSSL library, and that subset does not include the code involved in the Heartbleed vulnerability (or any of the other SSL/TLS code, for that matter).

Additionally, the Heartbleed vulnerability doesn't permit an application to read memory outside of its address space, so, for example, a vulnerable web server can't reach out and grab keys from a SSH server.


OpenID Connect/OAuth 2.0 and "fake" official apps My question mostly pertains to OpenID Connect, but can be applied to OAuth 2.0 as well.

When it comes to an OpenID Connect Client doing the "authorize" dance with the OpenID Connect Provider, the client sends its Client ID to the Provider to state which one it is. This is used in places such as the "consent" screens, which prominently display which scopes you are willing to allow the client to use with the Relying Party as a part of the access tokens that will be issued. The Client ID might also be marked as "special" in some way, like if it is for an "official app" it might allow this app to bypass certain consent screens that would otherwise be displayed to a third-party or display prominent visual cues to the user that this is an official "trustworthy" app.

My question revolves around to how to prevent said apps from being impersonated. With server-side apps these are protected through the use of a "Client Secret" which is unavailable to a malicious client. With browser-based clients (using the "implicit" flow), the "Client ID" is bound to a specific post-authentication redirect, which means a malicious client that is fraudulently using the "official" client's Client ID would never see the granted tokens, since the browser would redirect back to the wrong place (or the redirect URL would be rejected.

How do native apps, such as iOS or Android apps prevent against this kind of attack where the Client ID/Secret is stolen out of a legitimate app and used by a rogue app to impersonate it during OpenID Connect auth flows? As far as I see it, I could "steal" the Client ID (and/or the Client Secret) embedded in the "official" app, upload a rogue app to the App Store/Play Store that uses said ID/Secret, and then make sure the redirect URI that's used is the same as the official app. My rogue app would then listen to that redirect URL for the resulting tokens, and during the authorization dance the screens displayed to the user would prominently state that this is an "official" app and/or bypass those consent screens entirely, even though this is a third-party app.

(Sorry for the wall of text leading up to the question! Just wanting to make sure all of my assumptions are correct! Please, tell me if I have anything wrong!)

Stealing the client secret is becoming increasingly more difficult since these can now be stored using hardware APIs for encryption/safe storage on modern devices.  Mobile applications should use those to the fullest possible extent.

Some time ago, the advised flow to use for mobile apps was the implicit flow - no client secret and no way to get a refresh token, which limited the possible window of attack.

These days I'd advise the Hybrid flow (code id_token), which does allow refresh tokens and thus also requires a secret.  That secret must be stored as safe as possible, and additionally you should implement PKCE protection.  PKCE protects against code interception attacks, not unlike what you describe: a malicious app could steal the auth code by registering the redirect URI/scheme.  PKCE protects against that by requiring you to send over a code challenge (generated from a cryporandom code verifier) when sending the auth request.  On each request to the token endpoint, the verifier is sent.  That allows the IDP to check this against the challenge, which ensures tokens are only delivered to the correct redirection URI.

Hope this helps :)


Stateless session cookie and logout I have implemented stateless session cookie, something along the lines of this article:

Demystifying Web Authentication (Stateless Session Cookies)

The cookie contain an expiry time within the hashed value, and also the cookie is set with a session timeout in the browser.  When the user logs out, the cookie is deleted.  However, someone noted that an attacker can steal the cookie and essentially use it within the specified expiry time in the cookie even though the user has logged out.  Is there a solution to this problem (beside ditching stateless session cookie and using standard server/framework session management)?

The whole point of having a "stateless" thing is to avoid maintaining state (here, on the server side). Stateless servers are unavoidably subject to replay attacks, by definition. The problem you are envisioning is basically a replay attack.

If attackers can steal clients' cookies, then you already have bigger issues. If they cannot, then there is no problem. Use SSL.

(SSL is not the ultimate solution for everything, but it helps avoiding cookie-stealing, at least as long as the cookie is marked as secure and HTTP only.)


Exchange encrypted messages on public chatroom Not so long ago, I was chatting with a friend on our university's accounts, and the discussion went to an interesting subject: what if the administrators have access to our messages?

So we had the idea to encrypt .txt files using some software (7zip for example) and send these files through hangouts securely.

An idea would be to encrypt the file with my key then send it, my friend would encrypt it with his key then send it back to me, I decrypt the file with my key then send it back to my friend who would finally be able to read the contents of the file. The problem here is that the order of encryption keys matters for 7zip's encryption algorithm, so step 3 would fail, because only the last used key can be used for decryption.

So, is there a workaround? (pretty sure there is, cryptography does magic), and is there some simple utility to do such a thing maybe without manually bothering about the details?
Thanks.

This is the typical issue with encryption: the trouble is not how to securely encrypt a file but rather how to handle the encryption keys.

Basically, you have several options:

Use a secure channel to exchange the encryption key. It could also be a less than secure channel that you just hope isn't intercepted by anyone monitoring you line (SMS, for instance)
Use a method to securely agree on a common secret to use as encryption key (for instance, manually performing a Diffie-Hellman key exchange although you'll have to make sure no one can actually modify your exchange since DH isn't authenticated).
Use a public/private key system (for instance, PGP) to each generate a key pair and exchange your public keys in your chat room. Again, you should watch for anyone having the ability to change the traffic each of you see because they could perfom a MITM against you (in this case, i suggest using a different channel to confirm your keys. PGP makes it easy by having a key fingerprint that is much shorter than the actual key.

In practice, I would go for PGP and confirm each key over phone (it's hard to intercept and harder to fake if you know your interlocutor). Once you have exchanged keys, you can transfer any number of file using the same keys so it's actually pretty practical.


Capture windows cmd prompt execution? Occasionally (one/two times a day), on my Win 8.1 PC there's a cmd prompt popping up for about 0.1 sec, and closes automatically. It's scary, and I wonder if there's a way to capture who's doing it (and what does it do)?

The ESET scan hadn't found anything, as well as EMET. For some reason I suspect it's some intel driver, but I want to be sure.

A similar thread was discussed a couple of days ago. Hope it's of help for you. If not let me know. https://superuser.com/questions/1213475/console-window-keeps-popping-up


HTTP Verb tempering using MITM attack possibilities and prevention in rest api HTTP Verb tempering using MITM attack possibilities and prevention in rest api.

If an application URL is dependent only on http method to determine it's action, how can we reduce impact of tempering by someone using MITM techniques?

For example, GET /xyz/ displays the show page of entity to requester while DELETE xyz/ can delete the page. The concern is, if an admin user request for show page and someone in the middle changes method to Delete, page will get deleted.

Both requests needs same authentication token so the attacker, sitting in the middle, will only have to change method and entity will get deleted.

How can we reduce possibilities of such scenarios? Will a confirmation message be enough or some other measures should be applied?

If you fear a man in the middle attack you should protect against it by using HTTPS instead of HTTP. HTTPS is exactly designed to protect the data transfer against modifications by a man in the middle.

Using some kind of simple confirmation message instead will not help since a man in the middle attacker can also reply to this message or change the response presented to the client. While one might probably think of a more complex system of signed messages to deal with this properly, implementing this by yourself is much harder to get it right than just enabling HTTPS. Therefore using HTTPS should be the preferred way to protect against MITM.


Can IP address be a component of 2-factor authentication? I have a bunch of Linux machines that I wish to administer over the Internet. I currently use SSH keys, but have been advised to use 2-factor authentication. SSH Keys are something you know. Is an IP address something you have? (Yes, IP can be spoofed, but so can biometrics and so can atm cards).

Could I lock down SSH to only allow connections from my IP range and would that be considered 2-factor in conjunction with SSH keys?

I would think of an IP address as being "somewhere you are" rather than any of the traditional "something you know", "something you have" and "something you are" that are part of 3-factor authentication.

Although IP addresses are trivial to spoof, TCP connections are not and SSH is a protocol built on top of TCP.  The IP address of a TCP connection is a reliable indicator of who you are directly connected to.

Let's say I limit SSH connections to just my office IP address, an attacker is going to have to do one of:

Be in or near (if he cracks the wireless) my office
Be on the path between my office and my server (say inside our ISP).
Control a machine within my office.

Point 3. allows the attacker to be anywhere in the world but it increases the difficulty of an attack.

Points 1. and 2. significantly reduce the number of people who can successfully use the other factors (such as your SSH key or password) if they manage to acquire them and hence I see it as being worthwhile.

The quality of the IP address is a big factor here.  I used my office as the example above but if you have a dynamic IP address, do you trust the entire range your ISP owns?  How does that affect how easy it is for an attacker to get one of those IP addresses?  Does the trustworthiness of an IP address change when you know there are 10 machines hidden by NAT behind it?  What if there are 2,000 machines and 100 wireless access points?

I would not consider an IP address to be a factor on its own.


creating a testing environment This question has been asked over and over again across the web, but many answers are either ridiculous or the same. I have tried using OWASPs VM which has a range of purposely built holes in web applications to teach and explain the basics.

Here is the problem those tests are so easy even if you dont know how to pentest you can do them. I have also used hack.me which once again is just web applications (though some challenging) its all about MySQL injections and execution of code.

So here is my question:

What is the best way to legally test out server penetration skills and techniques? but more specifically... on a budget? assuming I have access to servers but little access to network hardware what approach can I take to set my self up a lab that isnt all about XSS, SQL injection and PHP execution?

I hope my question is not to broad and someone can help me and other people interested in penetration testing find a way to study safely.. (I am very knowledgeable in securing servers and encryption but I want to play for the other team!)

You MUST run your own servers, and then try to attack them, then secure them from that attack, then attack again.

You should use VMs.

One source of working VMs for a wide range of applications is Turnkeylinux; another is Bitnamithey should not have deliberate security flaws, but if you install an ISO created a few months ago, and don't let it patch itself, you can check for the most recent flaws in various software.


Should I have a maximum password length? I'm creating a webapp, and part of my authentication method is password length.

Should I put one in place? (say, 50 characters?) Or should I just put a minimum length (Currently at 6).

Are there problems with not putting in a maximum length?

You should hash the passwords using a secure algorithm instead of storing it in clear text. The hash function will result in a constant output size regardless of the length of the input string.

Using a minimum length and perhaps some other quality rules is a good idea because it helps a little against laziness.

If you are afraid of Denial of Service attacks, you could put a server side limit for ordinary input fields into place, for example 1000 bytes. It's unlikely that someone wants to use such a long password.


Strong encryption for base64 encoded public key in Android I want to know how I can achieve strong encryption of a public key present in my Android application.

It's Android's advice that

  To keep your public key safe from malicious users and hackers, do not
  embed your public key as an entire literal string. Instead, construct
  the string at runtime from pieces or use bit manipulation (for
  example, XOR with some other string) to hide the actual key. The key
  itself is not secret information, but you do not want to make it easy
  for a hacker or malicious user to replace the public key with another
  key.

There are certain solutions given like having substrings and encryption, but I want to know how can I achieve it in an efficient manner.

First, note that what you need is not encryption. This advice is about public keys. Public keys are, as the name indicate, not secret (except sometimes for privacy — but when your application's key is in your application, there's no privacy involved). What you need is to ensure the integrity of the public key, i.e. ensure that a malicious entity cannot replace it by a different key.

The application uses the public key to authenticate a purchase order. The normal sequence of events for a purchase is:

The user contacts a Google server and pays some money to purchase an in-app feature.
The Google server issues a receipt for that purchase. It signs this receipt with a private key that never leaves the server.
Your application running on the mobile device downloads the receipt.
Your application verifies that the receipt is genuine, relying on the public key bundled with the application.
If the purchase is a repeatable one (e.g. allowing to download X minutes of protected content, as opposed to unlocking a feature), the application must ensure that the same receipt cannot be used twice (replay attack). It does so by “consuming” the purchase.

The problem is that the user may modify the code or data of your application to put a public key of his choosing instead of the genuine one. In particular, he may put a public key for which he knows the private key. If he does this, he can generate purchase receipts without going through any server, and your application will accept them as genuine at step 4.

What you need to do to protect against this attack is to detect any attempt at modifying the public key. It doesn't matter if the potential attacker can read the public key, as long as he cannot change it. This means your application should contain code that verifies that the key is genuine. But whatever you do, the attacker could change the verification code (just flip a bit somewhere to change if is_genuine(public)key) to if not(is_genuine(key)))...

So you need to make it impossible for the attacker to find the verification code. Not only that: you must make it impossible for him to jump over the verification code and into the interesting part. You need to obfuscate your whole application.
But obfuscation is hard if not impossible.

There are only two ways you can benefit from obfuscation:

If no one cares about your app, maybe no one will try to crack it. (Downside: you aren't making any money either.)
You put a lot of effort into it, and only hope for it to hold for a small amount of time. Note that significant effort must be put into each release: if a lot of software is released with the same obfuscation techniques, someone will find a way to crack it, and all that software will be exposed.

For a success story of obfuscation, I recommend reading Gavin Dodd's story about the game Spyro: YOTD. The key points are that it took a lot of effort, that the objective was only to delay the crack for a couple of months, and that it relied in part on the psychology of the attackers who only spend limited time attacking each game and stop as soon as they've passed the first hurdle.

In most cases, obfuscation will cost you far more than it can benefit you.

So what can you do? As advised in the article: don't verify the purchase on the device, verify it on a server under your control. This is only useful if the result of the purchase comes from a server. For example, if the purchase is for additional content or features, the receipt should unlock the content in the user's account on the server, and the app would download any content that the server lets it have.


Proprietary RF Protocol Security I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.

It states that

  The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...

and

  ...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.

From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?

This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.

The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.

Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.

You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.

Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.

So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.

That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.


Secure query string parameters I have an application which use the Thick box jQuery component to open a popup page .

And I pass my parameters in query string like this :

 <a id="btnShowPopup6" runat="server" class="thickbox" href='<%#"RollUp.aspx?TCode="+Eval("Code")+"...."+"&AR=1"+"&TBiframe=true&height=530&width=750"%>'>

This 's the only choice I have, I can't use session variables with this method or post parameters so just the query string way.

How can I secure my query string so the user can't play with them? What's the best way to encrypt my query string?

Putting user-provided values into an eval() call is a horrible idea, because it essentially amounts to a remote code execution vulnerability. Let's say your code looks like this...

var data = eval(webRequest.Parameters["p"]);

Now imagine I put this into the p parameter...

System.IO.File.Delete(@"c:\windows\system32\ntoskrnl.exe");

Whoops! I just deleted your kernel.

No amount of messing around with escaping will work here - it's a fundamentally broken concept.

Encrypting parameters does nothing but complicate things. Go for the correct approach, and use a session variable like the language is designed to do.

Update: To be clear, I'm talking about eval() in a generic sense. If you're using the Eval binding method on a data controller in C#, you should be OK as long as no user parameters go in there, otherwise they can cause your code to dump out arbitrary values from your database, without even needing SQL injection.


Normalizing Windows Advanced Firewall rules How can I best normalize our Windows Advanced Firewall rules while implementing network segmentation? I want them to be as clear and concise as possible for audit purposes. What few examples I've seen have centered on locally defined firewall rules or had dozens of group policies.

I have been thinking it would make sense to extrapolate my rules endpoints into three broad categories, much as the Open PCI Scoping Toolkit does and creating only four general rules.

The groups would be :

L1: PCI servers and workstations
L2: Support servers and IS workstations
L3: General users and tertiary servers

The four rules sets would be:

L1->L1
L1|L2|L3->L2
L2->L1
L2->L3

I'm thinking that from here I should be able to simply list all services that might be installed and running on a given level to grant access as outlined above.

L1: SQL, IIS, SMB
L2: SQL, IIS, APP1, APP2, etc

Is there any security problem with defining only four rule sets as outlined using these  three levels?

As a former PCI QSA, I would not recommend using the built-in Windows Firewall to segment your card holder environment. The reason being is that this control will only apply to Windows based hosts which are receiving the GPO, in my opinion the control will not provide adequate coverage for the entire card holder environment.

From a coverage standpoint, you are relying on a Windows only control. So unless a separate control is in place to prevent a non Windows computer from obtaining an IP address (e.g., NAC), you could have a OS X or other non Windows device on your network with access to your card holder data.

From a completeness standpoint, you are assuming that every in-scope Windows computer is joined to the domain and will receive the appropriate GPO. So assuming your firewall rules will be limited by individual subnets (e.g., 192.168.1.0/24), there is a chance that a Windows computer NOT receiving the GPO could reside on a subnet that has access to the card holder environment.

My suggestion would be to use a proper firewall with a stateful packet inspection capability to properly segment your network.

Please note: This is my interpretation, another PCI QSA may have a different interpretation of your approach (which is one of the problems of PCI).


how to block ip from head or ping or get or post to webserver (using apache and windows)? am using apache 2.4.9 latest with windows 7 i am using some modules like

limitipconn_module
security2_module

but using wireshark i get unlimited request to busy my webserver (DOS) from some ip address i have deny them and their ip ranges basicly on isp hostname but using proxies would be a new problem and i can not deny all ip address so other clients can not visit my website

is there any method to block only ip address after 50 request per 10 seconds ? i have seen

mod_evasive

but it is not compatible with apache 2.4.9 or any idea for using firewall ?

You could do a policy based QoS, this allows you to perform rate limiting on particular IP addresses based on a particular policy.  This way, you can allow IP addresses to visit your side, but when they perform a particular action (accessing a certain port, accessing a particular URL...), you'll only allow a limited number of sessions.
It will limit the resources your server allocates to them.  It may be a good thing to look at potential "DoS" protection from your ISP, but that depends on yours and their definition of DoS.  This could be just the "noise" of the Internet.
Also, the ApacheHaus has Mod_evasive for Apache 2.4 on windows, this should allow you to put in some rate limiting as well.


What is a reverse WWW shell? I'm having a hard time finding a good definition for a Reverse WWW Shell through regular Google searching.

So far, I've gathered:

  Reverse shell is a technique of establishing a remote connection
  (shell prompt) to a host allowing only outgoing connections.

Am I close?

A reverse shell is a type of shell in which the target machine communicates back to the attacking machine. The attacking machine has a listener port on which it receives the connection, which by using, code or command execution is achieved.

google search link

That being said a reverse shell could be done in many languages.  What your computer science professor is most likely talking about is the ability to upload a file to a web-server and then remotely execute it like a CGI script ... which in turn would give you shell access to the server.

first hit I found on github for php reverse shell
Cheat sheet
of reverse shells in other languages


Can visiting a website virus your computer if you have JavaScript disabled? Let's say I visit a website that could potentially infect my computer by just from visiting it. If I disable JavaScript, is it still possible to infect my computer?
I have already searched the site for this question, but I only find questions like this that don't mention disabling JavaScript

Yes, it is possible.
Javascript is widely used for malware infection, and it's by far the most used way, but it's not the only vector for infection. If you run any vulnerable extension, or the browser uses any outdated library, then a specially crafted element can lead to code execution even without Javascript.


Is it imporant that a cookie should have secure flag set if the website is running on HTTP? I am working on a website and I want to know if a cookie needs to have a secure flag set or not if the website is running on HTTP. Also, httponly flag is set on cookie but there is no secure flag.

From the documentation of Set-Cookie:

  Secure Optional
  A secure cookie will only be sent to the server when a request is made using SSL and the HTTPS protocol. ....
  Note: Insecure sites (http:) can't set cookies with the "secure"
  directive anymore (new in Chrome 52+ and Firefox 52+).

In other words: it makes no sense to set secure on plain HTTP at all since a cookie with such a settings would essentially be ignored.