How to enforce TLS on Windows In Windows 2008 R2 and 2012, how do you enforce TLS-only and how do you demonstrate that posture?

I am in IP Compliance and have a strong background in practical system administration and support. I have however been too far away from windows administration and support for long enough that I don't know the answer to this question any longer and wouldn't know the 2012 analog anyway, and I do not have test systems available for me to poke around in.

So for PCI compliance, all versions of SSL have been deprecated and retired by NIST as strong encryption, which makes TLS the de facto replacement for SSL. Most implementations of SSL default to TLS anyway when possible, but I need to know how to enforce TLS-only.

I have been searching the google, but no matter how I seem to word the question, I get a cloud of "how to enable" type material which I am not at all interested in. In our unix environments it a simple matter (I am a unix head anyway) but how does one enforce TLS only on windows systems. For one, unfortunately I am the leading technical expert at my company whilst not in a technical role, and I'll have to prove this out to our Directory of Infrastructure that this needs to happen (if so), but additionally I must be able to prove our systems are compliant and need a configuration dump or output from a command that shows which ciphers and methods are available for connection attempts.

So, in windows 2008 R2 and 2012, how do you enforce TLS-only and how do you demonstrate that posture?

For Windows operating systems, Microsoft has multiple KB Articles and other references to address SSL/TLS configuration.

Microsoft KB Article 245030, How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll has practically everything you'll need to know. Currently, the KB Article covers operating systems ranging from NT 4 up to Server 2012. The specific operating systems and editions covered within that range appear unusually inconsistent, but this should probably be effective for all Microsoft operating systems within that timeline.

There is also a TechNet article, TLS/SSL Settings which is currently scoped to broadly apply for all editions of Windows from Vista to 8.1, and from Server 2008 to Server 2012. This largely duplicates the details from KB Article, but also includes some Group Policy information and other useful details.

The main thing to be aware of, from the above references, is that there are a number of Registry keys and values within HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL which govern what SSL/TLS cipher suites and protocols will be allowed. Usage and effects of each are generally pretty obvious, assuming that the keys and values actually exist (default installations may omit some). Refer to the KB and TechNet articles for more detail, or Google for information about "SCHANNEL" Registry entries.

However, the above is only effective for applications and services which rely on SCHANNEL for SSL/TLS security. Non-Microsoft programs very often come with their own SSL/TLS implementation which must be configured separately. This is especially true for any applications which provide a web interface that is not served via IIS. In some cases, you will not be able to configure these options yourself, or you may have to "hack" them in without vendor support, for a non-Microsoft program. You'll have to investigate the support options for each application on a case-by-case basis.

Also bear in mind that SSL/TLS is not only used for websites. E-mail, remote access protocols, directory services, and many other applications and services also rely on SSL/TLS for connection security.

For testing the configuration, you will need tools like Wireshark or Fiddler to inspect the SSL/TLS handshake. The handshake will contain information about what cipher suites and protocols are supported by the server and client. Automated vulnerability scanning tools like Nessus, and penetration testing toolkits like Kali Linux, also commonly have utilities to test this. However, they may not be configured out-of-the-box to target all of your specific SSL/TLS-dependant applications or services. Google for usage guides, or post separate questions on an appropriate StackExchange site, as needed.


Why does HTTP Basic authentication encode the username and password with base64? RFC 2617 requires that in HTTP Basic authentication, the username and password must be encoded with base64.

  To receive authorization, the client sends the userid and password,
  separated by a single colon (":") character, within a base64
  encoded string in the credentials.

  basic-credentials = base64-user-pass
  base64-user-pass  = <base64 encoding of user-pass,
                   except not limited to 76 char/line>
  user-pass   = userid ":" password
  userid      = *<TEXT excluding ":">
  password    = *TEXT

  Userids might be case sensitive.

  If the user agent wishes to send the userid "Aladdin" and password
  "open sesame", it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Since base64 encoding offers zero security of the credentials, why is this done?

It is not done for security reasons at all, and more as a means of escaping special characters

https://stackoverflow.com/questions/4070693/why-base64-encryption

TLS would be employed for security.


Is it safe to use a derivative of a password as a salt I know for a fact that salts are an important part of storing a password securely in a database.  Most people store the password hash, and the salt that was used for it.  This, I have learned, isn't as safe as many would think, as a dedicated cracker could use a dictionary attack to find out the password (granted he knew how you were using the salt).

Therefore, I am asking, is it safe to use some sort of transformed version of the password as the salt?  Or is a normal salt going to do the exact same job.

(To be clear, I am not making my own crypto.)

The purpose of the salt is to ensure that two separate users using the same password string will not generate the same password hash.  If you are deterministically defining the salt based on the password, and two users have the same password, then you'll almost certainly be selecting the same salt for both, and will have failed the original purpose of using a salt.

(One can imagine a scheme by which you determine the salt by calculating an index into the password based on the username, which would mean two different users with the same passwords would end up with different salts derived from their passwords.  But, keep reading.)

In addition, my gut tells me that when you're extracting information from the password to use in the more public guise of the salt, you're in danger of leaking information about the password itself.  Any of the more crypto-skilled on this site can probably give chapter and verse if that's a correct gut feel.

The bottom line is really that secrecy is not required for the protection that the salt provides.  It is not intended to supplement poor password quality, only to make two equal passwords result in different hashes, thus making brute force attacks more expensive.  You should consider carefully whether you truly get any security improvement by making it more complex - and I think the answer is no.


Should we change risk appetite when we go on a digital transformation journey? Our organization in the process of implementing several digital transformation initiatives including online/cloud platforms.

There are arguments in our Information Security team regarding 'Risk Appetite' of the organization. Team is divided on this argument:

One side argues going digital means the risks/threats are higher hence there should be no flexibility in the organizational level risk appetite and to continue the same value.

Other side argues going digital means increasing flexibility/efficiency/etc, hence security should not restrict the purpose of going digital. Hence they suggests to increase the risk appetite value.

I'm sure, there are several organizations have gone through this journey already globally. I would like to know how the industry approaches the 'Risk Appetite' when going digital transformation?

Risk Appetite is about how much risk you are willing to take on in order to achieve your mission. Your quotes of the different positions are both talking about only one side of the issue and not actually about Risk Appetite.

"Going digital means increased risk" (a higher likelihood of more and bigger negative impacts). I cannot be sure without more detail, but let's assume so.
"Going digital means increased opportunity". Again, let's assume so.

Great. Neither of these statements is about Risk Appetite.

The question that needs to be asked is if the increased opportunities are worth the increased risk. Will the extra risk impact the company in ways that it cannot or does not want to recover? Will the costs of treating the increased risks be greater than the company can afford? Will the loss of the opportunity negatively affect the company?

Those questions are more in line with Risk Appetite.

And you cannot look at Risk Appetite in isolation to these individual projects and not look at the aggregate risk to the entire company.

So, I find it odd that the Information Security team is trying to assign what the organisation should set as its risk appetite. They are not the correct people to be making this decision. By all means, define and analyse the risks, but I'm not sure that the team is properly placed to assess the opportunities or the more holistic organisational risks in context. That's the job of the business.

As for the "industry approaches" that you ask for, the wiki link you provided gives you the basics:

  Derived correctly the risk appetite is a consequence of a rigorous
  risk management analysis not a precursor. Simple risk management
  techniques deal with the impact of hazardous events, but this ignores
  the possibility of collateral effects of a bad outcome, such as for
  example becoming technically bankrupt. The quantity that can be put at
  risk depends on the cover available should there be a loss, and a
  proper analysis takes this into account. The "appetite" follows
  logically from this analysis. For example an organization should be
  "hungry for risk" if it has more than ample cover compared with its
  competitors and should therefore be able to gain greater returns in
  the market from high risk ventures.

What are the risks?
What are the risk costs?
What are the opportunities?
What are the opportunity costs?
What are the risks, opportunities, and costs in the holistic context?
What are the impacts of doing something vs. doing nothing?
What should our approach be to reducing those risks and pursuing those opportunities?


What happens if you run out of password attempts? In Samsung Knox, you have 20 password attempts. However, it is never explained what happens if you run out of attempts. Does it delete your Knox data, do you need to enter the recovery PIN or is it something else?

This could help: https://support.samsungknox.com/entries/28604817-What-happens-if-I-enter-my-password-incorrectly-

It seems to indicate data stored in the Knox container will be deleted.


Where to start preparing for SOC 2 type 2? We are a small US-based startup with most of the employees working remotely from other countries (less than 10 people in total) and currently are building a SaaS web platform for banks (everything is hosted in AWS). I was tasked with an assignment to investigate what we should do to get SOC 2 type 2 report (one of our clients will probably require it in the future) but quickly found out that the task may be insurmountable for me (I'm just an ops guy and have no experience with certification, compliance and such). I read "Trust Services Criteria" pdf from AICPA website, watched a bunch of youtube videos and spend a few days googling but still at loss.

Currently, we have no real controls in place because the company is so small, we just create tickets in trello, develop a feature and deploy the new code using only common sense without any written procedures, guidelines and rules. I'm not sure where to start and how all the controls should be designed to satisfy an auditor. It feels like I have to write a whole book from scratch without really knowing the subject. If there were at least some sort of documentation templates about how to organize everything I could at least try to adapt that to our case but I wasn't able to find anything like that.

How do one start preparing for SOC 2 completely from scratch? Maybe there are companies that can help with that (not with the audit itself because there is nothing to audit right now but with writing controls specifically)? Any help will be very appreciated. Sorry if the question is too broad but I really have no idea how to get more specific in my situation.

A requirement is that you get an assessor to evaluate your controls. You actually want to start with that step and get their guidance on how to start because they and you will need to agree on scope and what control set will be relevant.

The reason why you are not getting good guidance from the Internet is because your task is exactly like writing a book and not like passing an exam. Your assessor will help you figure out what you are supposed to be writing and how long your book is supposed to be.


What prevents malicious servers from spoofing mail transfer agents and/or mail delivery agents? An email system typically consists of multiple agents:

Mail user agent (MUA)
Mail submission agent (MSA)
Mail tranfer agent (MTA)
Mail delivery agent (MDA)

Evidently the 'middlemen' of this system are a spoofing risk.
(Technically the endpoints could also be a spoof risk, but let's assume in this case that the end users are genuine.)

What methods are used/can be used to protect against these 'middlemen' agents being spoofed?

I've thought about it myself and the only answer I can come up with is that DNS might provide some sort of limited authentication, though DNS spoofing would still be a risk.

(Image is CC BY-SA 3.0, © Ale2006-from-en.)

Delivery from the MUA is usually done to the domain specific mail provider (MSA in your image). This communication is typically done either inside a companies protected network or to some external mail provider. Mail delivery inside the local network is usually  protected against DNS spoofing as long as it can be assumed that there is no attacker inside the local network or that he will not make itself easily visible with DNS spoofing. When using an external mail provider the connection is usually protected by TLS. TLS will protect against DNS spoofing and other traffic rerouting since the MUA will check the subject of the certificate and that it was issued by a trusted CA etc. TLS will also protect against sniffing and modifying the traffic even if the attacker manages to get in the path of mail delivery.

As for MTA/MSA to MTA/MDA communication: this happens on networks where DNS spoofing is not easy too, i.e. this is not on some public hotspot where an attacker could easily inject himself. Additionally DNSSec might be used although lots (if not most) DNS MX/A/AAAA records are currently not protected by DNSSec. But using DNS spoofing to target a specific mail is impossible due to all the caching of DNS. Using it to target all mails to a specific domain is hard too since these might come from various sources which means DNS spoofing might need to be done in various places which might make the attack too visible. The same is true for other ways to reroute the traffic, like BGP hijacking. If the attacker still manages to actively get in the path of the mail delivery though he can likely sniff and modify the traffic since usually there is no TLS enforced between MTA or that the MTA don't properly check the certificates.

None of this actually makes attacks really impossible, it only makes it less likely in most cases. Well-equipped attackers (like governments) will likely be able to mount attacks especially against less protected domains. They might not necessarily attack delivery between MTA/MSA/MDA though since such attacks are more visible to others. Instead they might do a more targeted and less visible attack directly against the victims MDA or the victims mailboxes. The latter is often done using phishing mails to get the users mail account credentials or by delivering malware to attack the victims computer and thus get access to the mails too.


Time-limited encryption Is it possible to set up an encryption scheme where the decryption key can only be used up to a certain date? i.e. past the certain date the data can no longer be decrypted. We can assume there is a reliable/mutually-agreed upon time reference.

There is no way to cryptographically guarantee that a key will be useless after a certain period of time. The most you can do is digitally sign an expiration date, telling any potential decryption utilities to first verify the date before decryption. The utilities will then be in charge of either reporting the fact of the expiration, or refusing to perform any futher actions. As mentioned in a comment, the x509 format provides that ability, and compliant utilities will (or at least should) check the expiration date.

The reason for this is simple. If you have C = Enck(P) and P = Deck(C), where P is plaintext, C is ciphertext, and k is a secret key, it is logically impossible for the passage of time to change the behavior of a functional algorithm such that P ≠ Deck(C). You can of course have both parties agree to "forget" either k or C via mutually-agreed upon policies as other answers have described in more detail, but no matter how much time elapses, given C and k, you can always calculate P.


Digital preservation: cryptography for long-term archiving What would be a safer bet/standard choice for encrypted archived data?

Presently I use a dmcrypt + LUKS container for my sensitive data. For some stuff (like music mp3s), it would not matter if someone accesses them. But regarding private emails, financial statements and even family pictures I prefer when they remain private.

I worry that, if I store and forget the data, it would not be possible to open the container any more at some point in  time (5-10 years). Another issue is whether the whole container could be damaged by a couple of flipped bits here and there.

How do things like LUKS actually last?

It is safe to store encrypted data for 5-10 years, but not all drives last that long.

  I worry that, if I store and forget the data, it would not be possible to open the container any more at some point in time (5-10 years).

There is no reason why the encryption itself would fail to work after 5 or 10 years. As long as you remember the password and the drive is still working, you will be able to decrypt it. The algorithms that are used have a very long life. Even old algorithms like DES from more than 10 years ago are very easy to use. Simply put, encryption algorithms do not care at all about the current date.

Think about it this way: A 10 year old hard drive with a SAS interface (2004) encrypted with AES (2001) and formatted with the NTFS v3.1 filesystem (2001) would not only be trivial to access on modern hardware, it would not even be out of place to see today! Even a 20 year old hard drive with a PATA interface (1986) encrypted with 3DES (1998) and formatted with the FAT32 filesystem (1996) could be easily accessed today, in 2018. And you're worried about only 5 to 10 years?

However, I need to point out that 10 years is a long time for a hard drive. Even if you are keeping redundant backups (e.g. by using RAID 1), you are risking the hard drive itself dying from old age. Encryption will not prevent the drive it is stored on from dying. If you do need long-term archival, there are plenty of resources online to learn how to properly store data for decades.

  Another issue is whether the whole container could be damaged by a couple of flipped bits here and there.

That depends on which bits are flipped. All block ciphers (such as AES) require a mode of operation to work properly. Modern LUKS setups typically use a mode called XTS. Being a narrow block mode, a single bitflip will always corrupt 16 bytes (128 bits) of data. This may be enough to cause corruption in the underlying filesystem, but a corrupt filesystem can almost always be fixed, usually using automated repair tools. It is important to realize, though, that it is more likely for an entire sector (usually 512 or 4096 bytes on modern hard disk drives) to fail. It is fairly uncommon for only a single bit to be flipped, but not uncommon for a sector to "go bad" all at once. The hard drive will make a best effort to recover the sector's contents and copy them to a fresh sector, but it can only do so much. If it is unable to recover the sector, it is marked as damaged and is lost.

LUKS also contains a feature called "anti-forensic key splitting" (see page 10 of this document). This is a cluster of data spanning typically 250 KiB and contained in the 2 MiB header. If a single bit is corrupted in that region, the entire volume can be lost*. Its purpose is to make it easier to erase data quickly in the case that erased data can be only partially recovered, but it also increases the risk of accidental data loss. Unfortunately, this feature cannot be disabled in the current version of LUKS. Unless the header itself is damaged, the rest of the volume should remain intact.

Because this feature cannot be changed when using LUKS, it may be better to use different disk encryption software. VeraCrypt takes the opposite approach of LUKS, not only making its header as compact as possible, but keeping a copy of the header just in case the primary header is damaged. Linux fully supports VeraCrypt when a modern copy of cryptsetup is used. It does not require any extra software and even uses dm-crypt as a backend, just like LUKS.

  How do things like LUKS actually last?

I would only start worrying when the data approaches half a century of age. At that point, you run a high risk of not having access to any hardware which is capable of interfacing with your storage device or executing the LUKS software. After that much time, it's possible that even the LUKS specification will be lost, making it necessary to reverse engineer the format. If you are only storing data for 5 to 10 years, you do not have to worry about that kind of thing at all. I have storage drives with data that old and have never had any problem. The only thing you need to worry about is your storage medium failing due to age, which you can deal with by keeping redundant backups.

Overall, there are three things you need to keep in mind when archiving data that long:

Algorithm support. Encryption algorithms that are well known will continue to be supported for a very, very long time. There is no reason to worry about an algorithm like AES becoming ancient history after a mere 5 to 10 years. In fact, it will likely still be the most popular!
Storage medium compatibility. Over time, interfaces for storage devices become obsolete and the hardware required to interface with them becomes harder to find. This starts to become an issue as the age of the medium begins to be measured in decades. Even with this issue, for a popular interface (like SATA), chances are you will find plenty of retrocomputing fans who will know how to access data on even the oldest of devices.
Storage medium health. One thing you cannot prevent is the progression of time slowly damaging hardware. While some types of media last longer than others, everything will break down. I would be very uncomfortable keeping extremely important data on a hard disk drive or a solid state drive, but I would not feel too worried keeping it on an archival DVD. It's important to periodically test your backups to make sure the hardware still works.

To reduce the risk of loss of data loss when archiving, you should follow the 3-2-1 rule. This rule states that you should have at least three separate copies of your data, of which two should be kept on different types of media, and one copy should be kept at a remote location. The specific kind of media you will want to use depends on multiple factors. In general, you should know that:

High-capacity tape drives last for a long time, but require expensive hardware.
Archival DVDs† last a long time, but have a low storage capacity.
Archival hard drives don't last as long as some solutions, but have a high capacity.
Solid state drives begin to lose data in the span of years to decades.

* While a single corrupt bit in the header can corrupt the entire volume, it is still possible to recover it by using a brute force attack. If more than a single bit is corrupted, the chances of recovery become significantly lower. If an entire 512 byte sector is lost, which is the normal failure mode of modern hard drives, there will be absolutely no way to recover the encrypted data if that sector was part of the LUKS header itself.

† There is a lot of misinformation about archival DVDs out there, in part because "archival" is not a formal term and anyone can slap that label on their products. If you buy one, do your research first! Otherwise you may find yourself buying a sub-par product. In particular, be skeptical when "gold discs" are mentioned.


Billion Laughs Attack (XXE) - how does it work Hi all Im trying to understand how the billion laughs attack works(https://en.wikipedia.org/wiki/Billion_laughs_attack)

So far I get its obviously sending this payload:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

I get that it is an xml declaration has 10 entities that sort of self replicate like: &lol9; is a defined entity that means it translates to 10 &lol8; .

Is the whole point of this attack that each &lol# is a defined entity morphing to 10 other ones, and thus resulting in DOS attack?

Please advise. Thanks

To clarify DarkMatter's answer, it more specifically targets a programming construct called recursion.

The XML document tells itself to recursively include the entity before it. Thus infinitely looping while allocated data for the element it's referring to in the XML. This is what recursion looks like:

When the XML interpreter reads the XML, it doesn't ever get told to stop, which causes the CPU resources to become totally drained, RAM becomes full, and either the software or the operating system will crash depending on which level the XML is being interpreted at.

Edit: another interesting way to think about recursion is to visualize looking through a mirror at another mirror. They reflect eachother infinitely, that's what is happening with the data. See below for cool pic:


Using unencrypted parts of encrypted file to recover password (7zip) I have forgotten the password for an encrypted 7zip file (the filenames are not hidden), and I have copies of some of the unencrypted files. Is there a way I can use this to find out what the password is by using these copies?

It feels like there should be a way of using the knowledge of what some of the files look like unencrypted, to find out the password in a faster way than just trying to brute force it.
However, I don't know anything about how 7zip encrypts files.

Is there any program that can do this?
If not, and you know about encryption: Is it possible to write such a program?

You're looking for a known-plaintext attack. Usually (e.g. you're up against a high-quality algorithm), this is hopeless.

For example, there are some known-plaintext attacks on AES which are slightly faster than brute-forcing the key. However, this is pointless because you'd still wait gazillions of years before you identified the key.

Older ZIP versions, however, are known for notoriously weak encryption. So it might be that the encryption algorithm used to encrypt your zip is vulnerable. You'd need to find out which algorithm was used exactly in order to get a meaningful answer.


Server providing two different SSL certificates When I check on browser for a site example.com, I see that site has a valid certificate, not expired, with validity till end of 2016.

At the same time, When I scan for the same domain on the port 443 using a Python script which I have developed, I get example.com certificate as expired and different from the non-expired certificate.

Why do domains serve two different certificates?

My guess is that this site is using Server Name Indication (SNI). In this case the served certificates depends on the hostname specified in the SNI extension and will often differ if no SNI extension is used. I.e. it will be some completely different default certificate or it will be some old certificate because they only replaced the certificate used for SNI when renewing the certificate.

Modern browsers all use SNI for years while outside the browsers the support is mixed. Support for SNI was added to Python with version 2.7.9 in 12/2014. It might be that you are running an older version of Python or that you are using a lower level access to the SSL connection where you have to explicitly set the SNI extension yourself.

In theory one could also send different certificates depending on the capabilities of the client, i.e. certificates signed with SHA-256 for a TLS 1.2 client but a SHA-1 certificate for a TLS 1.0 client. In practice most TLS stacks don't offer this kind of behavior or make it hard to use and thus servers don't implement such a feature. Thus I guess that your problem is related to SNI.


How to stop USB Rubber Ducky? I want to protect my computer from fake USB keyboards like the
USB rubber ducky .

I tried Penteract's disguised keyboard detector.
I connected a keyboard and it locked the screen.

But I don't know if it will lock the screen before USB Rubber Ducky starts working. I don't want to buy a rubber ducky to check this.

How can I further test the keyboard detector, if I don't have access to the USB Rubber Ducky myself?

If the user account you are using is not in the Administrator group, it will make it harder for a Rubber Ducky to operate.
The weakness of the Rubber Ducky is running pre created scripts (payloads), and most of them are meant to accounts that like most Windows PCs are in the Administrator group. In a limited account, you will need to enter the Administrator credentials to do certain actions (i.e. change a Registry value) or run certain programs and without these credentials, the Rubber Ducky won’t be able to proceed.


Should I install an SSL certificate for a website that uses a third party payment gateway? I understand what an SSL certificate does but I need help evaluating if I need one for my client's website.

His website sells holiday packages online but does so without asking for any credit card information. When the visitor tries to book a package, he is sent to a bank's third party gateway where he submits his information and then returns to the website once the payment is complete.

In this scenario, are there any compelling reasons to install an SSL certificate, other than reasons of protecting the brand, and providing a safe atmosphere for visitors to shop?

I'm going to interpret this questions as "should SSL be enabled on this client's web server or not?" Regardless of credit card information it is still going to be collecting personal data on the client's customers, and therefore SSL should be enabled. Besides protecting the brand and providing a safe site to shop:

It will help protect the client from liability
It may be required by laws or regulations depending on where the site is hosted, or the clients it serves
It's easier and cheaper to prevent data breaches than clean them up later


Why append an nop sled at the end of the shellcode? I was trying to exploit a buffer overflow in the following manner:

  NOP sled -> shellcode -> address of NOP sled (before it was save RIP)

But, I was told on Stack Overflow that I should also append a NOP sled to my shellcode:

  NOP sled -> shellcode ->address of NOP sled -> NOP sled.

Can anyone explain to me why should I append a NOP sled to my shellcode?

This is my original post on Stack Overflow:

https://stackoverflow.com/questions/38416045/im-trying-to-exploit-a-bufferoverflow-am-i-doing-something-wrong?noredirect=1#comment64836134_38416045

Thanks.

EDIT: I read another post in which someone had the same problem.

He fixed this by adding a small NOP sled after the shellcode. Since the shellcode was added to the stack at the end of the buffer, and it pushes some things to the stack itself, it was overwriting its own code.

But I don't understand how a push instruction can make the shellcode overwrite its own code.

There are two reasons for this as far as I know

The buffer overflow length might need to be a very specific number and your shell code might not take up the entire buffer. For instance if your buffer has to be exactly  400 bytes but your shellcode is only 312 then you'd insert 88 bytes worth of nops to ensure the correct length.
Shellcode can require a bit of room to "expand itself". You can typically get away with only adding a few extra nops to the end of the buffer but I've always been taught that the shellcode should have some padding at the end for successful execution.


Benefits of identifying clients based upon the "X-Forwarded-For" or similar HTTP header in addition to Client IP The X-Forwarded-For header is used by some HTTP proxies to identify the IP address of the client. The wiki page (linked above) mentions that ISPs may use this header as well.

In addition there are a variety additional headers that may be used to identify a client.  Some examples include:

HTTP_CLIENT_IP
HTTP_X_FORWARDED_FOR can be comma delimited list of IPs
HTTP_X_FORWARDED
HTTP_X_CLUSTER_CLIENT_IP
HTTP_FORWARDED_FOR
HTTP_FORWARDED

  Can I use any of these headers to for access control, to block or allow access my site?
  e.g. Block in an escalating manner: HTTP_Header_X first then, client IP?
  What are the known usages of these headers?
  e.g. ISPs, proxy software like Squid, etc.

I was then considering that some web servers may dynamically alter their response based on the presence (or lack of) these header.  Suppose a server banned users by IP address.  Should it ban a user based upon the received IP or the one specified in this header? I then considered the possibility of spoofing this header as a way to work around an IP-ban that the server may have imposed.

  What security concerns may exist around these headers, what is the appropriate way to address it?
  e.g. include that is relevant for logging, etc.

Any of those HTTP headers can be used for access-control purposes, however I would not rely on either the presence of those headers, or the validity of their data.

The most I would ever use them for is logging.  There are no guarantees that any of those headers will be present, or even if they are, that they will contain valid data.  I know there are X-Forwarded-For spoof plugins for Firefox, and probably for other browsers, too.  This makes the information useful only at a statistical level - trending, pattern analysis, etc, there can definitely be some value in collecting and logging those headers. Just don't do any thing that relies on them

Any sort of reliance on HTTP headers for any kind of authentication or access control would have to be classified as worst-practice behavior.

There are much better ways to control access and authentication.


How To Secure a Computer Stick that Runs a TV I purchased an Intel compute stick to turn a TV into a display.

I have it set up so that I can VNC into the computer to change what shows up (Open windows, show movies, etc...). It works great in this fashion, however my concern now is securing it.

It is currently plugged into the back of a TV. At this point anyone could plug in a USB mouse/cable and they would have control over it. I cannot lock the computer because I want the desktop to be the display (not a lock screen).

Some ideas I've had

Require admin password when plugging in a USB device

I don't know if this is even possible. Google hasn't helped.

Physically box up the device

I couldn't find anything on the market and the low profile nature of the device means a box would push the TV away from the wall.

Run it as a user with only the necessary privileges

Maybe this is the best option?

What would be the best way to secure this computer?

The best option IMO is to physically secure the box. That can take the form of locking the whole box up, or any of the options that lock USB ports.


FileVault and Sleeping mode I have FileVault activated on 10.10. (Mid 2012 MacBook Pro - MPB)
I relaized already that there are different sleep modes.
autopoweroff and normal Standby. Whenever the MBP goes into Hypernate mode, I have to type in my FileVault password. Whenever it goes to normal Standby, it only have to type in my Account password.

I changed the settings that my MBP hardly goes into autopoweroff mode - only after a long time. Does that mean that when my MBP is in standbymode, its not protected by FileVault?!

If you have FileVault encryption enabled on your Mac and your system goes into standby mode, it will save the FileVault encryption keys in the memory so the system can be quickly woken and resume work without needing to unlock the volume again. This feature is convenient, but some people may wish to prevent it from happening in order to ensure maximum security for their systems.

To prevent the system from storing the keys, you need to change a small setting in the system management controller (SMC), which can be done by running the following command in the OS X Terminal program:

sudo pmset -a destroyfvkeyonstandby 1

When you run this command, you will need to supply your password (it will not show), and then restart your computer and the system will no longer store the FileVault keys when it goes into standby mode.

Keep in mind that doing this will require you to enter your FileVault password again when you wake your system from standby mode, but will prevent someone from potentially getting to your hard drive's data if you leave your system in this mode without fully shutting it down.

To undo this setting, simply repeat the command but use a 0 instead of a 1 as the value.

Source: Prevent OS X FileVault keys from being stored in standby mode


How to analyze why Chrome downloaded a particular file? I had a very few Chrome tabs open (see appendix) and other safe websites. Suddenly, without any prompt or action from me, chrome starts downloading the file "NEW!_iPhone7_LEAKED_PHOTO.JPG.exe" which looks very much like a malware. The file gets saved into my download folder without any action on my side.

I have Windows 8.1 with Windows Defender running. I ran a custom scan on the file using my Windows Defender and it's clean, and also ran it by virustotal]1 which confirms it's clean. (Still it could be a zeroday exploit).

My question is how do I analyze how and why chrome decided to download this file?

In case it's relevant, here is the list of tabs I had open: Gmail, Google Spreadsheets, my gas company, this shopping website, and the world population.

Unless you had the foresight to enable performance measurements on your system, its not possible. as for the tabs open. its possible to have chrome download a file directly from command-line (so any program on your system could have done this, not just your open tabs). also a webpage might have had an "injection" either in-between you and its server. or on the server, or on your machine. you should check your extensions, and inspect what software is actually running on your machine (is there any mal-/crap-/spy- ware present. very your result with more than 1 scanner. and USE COMMON SENSE.


Will CA's still validate internal IP's in SSL certs? Just wondering what Certificate Authority (CA) policy is nowadays on validating someone's internal IP address in a certificate? I have heard that some CA's used to do this but won't anymore.

For public IP it must be checked that the IP is actually owned by the one who requests the certificate. Issuing certificates for private (reserved) IP is deprecated because obviously the ownership cannot be checked.

For more information see CA baseline requirements Sect 9.2.1.


Is Git crowdsourcing cryptographic attacks? A strong cryptographic hash makes collisions unlikely. Many cryptographic protocols build on that fact. But Git is using SHA-1 hashes as object identifiers. So there are a lot of already computed hashes out there in the public Git repositories of the web, along with details on how to reproduce them.

Is there some known attack on some protocol where this might be leveraged? Something like “well, I can do something evil if I replace this unknown plain text with some other plain text with the same SHA-1 hash, so instead of computing a collision I'll google for it.” Of course, the space of all hashes is still far from covered by Git commits, but nevertheless, I'd guess all the Git commits out there might amount to quite some CPU hours of computing SHA-1 hashes. I'm not sure whether that guess is justified, though.

As far as I can see, such an attack would only work if the hash is visible, the plain text from which it was generated is not, but some cypher text generated from is, and a different text can be encrypted as well. So this looks like it might apply to some public key based protocols, where you can encrypt but not decrypt. Furthermore, you don't have control over the colliding plain text, so obvious things like putting your own name as the beneficiary of some financial transaction won't work. Are there any scenarios where such a crowd-sourced hash collision could cause serious trouble with non-negligible probability?

Is Git crowdsourcing the production of SHA-1 preimages?  Not to any meaningful degree.

Github doesn't say how many commits it's tracking, but it's probably not more than a few billion.  For comparison, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible SHA-1 hashes, so the odds of finding a plaintext matching an arbitrary hash of interest are effectively non-existent.


Loginless Client/Server Architecture (iOS) I'm currently in the phase of planing a project involving loginless service.

Users would be identified by an unique device id created on the client (ios).

What are the security concerns?

sockets would be wrapped with ssl
create a private certificate to verify client? (what about someone decompiling the binary and obtaining it?)

any thoughts are appreciated

If you can store a device ID on the client, then you can use that as both "username" and "password": within the SSL tunnel, the client sends the device ID, which the server looks up in the database. If the device ID is found, voilà! the client is authenticated. Remember that "a client is authenticated" has the same meaning as "no other entity than the client himself could have said that". As long as the "device ID" is client-specific, secret, and unguessable, it is a proper basis for authentication.

Of course, a customer who extracts the data contents of his device and reverse engineers the code will find his own device ID, and will be able to access the server from other computers. That's unavoidable. You cannot enforce usage of a specific client device unless the client device contains a tamper-resistant element (e.g. a TPM), and, apparently, iPhones do not. Certificates or other cryptographic gizmos won't help you there.


Are certificate authorities required to obey to the signature algorithm (hashing) specified in the CSR? I was playing a little bit with signature algorithms, trying to determine which CAs among the ones I use are currently issuing SHA2 certificates.

I generated a CSR specifying the SHA256 hash (either using gnutls-certtool with the hash param and openssl req with the -sha256 param) and the CSR is clearly displaying sha256WithRSAEncryption as the signature algorithm.

$ openssl req -noout -text -in test.csr

Certificate Request:
    ...
    Signature Algorithm: sha256WithRSAEncryption
        ...

However, the resulted certificate from the CA is hashed with sha1WithRSAEncryption.

$ openssl x509 -noout -text -in test.crt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ... (...)
        Signature Algorithm: sha1WithRSAEncryption

Of course, generating a CSR with --hash SHA1 (sha1WithRSAEncryption hash) will cause the resulting certificate to use sha1WithRSAEncryption (as expected).

The CA states that the hash should be specified as part of the order, not of the CSR (which is something I can't do in any case given I'm submitting the order via a third party service).

Hence the question. Should the CA obey to the hash algorithm specified in the CSR?

The signature algorithm specified when creating the CSR corresponds to the message digest used to sign the request itself, it is not intented to ask the CA to prefer that algorithm when signing your certificate.

The MD used in the CSR establishes the level of confidence in your request, but does not imply what algorithm is used on the certificate since signing does not depend on that digest but on the public key.

Most CA stick to the same algorithm for a specific issuing certificate unless it were discovered to be "weak", ignoring what message digest you used in your request.

A good CA would reject any CSR signed with MD5 (for precaution since they shouldn't trust you), and should be forcing you to use SHA256 for any certificate you pretend to use for more than two years starting today (2014), since Microsoft (and maybe others) will be rejecting certificates signed with SHA-1 or lower on January 2017.


Is there a backdoor in the hardware of our smartphones? I don't know for you but I always felt like Android especially is not safe. Is somebody - the government or other - able to listen to my microphone, or access my hard drive remotely ?

I'm wondering if secured apps like Textsecure and Redphone really help or are just an illusion. Indeed it is pointless to secure the transport if the source and the destination are corrupted with a security hole at the hardware level.

Can the monitoring of our network really tell us if we are spied ? The data sent to government agencies could be excluded by the author of the network monitoring app.

Also, at the software level, can we really assume that Android is safer since it is - supposed to be - open-source ?

Well lot of questions, but I'm trying to find a middle ground between concern and paranoia.

I don't know for you but I always felt like Android especially is not safe. Is somebody - the government or other - able to listen to my microphone, or access my hard drive remotely?

Why do you think Android might be especially vulnerable? I expect the NSA has the tools to snoop in on practically anything connected to the Internet.

  I'm wondering if secured apps like Textsecure and Redphone really help or are just an illusion. Indeed it is pointless to secure the transport if the source and the destination are corrupted with a security hole at the hardware level.

Indeed, but it sounds pretty expensive to built a security hole at the hardware level when a software one will work admirably.

  Can the monitoring of our network really tell us if we are spied ? The data sent to government agencies could be excluded by the author of the network monitoring app.

Most likely, such data would not reach the network monitoring app at all. After all, all a network monitoring app does is use a public API to sniff the data; it doesn't have a direct link to the fabric of the universe, right? The way to check would be with a passive cell signal receiver ... and you'd have to transfer the encryption keys used by the phone to it in real time; massively complicated stuff. But it'd be relatively easy to spot "extraneous" packets included in that capture but excluded by a network monitoring app.

  Also, at the software level, can we really assume that Android is safer since it is - supposed to be - open-source ?

Not unless you obtain a copy of the source, the whole source, and nothing but the source, and compile and flash it from a toolchain known not be compromised. And even then only if you trust that vulnerabilities in "open-source" software are rapidly found. Historically, this hasn't been the case. Consider how long the heartbleed vulnerability was around before it was found, and the underlying bug wasn't even hard to spot.

  Well lot of questions, but I'm trying to find a middle ground between concern and paranoia.

The simple thing to do here is just don't do anything that might raise flags for the NSA. They really don't care about your communication with your girlfriend(s).


ByPass usb GPO with iphone -and probably other mobile- So I am running pentest on a device running Win7 and admin user set group policy to disable all mass storage devices and all usb's.

I have access to local user without privs.

Although my usb stick wont work and group policy rules wont let me my USB flash, USB modem or anything but my iPhone works as a USB storage device somehow (it is not jailbroken thus I can only reach to photos but still it works). I am only allowed to plug in usb keyboard and mouse actually (and yes rubberducky has been tried)

So I have two questions,

Do you have any idea why this happens? How can I exploit this more? What is the solution/work around?
Can I use this to bypass all the group policies?
Lazy question alert Does anyone know any detailed info (aka how to exploit) about cve2014-1812?

PS: I am not sure if this is off-topic, I struggled to decide and maybe a little off topic my question is (Yoda v0.1 here) but I am not the admin of the system, but pentester so I posted here due to my point of view...

It's most likely connecting as a Media Device or Camera. There's a seperate GPO for each type of removable media. Perhaps this particular policy only enforces against flash drives.

This is quite common on androids.. I can switch my device to be a Camera and bypass our GPO for blocking removable devices.


Is exposing the psk in /etc/network/interfaces a security risk? I have an application that generates the /etc/network/interfaces file for connecting to the users wifi network.  This application uses wpa_passphrase to generate the psk, which is then copied into the interfaces file.

is exposing the psk in /etc/network/interfaces a security risk?

For example: (the passphrase in this case is asdfASDF123)

auto wlan0
iface wlan0 inet dhcp
wpa-ssid homeWifi
wpa-psk f4a4c36b738fd7340d0959e307dd76f05a9c5da5801a5f1ba08a5b2fafdfc067

Yes, but as always there is a trade-off between security and convenience. If you don't want the user to have to type the passphrase every time, then you have to store the PSK on the machine somewhere.


What are some cards that are vulnerable to RFID theft? I heard that some credit cards are vulnerable to RFID scanning and thus identity theft. I am concerned about my cards and I would like to learn which cards are vulnerable to such abuse? Are any of these vulnerable too: personal id cards, driving licenses, etc? I see that these might vary in different countries so how do I indentify if a card uses technologies that might be abused liked that?

which cards are vulnerable to such abuse?

First of all you need to recognize whether the card has RFID capabilities or not. These may be advertised with logos, icons (usually the three curved lines also used to indicate "WiFi" in some contexts), or in writing. You can also check on the supplying bank/company/entity, or look for telltales such as "My card does not work..." in the FAQs or forums. Also the issuer's support hotline, if available, should be tried first.

Another possibility is to inspect the card itself (some RFID antennas are visible by placing the card in front of a very strong point light, such as some hi-power LED torches; you can try and see if a RFID reader beeps, even if it does not recognize the card, or better yet, if a recognized RFID card has suddenly problems if waved in front of its reader while being pressed against the unknown card. Normal plastic and chip cards do not interfere with RFID cards; RFID cards, of course, do). If you have an expired card of the same issuer, you can try cutting the old card apart, and if it has a RFID coil inside, chances are that the new issue is RFID too.

Now that you know it's RFID, what information/operation is needed to complete a transaction or get the information on the card? A few RFID credit cards require a PIN to be entered manually (which somewhat negates the ease of use of a RFID...), for example.

If the only thing needed to get something you wouldn't want gotten from the RFID is to skim it with a reader - your knowledge or confirmation aren't required - then by definition that card is vulnerable.

  How do I prevent RFID scanning? Would a wallet with aluminium plates on both sides do the job?

There is a common misconception about "shielding" RFID. Passive RFIDs don't have a power source, so they get it from the incoming scanner field through inductive coupling. The shielding works both by limiting the energy transfer (so the RFID doesn't "wake up") and by decreasing the signal-to-noise communications ratio (so the RFID and the scanner don't "understand" each other).

The absorption of the shielding depends, for any given material, on the frequency being used; for smart cards we want good absorption in the 13-14 MHz range.

Different materials - even metals - have different shielding properties at different frequencies; for example, aluminum won't stop low frequencies (or stationary magnetic fields: a magnet will still work even if wrapped in aluminum foil). Steel sheet or soft iron sheet will screen low frequencies and absorb much of the magnetic component, but will leak at very high frequencies.

So, while an aluminum foil will create a Faraday cage stopping dead most high-frequency RF, microwaves, etc., it may not be enough to screen an inductively coupled RFID smart card from a juiced-up, savvy scanner. A single layer of aluminum foil will not stop any except the cheapest, more shoddily constructed readers. Of course, more layers will increase protection.

You would perhaps be better off with jamming -- using a shield made of a valueless (e.g. expired), but still working, smart card of the same make and model. Or "sandwiching" the real card between two valueless ones. Not only will the middle card receive less power, but the outgoing signal will be mixed with two others on the same frequency (activation delay makes this method not completely safe,  though).

Otherwise, you can use 30-mil magnetic iron foil (looks very much like aluminum), or have the wallet lined with Near-Field Cobaltex which is almost as good and weighs less.

For the truly paranoid, apart from several layers of Cobaltex, there are metamaterial shieldings (e.g. silvered-nickel-iron or nickel-cobalt-copper mesh from several suppliers, from Achron to Laird Technologies) which are significantly more expensive but have even more stopping power. And you don't need a lot of material to line a wallet after all.

You can then test the effectiveness of the shielding by using a shielded credit card to try and pay at the next gas station. If it doesn't work, you smile happily, take the card out of the wallet and tell the gas guy "Sorry, it usually works even from inside the wallet". If a reader at one inch can't interface, it's unlikely that a pirate reader will be able to do it from much farther.

It would also be interesting to build a coil tuned to 14 MHz and connect it to a rectifier, buffer capacitor and buzzer stage. It would suck most of the energy from the scanner field, converting it into an audible sound and giving the alert. Basically the same thing as a near field probe, except it could be completely passive: it takes quite a lot of energy to run a blind skim a RFID at a distance, so the scanners are probably heavily up-juiced and give off radiation enough to be detectable. (It would also possible to build an active scanner detector by tweaking this design).


How do I protect my passwords from WebBrowserPassView? I just got shocked with what can be achieved with WebBrowserPassView. It basically shows every password I've saved in my browser (Chrome).

I guess other users on my PC could get my passwords that easy too. How do I secure my passwords?

You're really asking the wrong question here
Really what you should be asking is:

Should I be worried that I can use tools to look at passwords stored in my Chrome browser?

And the answer to that is... Kind of. Really the best way to prevent that from happening is to keep your systems hardened. If someone gets access to that data, you've already lost everything. That's because at that point they have gained access to your OS/Computer as a whole and can do whatever they want. They have access to your browser, which means they can hijack your sessions easily, and do any damage they want all without ever having to sign you out of that session. This is true of any open sessions you have on your browser at the time, regardless of whatever password manager you use.
Why?
Because Chrome already stores your passwords in the encrypted user area of your disk.
Really using a master password as an encryption versus the already encrypted areas of your OS is nothing more than security theater. If they get that sort of access to your machine where they can get that file anyways, it's game over man. They have full control over your entire system.
How do I prevent this from happening?
By keeping your computer safe and secure. Don't lend access to it to people you don't trust, don't leave it unlocked, don't use a weak password, and don't just leave it unlocked when you walk away. Did I mention don't leave it unlocked if you aren't using it?
A great post on it from Justin Schuh:

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.
Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.
We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.


Looking For Compiled Version of Metasploit Local Windows Exploits I am looking to have a standalone compiled exploits for all local windows exploits that Metasploit has right now. I was wondering if somebody has done this before or know a place that has these exploits as an executables that are ready to execute on the vulnerable system.

Here is a list of the exploits that I am looking for:
https://github.com/rapid7/metasploit-framework/tree/master/modules/exploits/windows/local

I don't think you are going to find any.

The information such as the target, payload, etc I believe is compiled into executables which Metasploit serves up.

A precompiled binary would be useless for all practical purposes, besides maybe malware detection. Even then there are options for packers in Metasploit.


Anomaly-based Malware Detection in Web Applications I am partly responsible for the security and malware detection (in general) of a huge number of hosting accounts. Our methods rely heavily on signature-based detection provided by ClamAV for which we have also created a pretty decent signature database ourselves (500+ samples).

We receive up to 30-40 notifications on a daily basis for malicious code being spotted in a user's account. As time flows, hackers get more intuitive and always manage to keep up with our (whitehat community as a whole) progress as we attempt to cease their attempts of exploiting vulnerabilities. However, it appears that signature-based detection of malicious code is increasingly becoming insufficient - we keep finding new malware samples that our scan has failed to detect initially. Therefore I took the liberty to attempt and design a system for strict anomaly detection.

I am asking for advice whether my current plannings can be considered reasonable since this is my first time taking up on such a task.

I think the more conditions I check the file against, the better results I can get (eliminating false positives as much as possible). So far I have created the following list of conditions:

file location (5%)
filename (10%)
code tidiness/alignment (5%)
repeating patterns (5%)
weird/non-logical names of data structures (10%)
stacking of multiple functions (3%)
error reporting disabled (5%)
error suppression used (2%)
contains hex (i.e. \x73) (3%)

Where each of the conditions gives the file a certain percentage of it being potentially malicious or has malicious content within. My questions are:

Is this a good/right approach to developing a strict anomaly-based detection system? If not, why?
Can you give me example(s) of what else I can check a file against? Any tips or any useful information?

Do consider that:

It is targeted at web applications and mostly PHP files;
A lot of our clients use CMS's. Maybe it is better to base the system on a certain CMS?

Thank you.

I'm currently doing some research in the area of network security, where my topic is anomaly detection for log messages. However, I hope that I will be able to provide some insights for your problem.

(1) Signatures are ugly, but they do work. Although everybody is talking about anomaly detection and similar topics, nowadays signatures remain the most reliable way to detect malicious code/activity/etc. So you should continue using them and do not hope, that some anomaly detection will be able to fully replace it.

(2) The signatures are, of course, very limited and they cannot identify novel type of malicious code/attacks/etc. Then there are attempts to solve this problem with anomaly detection. The main disadvantage of anomaly detection is that it always produces false positive alerts that you should process and filter out. The current trend is to build a hybrid systems: first apply signatures and maybe some queries, and then perform anomaly detection in addition to it.

(3) It should definitely be possible to create an anomaly detection approach for your problem based on some machine learning techniques (based on your list of conditions; theoretically, it can be also possible to analyse PHP code i.e. perform static code anomaly detection, but this could be rather complicated/big project). However, I won't expect that it will catch all malicious code. The realistic number could be something like 70-80% detection rate with 10-20% false positive rate. So if you check 1000 files and 10 of them are malicious, probably in the best case you will be able to develop a system that will return you 100 alerts, where 8 of 10 malicious files will be detected, but the rest (let's say 92 other alerts) will be false positive. Also, probably 6-7 of these 8 you can have already detected with signatures and queries.

I hope that I'm not too pessimistic here. Sometimes, for specific use cases, it is possible to achieve 98-99% true positive rate with 1-2% false positive rate, but I'm not sure if you will have so much luck in your case. Also I do not know enough details about your use case to make any predictions.

(4) However, if you will be able to rank your results, then the top of the anomaly detection output will contain more true positive and less false positive alerts. For example, if your system will return 100 ranked alerts, you can only look on top 30 of them. And these 30 will contain 6 true positive results and only 24 false positive (which is to some extend better than 8 true positive and 92 false positive). Next, if you look at 5 most highly ranked alerts, they will probably contain 1-2 true positive and 3-4 false positive. And this is what you can check on the daily basis in addition to your signature-based detection results.

You can hire a data mining/machine learning expert to build such a system for you, or try to do it yourself, if you have enough skills.

I have not found too much relevant research papers (which is not a good sign), but I hope that the following can be relatively useful for you:

Learning to Detect Malicious Executables in the Wild. However, this should be a misuse detection, not an anomaly detection.
A static heuristic approach to detecting malware targets

Finally, there should be some alternative solutions to this problem. I have googled for it and here is what I have found so far:

PHP malware finder

Also not too much (just one link), but I hope you can try to search more, there should be some techniques like sandboxing. Maybe you can check this pdf for relevant info.


Where to get patches for recent CVEs announced for glibc? My SoC vendor uses Yocto to create custom Embedded Linux distribution, that contains glibc 2.22.

As part of the distribution we have received patches till CVE-2016-4429. But, now there are some vulnerabilities which hasn't been addressed yet, such as:

CVE-2016-5417
CVE-2016-6323

Are there known patches for these CVEs that we can get?

Searching for CVE-2016-5417 points to nvd.nist.giv which has as resource listed a link to a patch.

Note that these source patches are usually only for versions still supported by the authors of the software, i.e. often only the latest versions. And it might also be that the patch includes not only a fix for this specific issue but for multiple issues. In such cases you either depend on your distributor to provide you with a fixed version of the software or you need to have the know-how to extract the essential patch from a bigger one, maybe modify it for your software version and apply it - i.e. do yourself what the distributor usually does for you.


Can chipped cards without a stripe or with a blanked stripe be exploited by this attack? I just read this article in CNN Money and am trying to figure out what the vulnerability is:

http://money.cnn.com/2016/08/03/technology/credit-card-chips-flaw/

  Computer security researchers at the payment technology company NCR demonstrated how credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again. This allows them to keep counterfeiting -- just like they did before the nationwide switch to chip cards.

This suggests that if the stripe is not present or invalid, then the attack is not possible. But then it goes on to say...

  This claim of a glaring hole in EMV, the chip-based system, is possible because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.

This sounds like an entirely different vulnerability. Does anyone know more about this vulnerability, and if it can affect a card that has had its stripe blanked?

I haven't seen the talk, but based on the description and their slides, I'm pretty sure that you're conflating two separate attacks.

  ... credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again.

The magnetic track data on a credit card contains (among other information) a three-digit service code.  A service code that begins with a 2 or a 6 indicates that this is a chip card, which is how the terminal knows to tell you to insert the chip if you have one.  By changing that first digit to a 1 or a 5 (and appropriately altering the check digit), they can trick the terminal into thinking it's a chipless card and permitting the swipe.

This attack won't work under normal circumstances, because the entire swipe data is sent to the bank to verify.  Changing the service code will cause the data the bank gets to be wrong, and it'll reject the transaction "on the back end", as the article you linked to says:

  "If the data on the magnetic stripe is altered it might fool the terminal," said U.S. Payments Forum director Randy Vanderhoof. But on the back end, the system would "reject the transaction."

However, merchants have the capability to do "store and forward", aka "offline mode".  Slide 24 points out that EMV fails to "Prevent using modified Track 2 in offline mode", which is very true.  This happens when the POS is unable to actually connect to the card networks to get an authentication from the bank.  Rather than reject all transactions (lost business!) or require calling the bank to get a verbal auth code (lost time! customer confusion!), the business just decides to store all the transactions and forward them later, when things are back online.   Since there's no connectivity, there's no way to know whether the data is valid, if the card is over its limit, or any of the other usual safety checks.  The merchant accepts the risk of that in order to continue doing business.

Obviously, in this mode the altered track data won't be caught until it's too late, and the transaction fails to forward, bypassing EMV altogether.

  ... because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.

This is a separate issue, where the merchant's terminal transmits the card data to the POS in plaintext.  Even if the POS then immediately encrypts it (either for store-and-forward storage or to actively transmit), it was still in the clear over one leg of the network, which provides opportunity for compromise.  The section of the slides that starts on page 13 address one (of many) attacks on this: Networks shims.  If you can put your device or code between the terminal (POI) and the payment app that encrypts it, or between the (non-encrypting) app and the POS software, then you can read off the data as it goes by, undetectably.

The counter to this one is on page 41 and higher:  Point-to-point encryption (P2PE).  With P2PE, the device encrypts the data itself, using a pre-loaded key.  Now, no matter where you interject yourself into the process, you can't retrieve the card data, because it's encrypted all the way to the gateway/processor/card network.

This still doesn't protect you against skimmers (page 39) or attacks on the device's software (page 40 and earlier), but it reduces the attack surface.


How can I check the integrity of the downloaded files? I know we use hash functions to check for the integrity of the files etc... but my question is how can we check for the integrity of the files being downloaded from some server?

Integrity is defined only relatively to an authoritative source which tells what the "correct" sequence of byte is. Hash functions don't create integrity, they transport it. Basically, if you have:

a file;
a hash value, presumed correct;

then you can recompute the hash function over the file and see if you get the same hash value.

You still have to start somewhere. Some software distributors provide, along with the software, a "checksum" (or "md5sum" or "sha1sum") file, which contains the hash values. Assuming you got the correct checksum file, this allows you to verify whether you downloaded the right file, down to the last bit; and this works regardless of how you downloaded the possibly big file (even if it came over some shady peer-to-peer network or whatever; you cannot cheat hash functions).

Now this does not solve the integrity problem; it just reduces it to the problem of making sure that you got the right hash value. Hash values are small (32 bytes for SHA-256) so this opens a lot of possibilities. In the context of downloading files from P2P systems, you could obtain the hash value from a HTTPS Web site (HTTPS uses SSL which ensures server authentication -- you have the guarantee that you talk to the server you intend -- and transport integrity -- what you receive is guaranteed to be what the server sent). In the context of exchanging PGP public keys with people, hash values (often called "fingerprints" or "thumbprints") are short enough to be transferred manually (printed on a business card, spelled over phone...).

Digital signatures expand on the concept, but they too begin with hash functions. All digital signature algorithms sign not the message itself, but the hash of the message (which is equally good as long as the hash function is secure, i.e. resistant to collisions and preimages).


SHA 1 with RSA for ssl certificate Hi using SHA 1 with RSA encryption for ssl certificate is secure? As i know, sha 1 is not secure, but if we use RSA with sha1, still it will be an issue? Please suggest if any security issues exist.

There is no "SHA1 with RSA encryption" for certificates used in SSL. In the context of certificates the owner of the certificate has a key pair (RSA, ECC...) and here the public key part is included in the certificate, SHA1 (or other hash algorithms) are used as a cryptographic hash within the signature and the private key (RSA, ECC..) of the issuer certificate is used in this signature too (for signing, not encrypting).

SHA1 is no longer considered secure for use in certificate signatures - use SHA2 (i.e. SHA256, SHA384... etc) instead.


Forcing IE11 to use perfect forward secrey on AWS ELB I can connect to my server in practically every browser except for Internet Explorer and I cannot figure out why.

I am resolving SSL on AWS Elastic Load Balancer (ELB), which is configured to use the following ciphers:

DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES256-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA

I ran an SSL Labs server test 1 and the simulated handshake section passed every browser except all versions of IE, which all failed:

IE 11 / Win 8.1 Protocol or cipher suite mismatch   Fail3
Fail3: Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.

I tried connecting to the server using IE11 and IE10 and neither worked. I was able to connect to the server using Chrome, Firefox, Safari (v6 and v7).

IE11 supports TLS v1.2, v1.1, and v1.0, so it should be able to use one of the configured ciphers, right?

IE11 supports TLS v1.2, v1.1, and v1.0, so it should be able to use one of the configured ciphers, right?

No. The only cipher suite mandated by RFC 5246 is (in OpenSSL parlance) AES128-SHA. (I don't think any later RFCs added more.)

Read the SSL Labs client reports for IE 7/Vista and IE 11/Win8.1. IE supports DHE -- but only with DSA certicates. However, it does support ECDHE with RSA (and ECDSA) certificates.

You need to enable a cipher suite supported by IE, as listed above by SSL Labs. IE 7-10 support TLS 1.0 and the cipher suites ECDHE-RSA-AES128-SHA and ECDHE-RSA-AES256-SHA. IE 11 also adds support for TLS 1.2 and ECDHE-RSA-AES128-SHA256. If the ELB platform doesn't support ECDHE, your only option is to enable some old non-PFS cipher suite like AES128-SHA.


Environmentally friendly ways to destroy hard drives The best method to prevent others from reading the data on hard drives is to destroy the drives physically: a sledgehammer is a cheap and effective tool to prevent the data from being read again.  Since many types of hardware, including hard drives, contain toxic materials, it'd be a good idea to take them to some responsible e-waste recycling services.

There's a lot of info on the web about diverting e-waste from landfills.  There's also plenty of discussion on destroying data on hard drives.  But I have not found info on ensuring the data on the drives has been destroyed before giving them to the e-waste recycling services.  I afraid that a hard drive that has been beat up too badly becomes difficult or impossible to handle by the recycling services.

Is it possible to satisfy both the environment and my own privacy?

A first method is to open up the old hard disk, and extract the platters. Hard drives are usually closed with screws, so it can be unscrewed; beware, though, that it is customary for hard disk vendors to hide the screws under stickers (a disk is sealed and letting the air in can kill it, so vendors want to prevent inquisitive customers from unknowingly breaking their disks).

The data is on the platters; the rest of the disk can be sent to recycling... except if that is a hybrid drive, where data can be both on the platters and in the Flash chip. Removal of the said chip can be done, but this assume that you access the logic board and reliably recognize the Flash chip.

With this method, the recycling issue is not solved, but reduced to the platters only.

Another method is degaussing. A hard drive degausser will destroy the magnetically stored data by applying a powerful magnetic field on the disk (either a big fixed one, or a smaller alternating one). This makes the disk unusable (because the disk tracks are also destroyed) but preserves its physical integrity, making recycling as easy as it can be on a "normal" disk.

There again, Flash chips may resist degaussing, so SSD and hybrid drives will be a problem.


What are the Security Risks of Disabling Reverse Path Filtering Reverse Path Filters are generally used to disable asymmetric routing where an application has a different incoming and outgoing routes. So idea is to prevent packet entering from one interface leaving via the other. But there is a conflict of opinion regarding security risk of disabling reverse path filtering. My question is if disable reverse path filtering then what are the security risk and how can a malware exploit this.

Reverse path filtering (or forwarding) has nothing to do with an application. Applications have no knowledge of the underlying network topology, RPF is done at a lower level.

Most attacks that take advantage of systems that do not check their routing information base before forwarding packets are denial of service attacks, or reflection attacks. Here's how it works: An attacker outside your network sends a packet to an internet facing server with a source IP that is actually inside your network. The server receives it, crafts a response, then sends it back to the source IP address, which is a system in your network. Bingo, the attacker just penetrated your perimeter. If your server had checked the reverse path it would have seen that the address didn't match the interface it should have come from, and discarded it before it reached the application.

As for how useful it is depends on your network topology, it can create more problems than it solves as you have to ensure that all routing paths are synchronous, which can be very difficult to accomplish. In some cases asynchronous traffic can work well and be beneficial in terms of resiliency, load balancing, etc. In simple networks where you can rigidly control all your paths to make sure return traffic goes back through the same interface it came in it may add some security. In complex networks the benefit of implementing it is greatly outweighed by the design and administration overhead required to make it work, even if it is feasible to do so.

Perhaps the greatest argument against it is that if you have your house remotely in order you simply don't need it. A basic perimeter firewall ruleset will block all incoming traffic with internally used IP addresses, and all private addressing. Essentially, if you ever have a situation where reverse path filtering would have been beneficial whomever manages your firewall rules should try a new line of work.


best practices for storing retrievable passwords I am trying to build a NMS (network management system) and I am required to store passwords for 3rd party databases, devices and servers that are being managed (not user passwords). These passwords need to be able to be retrieved as plain text in order to login to the devices, connect to the remote databases.

I would like to know the best practices for storing such passwords either in a database or a text file. My current approach is that, store the password as base64 encoded in a text config file and decode it in the source code. Only the developers have read/write access to the config file and source code. No other users on the dev/prod server can read these files. Do you think this is a safe approach?

And yes, I have this answer, but in my particular case, I am not dealing with user account passwords, but instead I am dealing with passwords for logging into the devices that are being managed. True, if someone gets hold of such passwords, they can easily login to the box and "reload/reboot".

Also, because the NMS is all about automation (and assuming I will be running multiple cronjobs), I cannot expect the NMS tool to be prompted for passwords.

Thanks,
Amit

Never. Ever. Use. Base. 64. Encoding. It is not secure. It is also not allowed if you are managing other peoples passwords.

You must store the passwords encrypted through a machine level program that will encrypt and decrypt them. After they have been encrypted you can store them where you like, but you must always go through the program to encrypt and decrypt them.

Roboform Enterprise is a great password manager. The security official can change the roboform password for the clients, generate random passwords, and keep things pretty darned secure.

Of course since you're building your own, the truth of the matter is that you will have to build an auto key rotating encryption program with the keys stored in a separate physical, non network, secure location. You then encrypt the passwords and store them.

When a key gets rotated, the program retrieves every password, decrypts, encrypts with the new key, and restores them to the database or does it on the fly with the next retrieval. But basically you have to have a system level program do it.

You should also make this dependent on the system it is compiled on. This way you can make sure that if the program itself is taken to a new system, it won't work decrypt those passwords correctly.

Of course this means that for every client on your system, they need their own copy of the application, and their own set of keys. That however is the nature of enterprise security.


LetsEncrypt / Exim4 / GnuTLS / cert chaining: "The provided X.509 certificate list is not sorted" error From what I can determine, you generate a LetsEncrypt certificate that includes the full cert chain thus:

# run lets-enc the usual way
# then ..:
wget -O intermediate.pem https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
cat DOMAIN.crt intermediate.pem >DOMAIN.pem
# now use DOMAIN.pem instead of DOMAIN.crt

Unfortunately, when I do that, Exim4 resp. GnuTLS complains that

(cert/key setup: cert=/etc/letsencrypt/keys/DOMAIN.pem
 key=/etc/letsencrypt/keys/DOMAIN.key):
The provided X.509 certificate list is not sorted (in subject to issuer order)

and refuses to enable SSL.

Since using the "naked" .CRT file results in annoying certificate warnings on some clients (it works, otherwise), I'd like to fix that.

You got the wrong certificate. Check the graph at the Let's encrypt site and you will see that a leaf certificate is not signed by the X1 certificate you've downloaded but by  X3. If you would look at the certificate details (with openssl x509 -text or similar) you would also see the issuer of your certificate and you could check that it matches the subject of the issuers certificate.


How can I misuse the information of DCE service enumeration? Nessus reports almost on any Windows machine "DCE service enumaration". With the metasploit module tcp_dcerpc_auditor I get the following information:

192.168.1.23 - UUID 99fcfec4-5260-101b-bbcb-00aa0021347a 0.0 OPEN VIA 135 ACCESS GRANTED 0000000somelongnumber0000
192.168.1.23 - UUID afa8bd80-7d8a-11c9-bef4-08002b102989 1.0 OPEN VIA 135 ACCESS GRANTED 00000somelongnumber0000

In the nessus finding it says it could be used for information gathering. But how exactly? Is there a way to use the UUID?

Check this out. An attacker can see what services are running on the machine. This information can be very useful for planning and launching an attack.


Should a company physically destroy old HDD? Is it advisable for a security-minded company (data stored could be client's detailed information, patent pending docs) destroy all replaced HDDs/SSD? Or is it OK to re-sell them online?

Information used in the disk was encrypted.

Disk is cheap, peace of mind isn't.  Shred the disks and you won't have to worry about them.

"But it's encrypted..." - is it?  Are all your disks encrypted?  If not, how confident are you that your asset management never ever confuses encrypted and unencrypted disks?  Are you willing to sink the necessary effort into tracking assets that closely?

Disk is cheap.  You won't earn that much from selling them, and people buying the rest of the hardware can backfill a disk pretty cheaply.  Just shred them.


Finding and attacking an IMAP Server For a security challenge I am supposed to dictionary attack an IMAP service. A rather simple exercise using hydra.

So far I failed, since I've given hydra the actual website instead of the mail server. How can I find a sites mail server? Something like imap.example.com instead of example.com.

I am not sure about the username either. Does the account that hydra expects have to have an @example.com ending?

EDIT 1:

I tested bashCypher's clue with the dig command. This appeared:

is this postmaster.xxx.com what I'm looking for?

So far I tried to attack the main website which was handed out to me. Hydra with a dictionary and a username didn't show any errors. It worked for hours and never found a pwd. Despite the fact that the pwd should be rather easy...

First of all: Be careful of attacking random targets on the Internet unless you have an order to do any "white hat" / ethical hacking by the owner of the information systems you are trying to break into. Otherwise you may become liable to civil and crime investigations.

Having said that, the initial intuition would be that there is no way to tell a domain's IMAP server in a similar way as you could just lookup a domain's MX (SMTP) server through the DNS system.

But there is; at least for some domains. Some domains use autoconfiguration mechanisms to make it easy for people using their services to configure their MUAs. Take a look at

https://wiki.mozilla.org/Thunderbird:Autoconfiguration
https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2010-technical-article/jj591328(v=exchg.141)

for technical details. YMMV.

The answer to the 2nd part of your question is almost the same:

Some systems use the user's email address as a username, some don't. But if the domain in question is configured to use either Autodiscovery or Autoconfig, the service will also tell you the username that belongs to an email address.

Please not not disregard my warning in the beginning! You may harm yourself.


Secure Way to Set Up Wifi Extender I recently purchased a wifi extender and I now have to set it up.
There are three options for how to set it up:

Through the app
By pressing the WPS button on the router and then pressing the WPS button on the extender
By connecting to the wifi network of the extender (which does not have a password) and then navigating to a webpage that doesn't have HTTPS and enter the password for the extender.

The fact that there is no preset password is worrying. Considering that 3 is even possible  I worry about what security compromises they made in implementing 1.
Is 2. the best bet here? WPS seems to have some vulnerabilities though after googling.

Using the WPS (Wi-Fi Protected Setup) button is generally considered a secure method.  For two minutes after that, your access point will accept new devices onto the network, but not after, which means that the scope for attack is limited.  If you are concerned, most access points allow you to find the connected devices to your network, and you can verify that before and after only one new device has connected.
The WPS PIN method is known to be vulnerable to brute force and should generally be disabled on all access points.  However, you're clearly not using that technique here.
If you're using the Wi-Fi network of the extender, that is also probably okay, provided you promptly secure it with a strong password you don't use elsewhere.  The use of HTTPS is generally not possible on this kind of device because (a) certificates are time-limited, so they could expire before your device got installed, and (b) usually there isn't a secure way to ship the private key required for TLS, so the certificate would end up revoked due to potential misuse.
I generally recommend against using custom apps for setting up embedded devices because typically the security in such scenarios is pretty abysmal and using the app may result in that functionality being enabled on a more permanent basis.
The major threat you need to consider in scenarios 2 and 3 is whether the attacker is present in the small window of time during your power-on and setup.  If so, all of these options are insecure, and you should return the device and purchase one that does not power on any radios until set up over an Ethernet connection so that you can secure it adequately at first from a trusted network.  You will also of course want to be sure that your network is secured with a passphrase providing at least 128 bits of entropy and that all of your extenders and access points are up to date with security patches.
If, on the other hand, you believe that your major source of attacks is going to be nosy neighbors and not a dedicated, ever-vigilant party, then option 2 is probably secure and also quite easy, and it's a fine choice.


What countries have strong data protection laws? Many answers on this site and other security-related websites state that one should host sensitive data in a country with strong data protection laws. What countries are these, and how is this determined?

I understand that Germany has an excellent webhosting service as does the UK. Are either of these countries considered to have strong data protection laws? Even if they do, is it reasonable to assume that those laws are abided by?

I have found a website which list a overview of the key privacy and data protection laws and regulations across 77 different jurisdictions. Of course i haven't read the legislation of any of these countries and i'm not a lawyer so you should pick one of this countries and do a deep search to see if their laws suit your needs.

And laws can change at any time this should not be the end of your search but rather the start for a more deep and current search on the law.