15 May 2019

Intel CPUs impacted by new Zombieload side-channel attack

Researchers, academics detail new Microarchitectural Data Sampling (MDS) attacks.

By Catalin Cimpanu for Zero Day | May 14, 2019 -- 17:00 GMT (10:00 PDT) | Topic: Security

Academics have discovered a new class of vulnerabilities in Intel processors that can allow attackers to retrieve data being processed inside a CPU.

The leading attack in this new vulnerability class is a security flaw named Zombieload, which is another side-channel attack in the same category as Meltdown, Spectre, and Foreshadow.

Just like the first three, Zombieload is exploited by taking advantage of the speculative execution process, which is an optimization technique that Intel added to its CPUs to improve data processing speeds and performance.


What this means is that malware capable of carrying out a Zombieload attack can effectively break all privacy protections that exist between apps, similar to how both Meltdown and Spectre broke those lines, but via other vulnerabilities in the speculative execution process.

But things aren't as bleak as they were when Meltdown and Spectre were first disclosed in January 2018. For starters, Intel hasn't been caught with its pants down like the last time, and the company has already shipped microcode updates.


01 March 2018

GitHub hit with the largest DDoS attack ever seen

DDoS attackers have found a new way of magnifying their attacks, with experts warning that bigger attacks are likely.

Republished from ZDNet.

GitHub has revealed it was hit with what may be the largest-ever distributed denial of service (DDoS) attack.

The first portion of the attack against the developer platform peaked at 1.35Tbps, and there was a second 400Gbps spike later. This would make it the biggest DDoS attack recorded so far. Until now, the biggest clocked in at around 1.1Tbps.

In a post on its engineering blog, the developer platform said that, on Feb. 28, GitHub.com was unavailable from 17:21 to 17:26 UTC and intermittently unavailable from 17:26 to 17:30 UTC due to the DDoS attack.

Github said that at no point "was the confidentiality or integrity of your data at risk."

"Between 17:21 and 17:30 UTC on February 28th we identified and mitigated a significant volumetric DDoS attack. The attack originated from over a thousand different autonomous systems across tens of thousands of unique endpoints. It was an amplification attack using the memcached-based approach described above that peaked at 1.35Tbps via 126.9 million packets per second," GitHub said.


08 May 2017

Intel chip vulnerability lets hackers easily hijack fleets of PCs

Security researchers say exploiting the vulnerability requires little technical expertise, and can result in a hacker taking full control of an affected PC.

By Zack Whittaker for Zero Day | May 7, 2017 for ZDNet

A vulnerability in Intel chips that went undiscovered for almost a decade allows hackers to remotely gain full control over affected Windows PCs without needing a password.

The "critical"-rated bug, disclosed by Intel last week, lies in a feature of Intel's Active Management Technology (more commonly known as just AMT), which allows IT administrators to remotely carry out maintenance and other tasks on entire fleets of computers as if they were there in person, like software updates and wiping hard drives. AMT also allows the administrator to remotely control the computer's keyboard and mouse, even if the PC is powered off.

To make life easier, AMT was also made available through the web browser -- accessible even when the remote PC is asleep -- that's protected by a password set by the admin.

The problem is that a hacker can enter a blank password and still get into the web console, according to independent technical rundowns of the flaw by two security research labs.


Systems -- including desktops, laptops, and servers -- dating back as early as 2010 and 2011 and running firmware 6.0 and later are affected by the flaw.

But Embedi warned that any affected internet-facing device with open ports 16992 and 16993 are at risk. "Access to ports 16992/16993 are the only requirement to perform a successful attack," said the Embedi researchers.

Since the disclosure, monitors have seen a spike in probing activity on the two affected ports.


The chipmaker has also published a discovery tool to determine if machines are affected.

24 March 2017

Atlassian acquires Trello for $425M

Posted Jan 9, 2017 by Frederic Lardinois (@fredericl)

Source: TechCrunch

Atlassian today announced that it has acquired project management service Trello for $425 million. The vast majority of the transaction is in cash ($360 million), with the remainder being paid out in restricted shares and options. The acquisition is expected to close before March 31, 2017.

This marks Atlassian’s 18th acquisition and, as Atlassian president Jay Simons noted when I talked to him last week, also it largest. Just like with many of Atlassian’s other acquisitions, the company plans to keep both the Trello service and brand alive and current users shouldn’t see any immediate changes.

Trello launched in the TechCrunch Disrupt Battlefield in 2011 and in 2014, it was spun out of Fog Creek Software as a stand-alone company. With Trello, Atlassian is acquiring one of the fastest growing project management services. It now has about 19 million users and just under 100 employees, all of which will join Atlassian.

15 December 2016

WebP: A new image format for the Web

WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster.

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

Lossless WebP supports transparency (also known as alpha channel) at a cost of just 22% additional bytes. For cases when lossy RGB compression is acceptable, lossy WebP also supports transparency, typically providing 3× smaller file sizes compared to PNG.


28 November 2016

GIT: Comparación de metodologías de trabajo

Traducido del documento original en inglés "Comparing Workflows." Traducción por Alejandro Egas e ideaPort LLC con autorización de Atlassian.

La variedad de posibles metodologías de trabajo hace difícil saber por dónde empezar cuando se implementa Git en el lugar de trabajo. Esta página ofrece un punto de partida revisando las metodologías de trabajo más comunes de Git para equipos al interior de empresas.

Mientras lees, ten en cuenta que estas metodologías de trabajo están diseñadas como directrices generales y no como reglas estrictas. Queremos mostrar lo que se puede hacer para que tú tomes, mezcles y acoples aspectos de distintas metodologías de trabajo adecuándolas a tus necesidades individuales.

Metodología de Trabajo Centralizada

La transición a un sistema de control de versiones distribuido puede parecer una tarea de enormes proporciones, pero no es a fuerzas necesario cambiar la metodología de trabajo ya existente para sacar provecho a Git. Tu equipo puede desarrollar sus proyectos tal como lo hace con Subversion.

Sin embargo, el uso de Git en el trabajo de desarrollo evidencia varias ventajas con respecto a SVN. La primera es que cada desarrollador recibe su propia copia local del proyecto completo. Este entorno aislado le permite a cada desarrollador trabajar independiente de todos los demás cambios que se hagan al proyecto. Pueden añadir commits a su repositorio local y olvidarse por completo lo que se esté desarrollando en el resto del proyecto hasta que les resulte conveniente.

La segunda ventaja es que Git da acceso a un robusto modelo de ramas (branchs) y fusión (merging). A diferencia de SVN, las ramas de Git están diseñadas para ser un proceso seguro para la integración de código y para compartir los cambios entre repositorios.

Cómo funciona

Al igual que en Subversion, la metodología de trabajo centralizada utiliza un repositorio central como punto de entrada único para todos los cambios del proyecto. En lugar de trunk, la rama de desarrollo por defecto se llama master, y todos los cambios son agregados como commits a esta rama. Esta metodología de trabajo no requiere de ninguna rama aparte de master.

Para empezar, los desarrolladores deben clonar el repositorio central. Luego, en sus propias copias locales del proyecto, se editan los archivos y se agregan commits tal como se hace en SVN. Sin embargo, estos nuevos cambios son guardados de manera local. Están completamente aislados del repositorio central. Esto le permite a los desarrolladores aplazar la sincronización con upstream hasta que lleguen a un punto conveniente.

Leer más...

Git: Comparing Workflows

Source: Atlassian Git Tutorials. Read it in Spanish: En español.

The array of possible workflows can make it hard to know where to begin when implementing Git in the workplace. This page provides a starting point by surveying the most common Git workflows for enterprise teams.

As you read through, remember that these workflows are designed to be guidelines rather than concrete rules. We want to show you what’s possible, so you can mix and match aspects from different workflows to suit your individual needs.

Centralized Workflow

Transitioning to a distributed version control system may seem like a daunting task, but you don’t have to change your existing workflow to take advantage of Git. Your team can develop projects in the exact same way as they do with Subversion.

However, using Git to power your development workflow presents a few advantages over SVN. First, it gives every developer their own local copy of the entire project. This isolated environment lets each developer work independently of all other changes to a project—they can add commits to their local repository and completely forget about upstream developments until it's convenient for them.

Second, it gives you access to Git’s robust branching and merging model. Unlike SVN, Git branches are designed to be a fail-safe mechanism for integrating code and sharing changes between repositories.

How It Works

Like Subversion, the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.

Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point.