How can I find a SHA-256 hash with a given suffix using hashcat? Recently we competed in the X-MAS 2019 CTF and many of the challenges included a proof of work (PoW) check to avoid Denial of Service (DoS) attacks against their servers. The most common was we were given a 6 character suffix and asked to find anything where the hash ended in that suffix:

Provide a hex string X such that sha256(X)[-6:] = abcdef

The suffix abcdef would change every time you connected to the server. An example of a correct response:

hash = e38450c7008711d86a4d6c2039c8633a1ed637281b96888d7d9ff257aaabcdef
x = 4cbab1bbb03b4a10aef586b6

Can this be done using hashcat?

This is not possible using hashcat, unless you're ready to change the source code to suit your needs.

For example, you can adapt s3inlc's fork which added an option to check for hashes with some specific properties (starting / ending with as much 0 as possible, etc.).


Is there any mechanism available in Android platform for remote attestation? I recently read about PC/Desktops which come with TPM chips which are used for remote attestation.

So following are my questions:

Does any Android smartphone come with a TPM chip?
Is there any way for a service provider to check whether the user is accessing their service from a compromised Android OS?
(i.e., Does Android platform provide any mechanism for remote attestation?)

To my knowledge, no Android smartphones comes with a TPM. However, in theory, a TPM could be implemented in software within ARM's TrustZone but I never seen this in practice.
Samsung KNOX offers this as part of Secure Boot and TIMA (a TEE) running within TrustZone.

They implemented Secure Boot which makes sure a trusted (known) environment is loaded (they're probably using something like HIBv4 - ARM's efuse) and n,
TIMA pause the OS from time to time and assess the integrity of Android. In TZ terms, TIMA run in the Secure World while Android is in the Normal World thus TIMA has more privilege than Android.

Secure Boot doesn't provide -at-run-time- indication about the posture of a device like Remote Attestation could do but still provides some form of guaranty over the integrity of the OS. This link also describe how they authenticate a Samsung KNOX device from which you can derive trust (Secure Boot and TIMA are running).

Other devices provides Secure Boot but, to my knowledge, KNOX is the only thing monitoring the integrity after boot up and really providing a means by which you can derive trust that those controls are in place.


Are TPM chips or the equiavlent required for FIPS 140-2 security level 1 compliance? A 'TPM chip' is:

  a secure cryptoprocessor that can store cryptographic keys that
  protect information

FIPS 140-2 requires a cryptographic module, which can be hardware, software, or both that have been certified.

If I was using Bitlocker as a cryptographic module, would I need a TPM as another piece of that cryptographic module?

Is a TPM required for FIPS 140-2 security level 1 compliance?

What about security level 2?

No, absolutely not. FIPS 140-2 level 1 is essentially a test that your cryptographic module:

uses approved algorithms;
implements those algorithms correctly;
does not leak like a sieve.

Software can be validated at FIPS 140 level 1, there is no need to involve special hardware. FIPS 140 level 1 does not indicate resistance against an attacker with hardware access, unless the hardware is part of the target of evaluation. If you have a requirement for FIPS 140 level 1 compliance, then using Bitlocker (an approved version thereof, under an approved version of Windows operating in FIPS mode) is sufficient, whether or not the secrets are stored in a TPM.

At FIPS 140 level 2, the hardware must be part of the target of evaluation, but the security requirement is limited to tamper-evidence. A TPM is overkill for that (TPMs offer tamper resistance, so in principle a suitably designed TPM-based system could reach FIPS 140 level 3, though there are sticky points, and going beyond level 2 is not likely to be practical). You can browse the list of (non-secret) FIPS-140 validated modules. Note that the list does not include Bitlocker+TPM combinations, and in fact no TPM has been certified at FIPS 140 level 2 so far.

One of the hurdles in certifying a TPM is that it includes a large number of algorithms, many of them non-approved. The TPM does not provide a good way to disable these algorithms or to isolate all FIPS mode data from non-FIPS mode data. Yet this would have to be done, and tracked not only during operation but through the lifetime of the TPM, since the TPM includes non-volatile storage. (How do you know a secret key stored in FIPS mode is not leaked to non-FIPS-mode where it's used to encrypt some data with a broken algorithm?) Another hurdle is that all certified algorithms undergo a self-test when the device boots, and this takes a while (TPMs have pretty slow chips).

By the way, if you do not have a legal or contractual requirement for FIPS conformance, and you don't need to quote FIPS conformance as a commercial argument, then don't worry about FIPS conformance. Especially at level 1, especially when running on a complex, open OS with a poor track record on security like Windows. FIPS conformance is not an indication of security, and AviD's law of regulatory compliance very much applies here: FIPS conformance reduces the risk of the penalties of non-conformance. If you're running under Windows, I recommend using Bitlocker, not because of any conformance, but because it was written by specialists, has been heavily tested, and is being actively maintained. That way, you can concentrate on the real weakness in your overall security, like the fact that 50% of your users are going to use 1234 as their PIN and the other 50% are going to use their birthday.


How to store & use sensitive data in Java I have a several Spring Boot applications that use BCryptPasswordEncoder to encrypt data I'll never need to directly use again - passwords, for example. However, I have quite a bit of sensitive data (SSN, credit cards) that I need to store securely, but will also need to use at some point. I could use something like Authorize.net (although this seems really expensive for our startup) to store the credit card info, but I still need SSN and other personal information.

My post on Stack Overflow suggested using symmetric keys, but I was hoping someone here might know a best practice, open source solution to securing data.  I thought about using the db (PostgreSQL) but I heard that has issues as well.

For storing credit cards specifically, you need to weigh the costs of using Stripe, PayPal, or similar, or storing the cards yourself and the costs, financial and legal, should that data become compromised. QSAs have been getting tighter and tighter with all of the breaches that have been happening lately. That's a decision you'll have to make. It may be with the number of cards you have, and the frequency, you'll find it cheaper to store them yourself.

However, I would encourage you to find a QSA to talk to. PCI-DSS, as well as Visa, Mastercard, and other network operators, have their own requirements.


Can a connected USB device read all data from the USB bus? Is it possible for a (malicious) (hardware) USB device to access all the data that is transferred through the USB bus and then read/store this information, essentially sniffing all transferred data? Or is the USB bus switched and only sends data to the correct recipient, i.e. only allowing the intended recipient to read it?

Most likely yes, but it depends

Much like PATA, SCSI, and Ethernet devices, USB devices don't directly connect to the computer. They connect to a Host Controller that manages all signaling and communication. All ports are connected to something called a Root Hub, and to each Root Hub you may connect other hubs and subsequently more hubs.

Each of these hubs have multiple downstreams and exactly one upstream. "What does that mean?" you ask. Well, it means that whatever data sent by the hub is sent to all child hubs and devices, while data sent by the hubs and devices are only sent "upwards" to Root Hub.

So, if a number of devices are connected to ports that lead to the same Root Hub (they're all controlled by the same Host Controller), then any of the devices can sniff the data only in the direction Computer -> Device.

In my laptop, for example, the ports on the right side are controlled by a Host Controller, and the ports on the left side are controlled by another Host Controller.

Meaning that data sent to any device on the right side can be sniffed by any device on the right side, but not devices connected to the left side.

I remember a colleague of mine modifying a USB stick to prevent it from ignoring data sent to other devices. So if you plug that modified USB stick to a computer, you can capture all the files copied to other USB sticks on the same computer.

Update:

@Polynomial's comment made me question the whole answer, since my information is based on my colleague's description. To be sure, I tried to find some reference. I dug in the USB specs and I found this:

  ...
  In the downstream direction, hubs operate in a broadcast mode. When a
  hub detects the start of a packet on its upstream facing port, it
  establishes connectivity to all enabled downstream facing ports. If a
  port is not enabled, it does not propagate packet signaling downstream.

Also, a TOTAL PHASE KB article seems to agree

  USB 2.0 works through a unidirectional broadcast system. When a host
  sends a packet, all downstream devices will see that traffic. If the
  host wishes to communicate with a specific device, it must include the
  address of the device in the token packet. Upstream traffic (the
  response from devices) are only seen by the host or hubs that are
  directly on the return path to the host.


Unix command to generate cryptographically secure random string Is the following Unix command cryptographically secure to randomly generate 20 characters (a-zA-Z0-9 only)?

dd if=/dev/urandom bs=256 count=1 2> /dev/null | LC_ALL=C tr -dc 'A-Za-z0-9' | head -c20

Is there a better or more secure way to go about this in Unix?

No, it's not entirely secure. Let's look at each of the commands:
dd if=/dev/urandom bs=256 count=1 2> /dev/null

This will read a single 256 byte block from /dev/urandom, a cryptographically secure random source. The problem starts here, and is related to this 256 byte limit. In fact, you do not even need to use dd here. The next command is perfectly able to read from a block device on its own.
LC_ALL=C tr -dc 'A-Za-z0-9'

This command strips out all characters that are not alphanumeric. The LC_ALL=C limits the charset to plain ASCII, where [:alnum:] will match 62 characters. Symbols and unprintable characters will be removed. The issue now is that only 256 bytes are given to this command, so what if too few of those bytes are alphanumeric? The tr command will happily take 256 bytes of input and spit out only a couple bytes of output if only a couple bytes match the filter.
head -c20

This command simply truncates the output to 20 bytes. The actual output will vary between 0 and 20 characters.* Statistically, it is most likely for it to output the entire 20 characters each time.

A superior way to get random alphanumeric characters can be done with fewer commands. This will have tr read as much data from /dev/urandom as it needs, continuously spitting out alphanumeric ASCII to the next command. As soon as head has the 20 bytes it has asked for, it will close the pipe, causing tr to stop reading random data and exit. This is what you should use:
LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c20

This will guarantee 20 random characters, with an equivalent strength of log2(6220) ≈ 119.1 bits.
You can also turn this into a shell script function to make password generation from command line easier. This particular function takes the number of characters for the password as an argument. If no argument is specified, it defaults to 20 characters:
newpass() {
    LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c${1:-20}
}

* The risk is largely theoretical. Each byte has a (256 - 62) / 256 chance (about 76%) of not being alphanumeric. The probability that at least 256 - 20 bytes are not alphanumeric is very low, but non-zero: (194 / 256)236 ≈ 3.8 × 10-28.


What is a link certificate? I read an article and there was a link certificate short introduced (about a half sentence). Now I want to know what exactly a link certificate is?

Assumption: A link certificate is used, when an old certificate is replaced by a new one. The link certificate is the new certificate signed with the old private key. So that with the old public key, the new certificate could be verified.

Your assumption is correct. However to avoid a certificate path validation with expired CA certificates at the end, you can have such a link certificate and another certificate from the same CA with the same new public key which is self-signed (uses the new private key corresponding to the new public key). This way you can smoothly switch from the old CA certificate to the new one and your certificate path neither ends with an expired certificate nor it gets longer. In such a case the CA certificates should make use of the AuthorityKeyIdentifier / SubjectKeyIdentifier extensions to simplify things.


How to secure mine as well as other people' passwords on the computer used by my receptionist? My friend runs an office in which the computer used by the receptionist is used by so many people including my friend and others (so many people come there for job recruitment) who frequently save their passwords on browsers.

Today I was talking to the receptionist as we know each other very well and while discussing hacking, I told him how to view saved passwords on chrome and then realised my mistake. What do you think is the best way to secure password saved even accidentally on that pc so that the receptionist won't ever be able to view any of em?

Currently I have suggested him lastpass (although its more of a password manager, on first installation it removes all the unsafe passwords and even if any others are saved then makes them inaccessible by a master password).

Dedicated users. Remove the passwords that are saved and move to a computer use model that don't involve shared accounts. Don't give your receptionist (or anyone but Sys Admins) privileged access to systems. Ideally get all of your users using password storage such as KeePass, LastPass, etc.


Does Google's SSL encryption for searches thwart NSA spying? Given everything that is suspected about NSA (and GCHQ, DGSE, etc.) access to user data:

Avoiding speculation, can and do we know whether Google's recent action to make all searches use SSL encryption will actually prevent said spying?

If not, what more (in addition to what we've seen) would we need to know, to know that?

HTTPS, aka SSL, only protects data in transit. Google switching automatically from HTTP to HTTPS means that the search query from your browser to Google's server gets encrypted. But on Google's server, the SSL tunnel ends, and it gets decrypted. This will prevent spying only under the two following conditions:

The spies were indeed looking at traffic between the client machine and Google's server (as opposed to simply requesting from Google themselves a copy of the data).
The user actually notices that Google redirects to the HTTPS URL, and "takes offence" if the redirect does not happen.

The second case is against active spies who would do a Man-in-the-Middle attack, which is highly doable on HTTP (no SSL). Since the redirect-to-HTTPS occurs at the HTTP level, before (of course) any SSL actually occurs, then the MitM can certainly block it and maintain the illusion of a non-SSL Google server.

In any case, for a big US governmental agency like the NSA, enlisting the help of some people at Google's, to get a copy of the query data, would probably be vastly easier and more efficient than the grudging work of spying on network lines. Google, being a US-based company, would comply or be made to comply for a (small) fraction of the cost implied by generalized spying. Retrieving query data from Google themselves would also work for queries which are inconvenient to spy upon, e.g. for a connection from a non-US country to a non-US-based Google server.

Therefore, I find it implausible that enabling HTTPS would really be relevant to purported spying from NSA. "HTTPS for everybody" is more a marketing / public relations move than an actual security improvement, in the context of Google and assuming that the "enemy" is the NSA.


Why aren't anomaly-based intrusion detection schemes implemented in Snort? I have read many papers on anomaly-based network intrusion detection.  Am I correct that each of their techniques could be implemented as Snort preprocessor?  If this is true, why there are no anomaly detection preprocessors available for Snort currently, despite the fact that there are many papers out there on this subject?

SPADE is no more included in snort as I learned. PHAD, by Bernhard Guillon, should be patched, not official. AnomalyDetection is of course available.

Are anomaly detection algorithms useless practically?

There are two reasons:

First, anomaly-based network intrusion detection is harder to translate from research into practice than it might at first seem.  It tends to raise many false alarms.
Second, those are research papers.  Researchers often build a research prototype that's just good enough to test the idea (as a proof of concept).  There's a great deal of additional work to build something practically deployable, so only a small fraction of research papers go that far.  This is true across pretty much all of computer science research -- not just anomaly-based intrusion detection.

For your question about whether anomaly detection is useless in practice, see Neural networks & anomaly detection on this site.  (The search bar is your friend; give it a try!)


Detecting attempts to attack a website? I am currently trying to implement some recommendations from OWASP AppSensor Project and I'd like to respond to the attacker when he tries to break into my website.

Is there any resource covering/analyzing specific attack vectors? With specific I mean something like list of rules: when user tries to write ' character into username field, it's definitely an attack attempt (which is not, but ' or 'x'=x' probably is).

My main goal is to effectively log and respond to attack attempts and avoid false positives as much as possible (it should never happen that the system bans legal user). We are talking here probably mainly about SQL injection, XSS and maybe Request threshold (something like 50 requests in 1 seconds is suspicious - is it really?). If you think I should respond to another type of action too, feel free to suggest it and write a reason why should I focus on this type of action.

Robust web application in the means of valid filtration/sanitization is enough in most cases.  Problem you are trying to solve is very hard to satisfy. I am repeating again and again - do not reinvent the wheel, because there are high chances that you will just waste time with no effect on security. For example, look how PHP-IDS is written, how it works, which rules it contains. Also, what would you say about these SQL-injection evasion techniques: http://websec.wordpress.com/2010/12/04/sqli-filter-evasion-cheat-sheet-mysql/ - how would you handle them? Or about XSS - http://heideri.ch/jso/. As you might see, more attacks you want to cover - more chances to get false positive.

I am not saying it is impossible and not worth tinkering, but further we go, clearer we see that attacks becomes more and more complicated. First look whether your problem has not been solved previously and if it is really worth your attention.


How to find out that a NIC is in promiscuous mode on a LAN? How to find out that a NIC is in promiscuous mode on a LAN?

DNS test - many packet sniffing tools perform IP address to name lookups to provide DNS names in place of IP addresses. To test this, you must place your network card into promiscuous mode and sends packets out onto the network aimed to bogus hosts. If any name lookups from the bogus hosts are seen, a sniffer might be in action on the host performing the lookups.

ARP Test - When in promiscuous mode the driver for the network card checks for the MAC address being that of the network card for unicast packets, but only checks the first octet of the MAC address against the value 0xff to determine if the packet is broadcast or not. Note that the address for a broadcast packet is ff:ff:ff:ff:ff:ff. To test for this flaw, if you send a packet with a MAC address of ff:00:00:00:00:00 and the correct destination IP address of the host. After receiving a packet, the Microsoft OS using the flawed driver will respond while in promiscuous mode. Probably it happens just with the default MS driver.

Ether Ping test - In older Linux kernels when a network card is placed in promiscuous mode every packet is passed on to the OS. Some Linux kernels looked only at the IP address in the packets to determine whether they should be processed or not. To test for this flaw, you have to send a packet with a bogus MAC address and a valid IP address. Vulnerable Linux kernels with their network cards in promiscuous mode only look at the valid IP address. To get a response, an ICMP echo request message is sent within the bogus packet leading to vulnerable hosts in promiscuous mode to respond.

Maybe there are more, the DNS test for me is the most reliable


What is the risk of having an old, Internet capable phone not used for Interned compromised? (not smartphone) I'm talking about a class of old mobile phones that are not smartphones but are still (theoretically) Internet-capable, at least via 3G. Examples of such phones include Series 40 Nokia phones or the
Samsung phone featured in Spectre (OK that one at least is still available so I have to retract the 'old' word). Note these phones enable running user code via their Java thingy. Symbian phones, however, are out of the scope of my question.

Note I don't ask about browsing the Internet with such phones - these capabilities are, in my experience, often all but useless nowadays anyway. Instead, I mean carrying the phone around while it is switched on and making phone calls.

Until recently I assumed these phones were too simple and too old to be unsafe... But is this really correct? It suddenly struck me that these phones are likely directly routable from the Internet through an IPv4 address - which sounds pretty horrible, doesn't it? Aren't these phones, therefore, under a constant scan? To make things worse, many of such phones are very unlikely to receive updates (are they even technically capable of updating themselves?)

In short - one may not wish to use the internet with their phone - but will the internet forget about them?

This question asks about dumbphones. My question asks about phones that are in-between of dumbphones and smartphones - that already provide attack vectors (Internet, user code, ...?) but not precautions (updates, app scanning, ...?) of smartphones. It would therefore seem that such phones are the worst?

And yet there is, from my experience, noticeable demand for these in-between phones: namely from older people who seek the ease of use of a dumbphone, fear they could not manage to use a smartphone but won't use a true dumbphone because of their diminished availability. This, I believe, makes my question important.

Little bonus that made me ask this Q - some time ago my old Series 40 Nokia phone started showing me a weird message briefly each time I switched it on. The message was saying (IIRC) that my phone was sending some message. What message? Where? I remember seeing this message quite often during my country vacation, but now I switched this phone off and on again, hoping to provoke this message, but it is gone. I suppose this is benign?

Well, first of all you are behind a NAT of a cell phone operator equipment. Secondly, your IP changes frequently - reconnecting to different cell towers will do that (there are many factors to that). Thirdly - there are have to be either zero-day vulnerability or some services running on your phone accepting external requests to be vulnerable.

Phones are way more susceptible to 0 day vulnerabilities and MiTM attacks by impersonating wifi APs and Cell Towers (they are available for purchase and can fit in a rucksack) rather than directly from cell network.

Most of this attacks are being done by injecting javascripts through the browser when you are being served by malicious actors (wifi\cell tower impersonation). So disabling that will solve most vulnerability issues.


XSS with  tag with target="_blank` Basically, I am having an <a> tag with target set to _blank, where an attacker has control over the href parameter, thus possible inserting a javascript tag,  like the following:

<a target="_blank" href="javascript:alert(document.location)">

However, this XSS executes in a new about:blank tab because of the target setting.

Is it possible to bypass this, and let the javascript execute on the original page with the control of the href parameter?

You can use window.opener to exploit this (fiddle):

test

Or if you can escape the attribute value context, you can start a new script tag or a new attribute like onMouseEnter.


How is the TLS version selected between client and server? We have an issue where a client application, that has TLS 1.0, 1.1 and 1.2 enabled cannot connect to a server using only TLS 1.0.

After disabling TLS 1.2 and 1.1 on the client the connection can be made.

So i was wondering; how is the TLS version to use determined between client and server?

Seems that your application (client side) does not accept version negotiation fallback during the SSL/TLS session establishment.

The TLS version is negotiated initially by the client (Client Hello message) specifing the highest version that it supports among other parameters (cipher parameters, etc.). Text from RFC 5246, TLS v1.2:

  client_version:
        The version of the TLS protocol by which the client wishes to
        communicate during this session.  This SHOULD be the latest
        (highest valued) version supported by the client.  For this
        version of the specification, the version will be 3.3 (see
        Appendix E for details about backward compatibility).

After the server receives the Client Hello it sends the Server Hello with the chosen SSL/TLS version among other chosen parameters based on the Client Hello information. Text from RFC 5246, TLS v1.2:

  server_version:
        This field will contain the lower of that suggested by the client
        in the client hello and the highest supported by the server.  For
        this version of the specification, the version is 3.3.  (See
        Appendix E for details about backward compatibility.)

A summary of all this is shown in the following diagram:

I would say the problem is that your Client application does not accept TLS version downgrade fallback during the negotiation and that's why it works when disabling TLSv1.1 and TLSv1.2. Check the bold text in the again RFC 5246, Appendix E:

  A TLS 1.2 client who wishes to negotiate with such older servers will
  send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
  ClientHello.client_version.  If the server does not support this
  version, it will respond with a ServerHello containing an older
  version number.  If the client agrees to use this version, the
  negotiation will proceed as appropriate for the negotiated protocol.

  If the version chosen by the server is not supported by the client
  (or not acceptable), the client MUST send a "protocol_version" alert
  message and close the connection.

An easy approach to debug this, could be to check the logs of both server and application (you did not specify which applications you're using) in verbose mode so you can see the negotation messages. Other more advanced may be to put wirehark/tcpdump to check the negotation parameters. This should be feasible without too much hassle since these information does not travel encrypted.


Is there an asymmetric encryption algorithm that maintains the length of the plaintext? I want to protect some registers by encrypting them without providing additional memory space. Is there a encryption algorithm that will maintain the length of the data to be encrypted? (i.e. plaintext.length=ciphertext.length)

Basically, you're asking for an asymmetric cipher that can have a block size either equal to your message, or to the character size of your message encoding (8 bits for ASCII/UTF8, 16 and 32 for UTF-16 and -32 respectively).

Vanilla RSA can technically do this; you must simply limit the bitsize of the unsigned integer N, produced by choosing two random primes p and q (p must thus be less than sqrt(N), and the domain of possible q values is reduced the closer p is to sqrt(N)). The maximum N can either be of the same order of magnitude as the concatenated message, or some even divisor of it (down to 1 byte/character)

There are however two serious problems with this:

RSA is only secure for very large key sizes; its difficulty is inherent in finding the p and q that produce N, and so the security of any encryption including RSA is in having a literally out-of-this-universe number of possible keys to choose from**. So, tailoring key size to message length would only be secure from a key size perspective if the message were at least 256 ASCII characters (producing a 2048-bit message allowing a securely-large key). Small message sizes (key lengths of 8-32 bits) are trivially broken; worst-case (for an attacker), a 32-bit key requires finding a prime integer p < sqrt(232) = 65536 that evenly divides N; by the prime number theorem there are only 5900 possibilities. You could almost feasibly crack such a key "by hand" with a calculator.
In addition, and more serious, RSA without the proper encryption padding is vulnerable to known-plaintext attacks and in cases that reduce to trivial examples. OAEP, the gold standard RSA padding scheme, uses two hash functions, one of which must have a bit length at least the bit size of the plaintext message, and the length of the full padded message is equal to the sum of both functions' hash message lengths, so the padded message will always be greater than the unpadded message.

Therefore, the approach of plain RSA with a tailored key size should be regarded as fundamentally flawed. Every other public-key system I can find, such as elliptic-curve encryption, has similar limitations based on the math used for the encryption.

**2048 bits is the smallest recommended key size for X.509 digital certificates. 22048 ~= 3.2317e616. Putting this number in perspective, a Planck volume is 4.22419e−105 m3; this unit is, in theory, the granular "resolution" of the universe, based on the Planck length being the smallest distance that any instrument could ever measure. The observable universe is at least on the order of 1e27 m in radius (13.7 billion light years), so the sphere of our observable universe is ~ 4.189e79 m3 ~= 1.7e185 Pl3. That means that if we could not only "count the stars and call them by name", but assign an ordinal to every granular piece of our observable universe, the number of numbers we'd need is 400 decimal digits shorter than the number of numbers inherent in the RSA keyspace.


Why/how does Firefox bypass my employer's SSL decryption? My employer has set up what they're calling "SSL decryption" for Internet access from within the company. I believe this is provided by an f5 device. They have installed a trusted root certificate on all corporate devices, and are using this to terminate outgoing https, making their own https connection to the external server, intercepting all data in plaintext, and re-encrypting it using a fake certificate signed by their replacement root certificate. So, man-in-the-middling everything.

I can see that this interception is taking place by viewing the certification path in my browser, I get something like:

+- Acme Corporation Root CA
|
+--+- *
   |
   +--+- www.letsencrypt.org

The above is true for both Internet Explorer 11 and Chrome 65. However, when I try Firefox 59 I see the following certification path:

+- DST Root CA X3
|
+--+- Let's Encrypt Authority X3
   |
   +--+- www.letsencrypt.org

What I understand from this is that the Firefox connection has not been intercepted and decrypted. (If I've reached the wrong conclusion here, then that would be useful to know.)

Firefox provides under Technical Details the following info:

  Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2)

I can't find a way to see which version of TLS is used by IE and Chrome.

Firefox does not show any installed corporate root certificate in its list of trusted certificates (as it doesn't use the Windows certificate store). Also, the security.enterprise_roots.enabled option is false.

My question is, why and how does Firefox avoid this? Is Firefox lying to me and the connection actually is being intercepted somehow? Is it using a different version of TLS or different cipher suite that the f5 device can't handle?

Note that I have read How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy? which describes a similar situation but wasn't really enlightening. I have also seen the Certificate Patrol addon but that isn't compatible with Firefox Quantum. (Is there a replacement that does work with modern Firefox?)

It's quite simple really, it's your employer that hasn't secured their network properly. I guess that they add a system proxy settings or they configured the other browsers to use their interception proxy, and interception only happens when you are using their proxy, but they didn't put a network firewall to block traffic that doesn't go via the proxy.


How do I change the expiry date of an ElGamal subkey? I have a GPG key which has an ElGamal subkey (elg2048). Frankly, I don't remember why that is or whether I actually need it - I just have it. Now, I've just changed the expiry date of the key overall, using gpg2 --edit-key; however, the subkey expiration date seems not to have changed.

Questions:

Can I change that subkey's expiration date?
If so, how?
If not - should I care? Should I just remove it?

When you edit the key, you get a list of keys. Example::

sec  dsa2048/DEADBEAF
     created: 2014-10-10  expires: 2020-09-28  usage: SC
     trust: ultimate      validity: ultimate
ssb  elg2048/DEADBEAF
     created: 2014-10-10  expires: 2017-10-10  usage: E

If you enter expire, this will affect the "main" key, or perhaps the first key, not the subkey. For the subkey, type in key 1. You should now see * next to the ssb:

sec  dsa2048/DEADBEAF
     created: 2014-10-10  expires: 2020-09-28  usage: SC
     trust: ultimate      validity: ultimate
ssb* elg2048/DEADBEAF
     created: 2014-10-10  expires: 2017-10-10  usage: E

now, an expire command will affect the subkey.


Login: password hash vs successful decrypt Using a one- way function (e.g. BCrypt) for password handling in password based login is a common approach.

When an application uses a key derived from user’s password for encrypting a private key, is it secure to rely on successful decryption on login?

Example:

Registration (all steps performed client- side):

Derive a key (A) from user’s password (e.g. using PBKDF2 with 100k iterations).
Use key A to encrypt user’s private key (using authenticated encryption; e.g. AES in GCM mode).
Store required information in user’s database record (e.g. ciphertext, salt, …).

Login (all steps performed on client- side):

Load user's database record by username.
Derive key (B) from user’s password (using same method used on registration).
Try to decrypt users private key using key B.

Yes, this is a workable approach, when you use authenticated encryption, as you've indicated.  The authentication tag on the encrypted data is analogous to a stored password hash, and GCM is specifically designed to prevent message forgery (i.e., a valid tag constructed without access to the private key).

In fact, GMAC is a variant of GCM mode that is designed not to encrypt data, but just to provide a signature with a shared key over some data.

It's important to note that this should not be done with non-authenticated ciphers, as even with padding being used to detect "correct" decryption, this would lead to a (slightly better than) 1/256 chance of any password working correctly by having correct padding despite being the incorrect key.

All this being said, I don't think this is a good idea, because it's much easier to have implementation errors in this than it is in a standard password storage scheme.  Attacking this scheme is equally easy/difficult to attacking a separate PBKDF2 hash for the user password, which is a well studied authentication mechanism.  If you're worried about CPU time with computing two PBKDF2 hashes, you can do the following:

Compute key = PBKDF2(Password, Salt, N) to derive the symmetric key.
Compute pwhash = PBKDF2(Password, Salt, N+1) to derive the stored password hash.  (This can be done with only a single extra round on the original hash above.)

Inverting PBKDF2(Password, Salt, N+1) into PBKDF2(Password, Salt, N) is equivalent to inverting HMAC on whatever hash function you use.

The scheme above is the scheme used by Lastpass for authentication vs decrypting your password vault.  (Only pwhash is sent to their server so they cannot recover the key for the password vault from that.)


Building a secure server with CentOs Possible Duplicate:
  Hardening Linux Server

I recently started to manage my own server with a cloud-based server. Recently I got hacked somehow and the server was used for phising. On the server it was installed CentOs, cPanel/WHM and CSF with medium security settings.

After being hacked I realize the need for more security. How can I make a secure server with CentOS?

For maximum security type this command.

# sudo ifdown eth0

But for real.  The answer in this thread is almost exactly what you are looking for.
How do I run a security check on my WordPress server?

edit:  Oh I realized that it was YOU who asked that question...

Firewall rules using iptables.  Only leave open the ports you need.  Block all, allow port 80 for example.
Change default passwords.  If you want to know how a lot of people get hacked...default passwords are a main reason.  Change it to your mysql server, your user accounts, whatever.
Disable services you don't need.  Hell, uninstall them.
Run up to date software.  The reason wordpress will update sometimes is because an old version may have a vulnerability. Make sure your services are all up to date.

If you do this stuff well....you should be pretty secure.


How can I protect my privacy against Facebook tracking my web activity? I was at CryptoParty this year and I heard that Facebook can track user's web activity even after we are logged out. The speaker didn't gave us a solution for protecting our privacy on that matter, so my question here is how can I prevent that?

To my knowledge installing the browser add-on called uBlock Origin (or something similar) would suffice, just remember to properly configure it to (also) include anti-tracking lists.

Aside from anti-tracking, this add-on is generally known to block ads. (Ad providers, to my knowledge, also have a hard-on for tracking people.)

I generally also block addresses related to social media as I don't use any myself (this can be done at router level, firewall level, or as custom rules to uBlock Origin).

It's probably also a good idea to clear cookies after installation to ensure you got rid of tracking cookies (note that this will log you out of pretty much all sites).


Content-type validation in REST APIs I'm trying to wrap my head around, why it is advised to validate the content-type, sent by a client to a REST API.

OWASP states in their REST Security Cheat Sheet:

  When POSTing or PUTting new data, the client will specify the Content-Type (e.g. application/xml or application/json) of the incoming data. The server should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a 406 Not Acceptable response.

They never really state how a missing validation may be exploited. Of course it's better to validate the input, for the data parser's sake, but the header can be faked anyways by an attacker, right?

Why is the content-type validation suggested and how could a missing validation be exploited?

First, the attacker can't always spoof the content type. For example, if your REST API supports a web app that uses cookies to hold session tokens, an attacker may try using CORS (cross-origin XHR) or auto-submitting HTML forms to attack users of your service when the victim visits the attacker's page. If making a cross-site request from the attacker's site (which doesn't have CORS permission for Access-Control-Allow-Header: Content-Type), the attacker can't set the Content-Type header. However, if the application just assumes that the content type is something CORS disallows by default (like JSON) and doesn't verify the header, then an attacker can send a request using one of the non-preflighted / allowed-by-default / allowed-in-forms content types such that it will be accepted by a JSON (or whatever) parser. Of course, ideally you'd have anti-CSRF protections, too, but sometimes people think "I only allow JSON and don't let third-party sites send me JSON, so I'm safe" when in practice they also allow other content types so long as the request body is also valid JSON.

Other times it matters come when doing things like letting a user upload files (always something to do cautiously); if you limit allowed file types, but don't actually verify that uploaded file's type is what it's supposed to be, you could experience a variety of types of problems (depending on what you do with the uploaded files). If you do different things with different file types, you may need to both verify that the user specified a file of one of the allowed types, and that the uploaded file is valid for that type.


Can HTTPS-Everywhere Prevent An SSL-Stripping Attack? If I set HTTPS-Everywhere to block all unencrypted requests, and my connection is man-in-the-middled by a malicious Tor exit node when I connect to a website that, by default, uses HTTPS, then will the extension prevent the site from loading entirely, and thus, prevent my login credentials or other data from being sniffed by the node?

Yes. If HTTPS-Everywhere is set to block all unencrypted requests, your browser will never establish a plain HTTP connection without TLS, no matter what.

How the rest of the networks looks, and where on it the attacker is is irrelevant here. The man in the middle may be a malicious Tor exit node, a hacked router, your ISP, but they will still not be able to downgrade anything to HTTP since your browser will not accept such a connection.


PHP shellcode inside /tmp. Is the server compromised? I have a Debian 7 VPS that runs Nginx, PHP5-FPM and MariaDB. This server runs a couple of WordPress installations, phpMyAdmin and Roundcube Webmail. One is my personal blog running WP 3.9.1 and another runs the latest WP trunk version 4.0-beta1 for development purposes.

I am the only person to have SSH access as well as wp-admin access. Root login via SSH is disabled and so is logging in using passwords.

Today I found the following files inside /tmp.

# ls -l /tmp
total 8
-rw------- 1 www-data www-data 1551 Jul  9 03:22 php9Lg8Js
-rw------- 1 www-data www-data 1551 Jul  9 03:23 phpQNsW36

stat output for the files

# stat /tmp/phpQNsW36
  File: `/tmp/phpQNsW36'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337356      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:23:03.000000000 +0530
Modify: 2014-07-09 03:23:03.000000000 +0530
Change: 2014-07-09 03:23:03.000000000 +0530
 Birth: -

# stat /tmp/php9Lg8Js
  File: `/tmp/php9Lg8Js'
  Size: 1551            Blocks: 8          IO Block: 4096   regular file
Device: ca01h/51713d    Inode: 337355      Links: 1
Access: (0600/-rw-------)  Uid: (   33/www-data)   Gid: (   33/www-data)
Access: 2014-07-09 03:22:27.000000000 +0530
Modify: 2014-07-09 03:22:27.000000000 +0530
Change: 2014-07-09 03:22:27.000000000 +0530
 Birth: -

Both these files contain the same base64 encoded PHP code. I replaced the eval() with print() to find it was a PHP shellcode which emails the HTTP_HOST and REQUEST_URI to two Gmail addresses as well as prints an input box for the exploiter to run shell commands and upload files.

I can post this code here if it required for analysis and if I am allowed to do so.

Searching the Nginx access log based on the timestamp I could only find the following POST requests.

121.97.137.10 - - [09/Jul/2014:03:22:27 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"
121.97.137.10 - - [09/Jul/2014:03:23:03 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"

This server does NOT run Joomla

My understanding is that a BOT was randomly scanning the web for Joomla installations with the JCE exploit. It POSTed some file content and closed the request (Nginx status 499 - Client closed request). This POSTed content ended up with a tmp_name in the /tmp directory as the request did not complete.

Is this correct?

What else should I check to see if this was just a failed attempt or something more than that?

Let me know if more information is required.

Your assessment sounds correct.  It's impossible, of course, to say that your server has not been compromised, but by default, PHP receives all the data before executing the script, so it writes file uploads to /tmp and provides that filename to the running script.

If your /tmp is mounted with atime enabled, the fact that atime==mtime is reassuring.  If the attacker found a way to execute those scripts after their upload (LFI vulnerability, for example), that would change the atime, so the fact that it wasn't updated indicated they weren't executed (again, if atime support is enabled on /tmp).


Using the password hash as a reset token I had this idea, that instead of generating a password reset token and emailing it to the user, I simply email the user's hashed password to them. Then upon reset, the user would submit the old hashed password and the new password in plain text. The server would compare the submitted hashed password and the stored hashed password, and if they match, reset.

This could have some benefits including no expiration time on the reset email and no need to store/expire reset tokens.

What sort of negative security implications would this have?

There's a couple of disadvantages with this scheme:

As other responses have pointed out, this leaks the user's password hash.  This is a problem not because the legitimate user gets it or because anyone with access to the email could own the account (this is true of reset tokens as well) but because it allows an attacker who can read the email to perform a dictionary attack on the hash.  It's likely the user will set their new password to something very similar or have reused the same password on multiple sites.  Leaking hashes is undesirable, even if properly salted & hashed.  Consequently, if the email is ever compromised by an attacker, it has value to the attacker.
Also, as pointed out, this makes it hard to regenerate the token or have it expire.  Password reset tokens should not be good indefinitely in case someone gets access to an old copy of email (e.g., a backup) or has pulled it off the wire but does not use it in a timely fashion.  Your "benefit" of no expiration of the token is actually a drawback from a security point of view.  (And marginally useful from a usability point of view.)
In the reset email, the token is often (always?) placed as a query string parameter.  This means the token (and the users password hash) will be stored in their browser history, and likely in any webserver logs.


SQL Injection via table name? Is it possible to perform SQL injection on a query where the name of the table is passed in as an argument?  The user doesn't enter the table name themselves, but it can be inferred through element IDs.  I am using Microsoft SQL Server 2012 with Coldfusion 10, if that helps.

Example:

  SELECT * FROM [Database].[dbo].[#tableName#]

Could the #tableName# parameter be used to inject malicious code?

Also, could the parameter names be vulnerable to injection as well?

Second example:

  SELECT * FROM [Database].[dbo].[#tableName#] WHERE [#paramName#] = '#paramValue#'

The second example assumes the use of Coldfusion's cfqueryparam for setting the #paramValue#, so the question is more geared towards the use of [#paramName#].

Yes. I'm assuming that you are building your query with string concatenation.

Let's take

SELECT * FROM [Database].[dbo].[#tableName#]

If you replace #tableName# by employee]; DELETE FROM [Database].[dbo].[employee you then obtain 2 queries

SELECT * FROM [Database].[dbo].[employee];
DELETE FROM [Database].[dbo].[employee];

There is only one way to fix SQL Injection : use parametrized queries.


Can viruses transfer from phone to computer over the network? I don't know if this is the right place to ask but I heard that adult websites (porn) had viruses.  I used to look up porn on my iPhone (I won't anymore) and I understand that there aren't viruses for iPhones yet, but if my iPhone gets a virus, can I affect other PCs on my network?

It doesn't really work that way. Any web site can provide active content, and any active content could be "malware". Virus, if you will.

Porn sites are no exception. Of course, reputable ones are less likely to stoop to malware to milk their customers.

One risk involved with an iPhone (or any smartphone) is that the site might try to trick you into subscribing to some service that will cost you money. This is sometimes done with the... well, I'll have to say complicity of the phone operator, which must supply information about your phone number. Then, any click anywhere on the page could potentially be crafted into a "request for premium service subscription", which would go straight on your phone bill.

Once a device is infected, what happens depends on the malware. Some of them actively attempt to replicate throughout the local network, and some of the most sophisticated will actually try establishing a contact to a "virus server" to download suitable code (e.g. if they detect a Mac OS machine on the network, they might try to download a Mac OS exploit, or try leaving an enticingly-named malware suitable for running on Mac OSes somewhere where the Mac's owner might stumble upon: file shares, DropBox folders, public areas...).

A first line of defense is an updated antivirus software. There are free versions too (AVG and Avira, I believe). Browsing with a secure browser (e.g. Firefox or Chrome with NoScript and adblocker plugins) is another good practice. Situational awareness - never click on something you're not sure of, and think before confirming any actions - is a definite plus.

If you're really paranoid there are "virtual secure browsing appliances" that run on VMware or VirtualBox, and allow browsing almost anywhere with a good certainty that whatever virus or infection will be unable to come out of the "sandbox" it's confined to. There are also strategies that essentially recreate the VM each time from a clean copy, and destroy it when you're finished, so that any virus you downloaded would be exceptionally short-lived. In this case, of course, you must be wary of what files you copy from the VM to the outer host machine, and scan them thoroughly with an antivirus.

Actually, if you're really paranoid you should buy DVD porn and watch it on a TV which is incapable of network connections :-) -- keep work documents and porn separated by a physical air gap.


HSTS for android apps? Websites such as Facebook visited on browsers have the HSTS capability which is one more layer of security for TLS from some attacks.

What about, in particular, the Facebook android app?
Does it have HSTS? We already discussed that this app and many more have at least TLS.

In another thread I read that for apps HSTS is not important.

Does the Facebook app use HSTS for Android/iOS? No. It doesn’t need to. HSTS is specific for telling web browsers like Chrome, Firefox, etc. to interact with their web service via HTTPS only.
A mobile app will have HTTPS hard coded in the app itself making it the only option. I believe Apple requires this for any apps and for Android it looks like they are moving towards HTTPS for apps as well. Android HTTPS.
If you are developing an application yourself and want users to only use HTTPS then you would simply call your backend services using only HTTPS and have that coded right into your application whether android or iOS. Example: https://api.example.com/data
The reason why HSTS isn’t needed in the mobile app environment is because in the web browser a user can go to a base url like example.com over HTTP. The user has more control in a web browser environment on how they want to navigate to your website. Also indexing and back linking to your website, people can specify which protocol HTTP or HTTPS when linking to your website. So that’s why you need HSTS in a web browser environment to tell the browser, “only talk to me in HTTPS even if someone says they want HTTP” but in a mobile environment, as a developer you are the one that gets to specify HTTPS in the code in your app for interacting with the backend service. Users don’t need to manually navigate to a url because that is all coded in the app Facebook or you built. The users just have to open the app. So as a developer you get more say on how the app should interact with your web service. It’s your app, your client, you tell it what to do but you didn’t build Chrome or Firefox, it’s someone else’s client so you need to tell them via HSTS how it should interact with your web service.


Hashing standards in DB front end Software Is there any real standard for hashing when working with user passwords in non-web based software development?

I've only really ever handled passwords in Php before, where hashing is a must given the open availability of the web.

In an application that purely acts as a front end to a DB stored locally, with no interaction with the internet (at least not where passwords are concerned), how are passwords stored and handled? Surely they're not stored as plain text as that seems like a terrible idea regardless of how secure systems are. At the moment, the best I've got is storing a Hashed password and a separate Salt in the DB. In my experience even storing the salt separately is bad practice.

I also can't find much documentation when it comes to practices to a non-web based solution. I've had to perform a number of conversions and manipulating the password manually to actually work with the namespace (system.security.cryptography).

Given how not every developer can be expected to care enough to go through the effort, I'd have expected there to be a number of libraries and tools to help make the task as straightforward as possible.

Edit: Just for clarification, I'm looking for how these practices change (if any change) for local applications, and whether or not there is a separate standard to follow for working in a local environment.

(I'm working with C#.NET btw if that changes anything)

The standards would not really change from the web to local storage, with the exception of maybe some of the implementation details.  Hashing is still a defense-in-depth technique to protect in the event of a compromised data store for both situations.   The preference are still:

If you can get away with it, don't store anything.
If you need to store a password, hash with a salt using a Key Derivation Function (KDF)


Hacking Course Value (Soft) The college that I'm currently attending (masters) offers a ethical hacking course, which I am currently enrolled in.  I have been seriously considering dropping the course for several reasons.

1) The course until now has dealt with fluffier topics such as how to think like a hacker etc. and frameworks and specifications for the hacking process.  It seems like it will get a little more hands on later on.

2) I feel like I can get equally good training (in this particular area) from an offensive-security type program rather than one from my university.  It would also be cheaper to go that route.

I was hoping to get rigorous, hands on experience in the field and am assuming that this would be more beneficial than what I am currently getting.  Instead of this course I would probably take a cryptology course a different semester.  My main concentration is going to be Artificial Intelligence and this seems like it would be related.  To be clear, my issue is not learning theoretical information, it's learning theoretical information in a course that I'm assuming is supposed to be hands on.

I guess my questions are:

1)  How beneficial is it to know the fluffier aspects of hacking relative to the hands on aspects?  Is this how the course should be structured?

2) How does it look in the field to get a "hacking" certificate from offensive-security (or something similar) as opposed to a real course in a legitimate university?

3) What areas should I be focusing on in my cybersecurity courses?  Is cryptology useful in the field?  Should I be trying to obtain practical skills or theoretical knowledge (rigorous or otherwise)?

If you have any other thoughts on the situation please let me know.

David,

A warm welcome to you to the exciting world of Information Security.
I am really happy that you have got the right questions. Let me share you my thoughts

"Hands-on aspects" & "Certification"
Theoretical concepts you learn in Academics and the hands on experience by practice will complement each other. They are like two sides of a coin. Understand the concepts in classroom and start practicing step by step.
Setup a mini practice setup in your own machine using Virtual machines. There are lot of Security Distros available like Kali Linux. Also some vulnerable Distros for your practice like Metasploitable. Identify your Distros, install in your machine and start practicing.
Once you are comfortable and gained some experience identify your certification and prepare step by step.
There are a lot of sites which will provide you training videos free of cost. You can do a research in Youtube, Securitytube.net and related sites
Areas in Security
Cyber security is a field with lots of diverse areas. Some of the areas include but not limited to
a. Penetration testing
b. Secure Development
c. Network Monitoring
d. Digital Forensics
e. Incident Handling and Response
f. Testing and Certification
Identify your area of interest and start working towards your goal
Knowledge on standards:
A high level knowledge in various security standards will definitely an added value to your Resume. You can research portals like NIST, US-CERT to get more information.

Finally one fact remains unchanged "Practice makes a man perfect". This holds good for Information Security. Practice well the tools and techniques so that your skills will be enhanced.
All the very best for a successful career in Information Security.


Distributed IMAP-Dictionary-Attack-Tool? I have a client with a hacked IMAP-Account, and the attacker(s) made thousands of password-attempts, probably with a fixed set of passwords, from different IPs before they got in.

After successful password guessing I see 10-15 different IPs connecting and pushing out spams, simply killing that little ol' post-fix server :(. After flushing 440.000 mails from the queue and resetting all passwords to secure ones, Nr 5 lives, again!

My question:

What tool is used for distributed attacks on accounts / spam sending? i know about hydra & consorts, but I never saw a tool for botnet-like brute force. Are sources  available somewhere?

Edit: changed brute-force to dictionary attack

This might give you a little in-site into the process needed to perform this type of thing, http://du.nham.ca/blog/posts/2013/03/08/password-cracking-on-amazon-ec2/  it uses http://hashcat.net/oclhashcat-plus/ along with ec2 to perform circa 2320.9 million MD5 hashes per second, it's maybe not exactly what you looking for but it will certainly give you some pointers.


Bought used computer with working GSM card I recently bought a used computer from a company. They are buying lots of computers from big companies and they refurbish them for resale. Today I discovered that my computer has an installed SIM card. This SIM card is roaming with excellent speed. I know it's bad to use this card, but I wonder: Is it easy to get caught using this connection? Can the card's real owner track my connection and location? Any good way to hide?

Remember, SIM is "subscriber identity module."  It identifies itself to the mobile carrier each time it talks to a cell site, and the carrier knows which cell site.

The best you can hope for is that it will stop working when the original owner gets the next bill.  At worst, you could be tracked down with a cell site simulator (aka "stingray") and charged with theft of services.  There may be consequences in between.


Is possible to deliver a dos attack increasing a database table? If a user through a request can add a record to a table (for each request) is theoretically possible that he could cause a dos attack just increasing the size of a table?

Of course. Depending on how the database is configured to handle growth. The database can grow to fill an entire disk or partition, for instance, and that can crash the database, the service, or the entire server.


Is JavaScript self-injection dangerous? I have a toy web application that can be described roughly as a per-user key-value store. After logging in, the user can view and modify her set of key-value pairs. The keys and values are stored in a database on the server. The keys or values are not shared among users in any way.

I just discovered that JavaScript code included in the keys or values was not properly escaped. So if a user added a key foo with a value of bar <script>alert(1)</script>, the script would execute in the user's browser.

Of course, I fixed this as soon as I noticed it. But I was left wondering: Can this be exploited to do anything harmful? Remember that the key-value pairs are ONLY ever shown to the user who created them.

(The only scenario I could think of is rather far fetched: An attacker convinces the user to navigate to my web application and then to click on a rogue bookmarklet. The bookmarklet saves a key-value pair with a script that steals the user's key-value pairs. Because this is persisted to the database, the key-value pairs will be sent to the attacker every time the user loads the page. But with a rogue bookmarklet you can do almost anything anyway...)

There may be some potential for a CSRF attack, where an attacker maliciously saves a key value pair on behalf of your users.  Then the executable JS in the key value pair might be able to be used for a run of the mill XSS attack to steal their cookies and potentially allow the attacker access to the application as the victim.

I agree with Jimmy's comment.  If there's any possibility to properly scrub the user input, that would definitely be my first priority.


Best practices for loyalty cards (barcode & NFC) I am currently trying to determine the best way to go about designing a system that integrates both barcodes and NFC passes.

The barcodes will be displayed on a phone screen. The barcode (2D, Aztec, as best for phones screens) will contain a 16 digit number which will effectively be a "pass ID", when querying the database you can see the holders name, balance etc. When this barcode is scanned, the merchant will be able to see an image of the account holder associated with the barcode to validate they are the owner. This data is obtained from a offline database (updated every 5 minutes) containing information about each pass. We could change the 16 digit number after each transaction, but as we want the NFC cards to reference the same balance, we haven't done this.

The NFC cards are new territory for me. I am familiar with common "hacks" used in Mifare classic cards, so at minimum we will use Mifare Plus cards. As far as I'm concerned, the NFC card simply needs to inform the NFC reader of its 16 digit number in the same way the barcode does so that the prepaid balance can be updated.

The worry I have with NFC cards is that the content can be cloned/edited which is far easier than it would be to do with the barcode (remember it's on a phone screen, not physical). To cheat with the barcode, you have to make an effort to obtain a visual image of someone else's pass, and even if that does happen we can simply blacklist the pass ID and refund the original owner on a new pass. With NFC I could just swipe my phone over someones pass, see their pass ID, update my pass ID and voila, I'm using their balance.

So in conclusion, I think what I am asking for is a professionals opinion as to whether I am thinking along the right lines. I appreciate I cannot just store a plain-text pass ID on the NFC card an expect no problems. I understand there has to be a form of encryption or way of preventing cloning/editing there. I would just like to know whether the concept I have provided sounds wise from a broad overview.

To be clear, the NFC cards would be optional for those that cannot display a barcode on their smartphone (e.g. the elderly, like a concessionary bus pass), as opposed to customers having both (which they could in theory, but would gain no advantage).

NFC cards can authenticate the reader. Mifare Plus (and Classic as well, but they're broken) can implement ACLs on sectors so that a key must be presented in order to read/write a sector. You can have two different keys per sector, called key A and key B, and a bitfield controls which key can do what and whether unauthenticated access is allowed.

I believe Mifare DESFire can even do crypto on the card itself, so not only is the transport layer encrypted and the reader authenticated, the card merely proves it has the user's secret key without ever disclosing it, where as Plus and Classic are only doing authentication but then behave like dumb  storage devices. Don't quote me on that though, check the datasheets for yourself.

So, if you use Mifare Plus I would recommend setting a key for the sectors holding the sensitive data, and then put there an user ID, a nonce and a MAC. The MAC should be updated each time the card is used so that even if someone manages to copy a card, they won't be able to use it if the legitimate card has been used in the meantime because the nonce would be already used, and they can't make another one because the MAC would no longer be valid.

For QR codes, never use a static code with just the user's ID. Require your mobile app to have a connection to the server, and then when used the app should request a new token from the server and only display that token. It will be one-time use only and have a limited lifetime. This is similar to the card approach above, except since the phone and POS machine don't communicate, there is no way to update the nonce and MAC, so it's better to have the phone just request a new one each time. The only time it would be acceptable to use a static ID is if you require some other method of authentication to actually use the funds from the card.

You can maintain two types of tokens, one for the NFC card and one for the phone. The NFC one would be static (user's ID) but protected by a nonce and MAC, while the phone's one is dynamic. Usage of either type shouldn't affect the other one. Also, the card doesn't even need to be aware of its balance since this is kept on the server anyway. Storing balance on the card would be an unnecessary risk no matter how good the crypto is (remember when people thought Mifare Classic was safe? Imagine the disaster if you had the balance on the card and someone figured out a way to add some hundreds to his balance...)

If you decide to go with the DESFire route and it can actually do on-card crypto, just store the user's ID and a private key on the card. On the server you keep the public key, and each time the card is used the reader should ask the card to sign a random challenge with its key, and the server can then check whether the signature is valid. Since the key is never transmitted and it's pretty much impossible to get it out, this approach is safe. That's similar to how credit cards work by the way. You can even couple this approach with having the card authenticate the reader before talking to it, just like you'd do on the Plus by setting the appropriate sector keys and ACL bits.

Finally you can periodically rotate the sector keys, on each transaction the reader tries every key used in the last X months (the lifetime of the card), and once successfully logged in it updates the card's key to the latest one. That would prevent a rogue employee having extracted the key from the POS software from copying the cards, even though the nonce + MAC would most likely defeat him anyway, but another layer of security is always good. Key rotation should be done regularly but the total number of usable keys has to remain reasonable - this should be calculated based on the maximum lifetime of a card and the acceptable transaction delay. For example, if the lifetime is a year, and you'd rotate the keys every month, the worst case scenario would be that the reader has to try the last 12 keys, which would take about a second. Adjust the values according to your requirements.


How can I caputre the email address from the cookie , when a user visits my website SO I have got a website where visitors just come and see and then they leave, i could monetise on selling only if i would be able to capture there email address, I read couple of sites doing that ie when you visit there site and do not register or give the email address , they still capture it, How do they do that? Any inputs would be highly appreciated

No, you can't capture email address from the cookies. Not unless there is a previous known javascript trick the user enter the email and store it inside the cookies for anyone to retrieve it. (And with a cross domain cookies access rights ) .

HOWEVER, there is another way to steal email exploiting Browser Auto-complete/Auto-fill, by embedding hidden input filed into HTML form.  You can check out this web article for details: Prevent Autofill From Stealing Your Personal Data.

Most Browsers already fix this blind autofill features, Chrome required a mouse click intervention to trigger the auto-fill. Nevertheless, one should not take the patch for granted. So it is a good idea to disable auto-fill or remove crucial personal info in auto-fills.


Security on Ubuntu 12.04 LST Server for Business App I am developing bussines application based on php and mysql on ubuntu 12.04 lts server.
I have closed all ports except :80 and php code can be executed only by security login and not using cookies but session.

What other vulnerability can server have and what security precaution i need to take for hight security???

First of all:

create a user to run your PHP code as who has no more user rights than needed, including being jailed within his user context
configure suphp
get a hardening guide for ubuntu and follow it thoroughly
configure apparmor
limit user access and have a remote logging tool set up
implement auditd for sensitive folders
set up SSL with a valid certificate (443) if your app handles sensitive information

For MySQL preferably you have a table to which you can only add records. Every record has a field "deleted, to which your user mysql application user can have access. This record can be set to True or False. Your user can insert rows but cannot delete any, he can also only update those fields within a record which should be updated. Deleting can be done by setting True or False (your application needs to account for this).

Use as much stored procedures as possible, off-load as much database logic to your database as you can.

Configure a WebApplication firewall and HIDS.


Is this a self rolled hashing/obfuscation method? Can you recognize the pattern? A system we're introducing into the organization is not using any traditional hashing function that I can find. I've been assigned to "approve" it by black-box testing.

I suspect passwords are simply being obfuscated or encrypted (not hashed) since the length of the result changes with password length (though there is some minimum, it seems - perhaps padding?).

Here is some data:

password   : result
1          : TG3432WB7VU=
11         : r8ahLkJGWbY=
111        : E7fXdNqEWAA=
11111111   : FIcx3a00R4eGhFyHjD56qw==
1111111111 : FIcx3a00R4evxqEuQkZZtg==
2111111111 : GPwnH80qEACvxqEuQkZZtg==

The result is obviously base64, but doesn't decode to anything readable. Before I knew that the result's length changed, I tried taking the decoded bytes and treating them as MD5 and other hashing functions, but that obviously didn't pan out. Now that I know the result changes in length, I'm considering other, worse, alternatives. Of note are the two bold parts above: they're identical in two different passwords. So either each 8 bytes are being processed independently (why?) or there's some polyalphabetic substitution going on(?).

Update:

Any character, including Unicode characters, is accepted by the system for passwords. Repeating a 3-byte character 8 times does result in a 24 byte long "hash".

I highly suspect this is a self rolled, or at least very outdated method.  It is very weak by modern standards and should not be used to protect anything important.

Short passwords could be cracked with no more than 2^64 brute force attempts, which is quite possible with even a normal computer.  If both halves of the result are independent, even with fairly long passwords, 2*2^64 brute force attempts could crack it (so 2^65 attempts). There are likely further weaknesses in the algorithm that make it weaker than described here.

Another interesting point to test would be 2111111111 and see if the second part of the result remains the same.  If the second part doesn't change, this is definitely a weak algorithm.

Edit:

Seeing that the results of the 2111111111 test are the same for the second half, this is definitely a weak algorithm and should not be used to protect anything sensitive!  I have included the relevant comparison below:

  1111111111 : FIcx3a00R4evxqEuQkZZtg==
  2111111111 : GPwnH80qEACvxqEuQkZZtg==

Edit:

Another interesting test would be what Ricky Demer suggests below:

  The next thing to check is that it handles the 8-byte blocks identically.  What are the "hashes" of aaaaaaaabbbbbbbbc and bbbbbbbbaaaaaaaac?     – Ricky Demer Feb 25 at 6:44

If it handled the 8-byte blocks identically, it is even worse for even long passwords, no matter what the length.  It would require just 2^64 brute force attempts as pointed out by Neil in the comments. Once someone made a table of what each possibility calculates to, this algorithm would be practically useless.  There are probably even more weaknesses to this algorithm remaining to be discovered.

Bottom line:

I do not recommend using this algorithm regardless of the results of the last test.  We have already seen enough to know it is weak.  Something with a higher bit encryption / hash scheme, salt, long computation time etc... would be much better, and I would recommend going with one of the existing thoroughly tested methods.  Self rolled encryption / hashing has not had the benefit of extensive testing that most of the main stream methods have.


Find out the identity of the person that called you I once heard that if a number that you don't know called you, you can access a website (that I don't remember now) that will call the number and make a recording of what the person said and send it to you. Is it legal? Or can I find a better way to find out the person identity?

Why are you assuming it is a "person" who called you?

Most people will just Google the number - typically if this is one of those spam callers you will find out some information about them on discussion groups.

I am not sure why it would be illegal to search publicly available information about a phone number that called you.


Impact of Mathew Garrett's Secure GRUB Bootloader on UEFI Secure Boot My eyebrows rose with Matthew Garrett announcing his Secure GRUB Bootloader less than three hours after no longer being a Red Hat employee.  This work and its impact on the trust chain design of the UEFI secure boot now being implemented on Windows 8 configured hardware has had me puzzled for the last six months. Can one shim the trust chain without significantly damaging the overall concept of secure boot?

This depends what you mean by “the overall concept of secure boot”.

Pretty much all secure boot systems have several components, starting with one in ROM and ending with an operating system or even programs within that operating system. A typical boot chain is ROM → OEM bootloader → OS bootloader → OS kernel → OS startup programs. A typical secure boot chain has each element of the chain verify the signature of the next element. Each link may involve a different authority to decide which signatures are allowed (the chipset maker, the OEM, the OS vendor, …).

In the case of Matthew Garrett's shim, the path is: … → UEFI → shim → OS bootloader. The shim is signed with a signature that the UEFI BIOS accepts. The code of the shim decides what is allowed at the next stage. The shim is designed so that it allows anyone in physical possession of the device to provide their own signing key for the next stage.

If you think that secure boot is about the owner of the device controlling what the device can run, this is perfectly normal: the end user is in ultimate control of the software that is executed on the device. If you think that secure boot is about the device manufacturer locking the software against modifications by the end user, then allowing someone like Matthew Garrett to participate in the secure boot chain breaks secure boot.

The background is that Microsoft, in part via the UEFI specification, has been pushing for OEMs to activate secure boot on all platforms running Windows 8, allowing only OEM-approved operating systems (with Microsoft having a signing key). On PC-style platforms, Microsoft has signed a shim which allows other operating systems to be loaded, allowing other operating system vendors to provide a secure boot. On ARM platforms shipping with Windows 8, Microsoft has retained the only signing key, locking the user into Microsoft's operating system.


Does PCI ban using MD5 to store sensitive data? Just had a vendor tell me that because their PCI auditors did not recommend banning the use of unsalted MD5 to store sensitive data at this time with with their current level of PCI compliance that they're not going to ban the use of MD5 to store sensitive data.

NOTE: The vendor declined to say if the auditors: (1) discovered the vendor was using MD5 to store sensitive data, but said it was not an issue; (2) did not discover they were doing it, but said using MD5 to store sensitive data was okay; (3) did not discover they were doing it, and not say using MD5 to store sensitive data was okay; (4) if their level of PCI compliance does not require MD5 hashes to not be used to store sensitive data per the PCI Security Standards Council. (5) etc.

Again, all they would say is their PCI auditors did not recommend banning the use of unsalted MD5 to store sensitive data.

Putting aside if banning the use of MD5 to store sensitive data is right or not, what levels of PCI compliance if any ban the use of unsalted-MD5 and/or MD5 to store sensitive data?

Using any hash algorithm to "fuzz" the card is often reversible.

Since there are only a finite quantity of card numbers, remember the last digit maybe a check digit.  Not all the entire card space needs to be checked.  It is well known what the card issuer prefixes are so you perform your searches there.  So now your 16 digit PAN, lost the last digit for check digit and the first 4 to 6 for card issuer.  That is not a lot of combinations to brute force, maybe a single PC with a GPU can do it in a few hours.

So even salted data is useless when you can exhaustively search the entire keyspace with a few clicks and an AWS or evil botnet cluster and get the results back in an hour.  Computers are fast enough to cycle through ALL combinations to find the hash that matches.  The salt is usually known and designed to protect against pre-computation, but that doesn't matter if you can re-compute a complete new data set based on known salt quickly.

So what is important is the exact algorithm used in conjunction with a hash like MD5.

What is the point of using MD5 anyway ?  If you need a token the represent a card number issue it from an independent keyspace.  A sequential counter starting at 000000001 and encrypted with a completely secret key will always grant you a unique output value for the blocksize that is completely unrelated to the card data (and therefore not reversible) without the mapping database being compromised.

If you really need to fuzz the card number look towards PBKDF2 for all usage where you considered a hash.  Since you can bring back the intention of the salt by making it too costly to brute force (even on GPU even on AWS cluster).

Ask your PCI compliance people if you substituted number 0 for A, 1 for B, ... 9 for J, etc... and stored it in the database if this is "strong" enough.

Straight use of MD5 to fuzz card number (even with known salt) can be broken at the rate of 450million/sec on a GPU (from my quick google).  Remember we lost some PAN digits to brute, so we can do 10 digit in 2 seconds.

Sorry if not 100% on topic but use of MD5 to "strongly" secure credit card is a joke in 2013.


TLS certificate - How to assign a CN name for an EC2? AWS console(EC2 dashboard) shows  public DNS name as  ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com for an EC2 instance.

But the same AWS EC2 has a different DNS name (shown below):

$ hostname -f
ip-172-xx-xx-xx.ca-central-1.compute.internal

compared to DNS name shown at AWS console.

EC2 is created in default VPC.

AWS documentation says... When you launch an instance, we allocate a primary private IPv4 address for the instance. Each instance is also given an internal DNS hostname that resolves to the primary private IPv4 address; for example, ip-10-251-50-12.ec2.internal. You can use the internal DNS hostname for communication between instances in the same VPC, but we can't resolve the internal DNS hostname outside of the VPC.

Each instance that receives a public IP address is also given an external DNS hostname; for example, ec2-203-0-113-25.compute-1.amazonaws.com. We resolve an external DNS hostname to the public IP address of the instance from outside its VPC, and to the private IPv4 address of the instance from inside its VPC. The public IP address is mapped to the primary private IP address through network address translation (NAT)

We need to submit CSR to create server certificate for docker daemon running on AWS EC2.

Not sure which one dns name to prefer, hostname -f  or public dns name given in AWS console?

{
   "CN": "somehostname.somepublicdns.com",
   "hosts": [
       "somehostname.somepublicdns.com",
       "99.xx.xx.xx"
    ]
}

hostname -f has different domain compared to DNS name shown in AWS console.

1)
Which DNS name should be assigned to CN attribute? ip-172-xx-xx-xx.ca-central-1.compute.internal or ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com

2)
If CN is ip-172-xx-xx-xx.ca-central-1.compute.internal then , does remote docker client connect with docker daemon after setting export DOCKER_HOST=tcp://ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com DOCKER_TLS_VERIFY=1?

First of all, you should not be using the CN attribute of certificates, but the SubjectAlternativeName attribute (also known as SAN). In fact, the fallback to CN if there's no SAN has been deprecated for some time now in browsers.

Still, your question stands of which hostname to use in the SAN of your certificates. The main question here is which name will you be using to connect to the service, since you should be using the same name in the certificate (and your client should be validating it!).

If you are accessing it as ip-172-xx-xx-xx.ca-central-1.compute.internal, place ip-172-xx-xx-xx.ca-central-1.compute.internal
If you are accessing it as ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com, use  ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com
And if you are accessing it under either of those names, include both in the certificate. The SAN may contain many entries (they are usually capped by the CA, but dozens are easily supported everywhere).

Note that if you are only using the ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com name you may use a publicly trusted CA, whereas if there's any .internal entry, you can't do that, and would need to use your own CA and install that one on the clients.


Legal process for suing joejobber? I'm currently being joejobbed, and want to sue the joejobber. Details:

I have real damages: the joejob causes me to receive fake bounces, which:

stop/delay my receipt of legitimate mail, since Gmail limits how
much mail I can receive in a given period of time.
uses up my time to delete these bounces. Gmail catches many, but
not all, joejob bounces.

I found the joejobber's IP address by looking at the bounces that
include the header information of the message they received. Of
course, not every bounce has this.
Right now, I just need the first step: do I file John Doe suit,
do I subpoena the ISP, do most ISPs have a formal procedure here,
etc.
I realize the joejobber's probably using a botnet of innocent
people's computers, but I'd still like to proceed, since:

I can warn the affected people.
In theory, I could sue the affected people for negligence. I
realize this won't go anywhere, but it'd be nice to explore the
possibility that people have some legal requirement to protect
their computers from being used harmfully by other parties.

EDIT: A joejob is when a spammer sends email spoofing your email
address/domain. Among other things, it results in you getting bounces
for email you never sent. http://en.wikipedia.org/wiki/Joejob

It is extremely improbable that any IP address you retrieve from the header links to the spammer. Almost all spams nowadays go through botnets. Also, remember that message headers are as fake-able than message contents; usually, after careful analysis, you can determine which is the first trustworthy mail host through which the spam went, and possibly that mail host may have added the IP address from which the mail came -- which may be only a gullible open relay.

Therefore, while you can usually have reasonably accurate information on which machine is part of the botnet, you will have a hard time finding proofs which could hold in court. Also, 99% of the time, the infected machine is a home PC and the ISP will not give you any name unless forced by a court order -- which may become tricky since most home PC are from other countries. Chances that an ISP will react on your complaint are nil. As a way to warn innocent owners of infected machines, a lawsuit is about as appropriate as trying to squash mosquitoes with a sledgehammer: even with awesome amounts of luck, results will be miserable and completely disproportionate with the invested efforts; and there is a high risk of backfire.

Theoretically, German law makes owner of open WiFi access points responsible for what goes through, to a limited extent. I have not heard of any actual enforcement of that law yet.


Does PT (Penetration Test) allow rooting a server? When doing a PT, are we allowed to root servers to escalate privileges? I am planning for post exploitation and it necessary to root server for that. So it is better to stop there or go further.

In a Penetration test,you can root a server if you are permitted to do. The question cannot have a generic answer. It can only be specific to a each case.

The Rules of Engagement specify whether or not you can root a server. A few things are considered for this:

Is the server a Production one? If yes, then certainly you should restrain from rooting it.
If its a Test server, you have to be consider whether rooting this server can be directly be used to compromise/sniff/etc any Production servers on same network. If so, then probably you should not root it.
Businesses/Financial  Impact that you may cause by rooting the server and post exploitation steps.
Also, you have to consider the terms/agreements you have agreed to. Sometimes, there can be backlashes from management even if your intentions are good.

If you are not sure, better check with some person responsible for the servers (management).

Ultimately, post-exploitation does not require rooting a server, but is one option for performing the task.


Any solutions out there to counter shoulder surfing? I'm talking about an unknown or undetected physical presence who may be looking over your shoulder as you view or type in sensitive information or passwords.  Most likely to happen when you are supremely focused or using headphones, so not fully aware of your surroundings.  What about a device to warn you, or automatically perform some function on your computer to secure the information being displayed?

Yes. There are 'screen-protectors', or anti-glare protectors. A kind of foil you put on your screen so you can only see your screen in a specific angle (your angle). The other person would have hard times viewing your screen.
NSA-employees are forced to use this.

Also, on most Unix(-like) systems when you put in your password in the terminal, no asterisk-symbols (*) or characters appear. That's for the same reason. Also for screen-capturing.

Snowden also used a blanket which he put over his head and keyboard when typing in passwords, this to protect against hidden cameras.

And people even experimented with filter-foils to make 'secret-screens'. Screens you can only see with special glasses.
https://www.youtube.com/watch?v=zL_HAmWQTgA

But if you really want a device though, you could use a kind of laser alarm system, or beep-alarm when someone passes. You can buy one on Amazon for €/$20 making your own small one.
However, I don't think people would appreciate it if you set this up in your public work office.


Should you remove the user's application PIN if they explicitly log out I am looking for some security driven insight on when to dispose of a mobile application user's PIN in a few scenarios:

Background: When the user downloads and installs the mobile app, they are asked to log in with username and password. After authentication is successful they are prompted to set a PIN for easier access to the app during the session lifetime.

1) The app session expires and the user needs to re-enter their username and password to "restart" the session.

Here I would presume to leave the PIN in place as this was not an action initiated by the user.

2) The user clicks "log out" in the app to kill their session manually.

Here I would presume the PIN should be removed as this was an explicit action by the user.

I understand that this may be viewed as "subjective", but I believe that there should be a best practice around this as this involves defining an average user's intent regarding security.

So you have a setup where the user needs to do full username / password authentication, but as a short-cut you allow them to use a PIN until the session expires.

I would follow the model used by the Keepass2Android client:

When you open the app (equivalent to your new session), you need to do the full authentication process.

While the app remains open, but in the background, you can re-open it using a short-cut -- last 3 characters of your password, fingerprint scanner, etc (equivalent to your PIN, I think).

When you fully close the app, you will need to do the full login next time.

So following that model, I would have them enter one PIN at install, when opening a new session they must re-enter their full credentials, and while the session is open they may use the PIN.

I don't see any difference here between whether the session expired naturally or because they clicked Log Out. I also don't see any reason to ever force them to choose a new PIN; that seems like it's asking for usability problems ("What's my PIN again??") for minor-at-best security benefits.


What could an attacker do on a server where Source Control Management (SCM) files are accessible? I'm testing some servers with OpenVAS and I run into some SCM files that are remotely accessible:

.git/config
.git//info/exclude
.git/description
.git/HEAD that contains refs/heads/master

and

.git/refs/heads/master that contains a hash

I'm new to git and my experience with it is pretty basic. My question is what can an attacker do with the information inside these files and the hash I've found inside .git/refs/heads/master?

For my answer I presume that this is the git repository of the application that the server is running, that it contains the full git repository, and that you are able to download the whole thing.  This is both surprisingly common and surprisingly dangerous.  The git repo contains not just all the code actively deployed on the server, but also every line of code ever written (deployed or not) for the application.  There are a few things to do with that:
Search the Repository for Access Tokens/Api Keys/Database Credentials
A common refrain is that you shouldn't store passwords/keys/credentials in git.  This incident is one big reason why.  When attackers find them it can end very badly..  Finding the git repo publicly available on the website means that it is time to go treasure hunting.  Every key you can find is basically a treasure map, and you never know what you'll find!  There are even tools out there that try to automatically find credentials in git repos for you.
As an example, the best case (for you) scenario is if the database password and host are stored in code.  If the database accepts remote connections and isn't properly firewalled, you may end up easily upgrading yourself to full database access too.
Whitebox Penetration Testing
Whitebox testing can be much more effective than blackbox testing because you have more information to aid in your search.  With full access to the source code, you're basically now a whitebox tester for this site.  You can spend a few hours getting to know the way their application is put together and organized (which is obviously easier if you happen to be familiar with their technology).  From there you have substantially more information available for bug finding.  Of course you don't have infinite amounts of time for reading their code, so I'd start simple.
I would Check their routing tables for very juicy looking endpoints (admin/users, admin/orders, admin/reset_user_password), and check those endpoints for holes in access control that you can exploit.  Similarly, I'd pick some "high impact" pages that I already know about and dive through their source code, looking for any vulnerabilities that might be hard to find while trying to blindly exploit things from the outside.
Social engineering attacks
This one is a bit much for your typical bug bounty scenario, but I thought I'd mention it anyway.  git records not just all code every written, but who wrote it.  It requires both a name and email address to be attached to every commit (although it doesn't check that an actual email address was provided).  This means that you have also gained access to a list of the names and email addresses of everyone who has ever done any programming for this system.  This could lead to many opportunities for more informed social engineering attacks, which increases the odds of success.
Summary
Finding someones git repo is definitely bad and a reportable bug in-and-of itself.  This can also lead to the discovery of even bigger vulnerabilities.  However, like anything else in penetration testing, doing so can still take some effort and isn't guaranteed results.  If they don't keep keys in their repo, if they have good application security overall, then their git repo may not practically benefit you in the slightest.  Of course, allowing the repo to be publicly accessible is a big security blunder in the first place, so I'd be surprised if there aren't more mistakes waiting to be found.
Also, to answer your last question: the hash you found won't help with penetration testing.  git uses hashes as ids for both files and commits.  That is just the hash (aka the id) of the commit which is the HEAD of the active branch.  In other words, that hash just tells git which code is currently "active", since git keeps around the full code history.  It is built from data that is otherwise easily accessible in the git repo in plain-text format.