Leaderboard

Pentru ca acel 0% nu inseamna ca baeria ta este complet goala, ci doar nu mai poate face fata consumului mare de curent(display, gsm, difuzor, etc).Chiar daca telefonul tau e inchis, el tot mai "gandeste" putin.

mergi pe faptu ca echipa lu lucescu are DECAT 13 oameni ( cum zic bucurestenii ) in lot ... nu-i exclus. As merge ca da GOL in prima repriza ( safe bet ) si dortmund - ambele pe acelasi bilet. Eu am zis ca ma opresc din ponturi la 4k vizualizari. ATM lucrez la un site - a carui idee a fost a lui @takko. Will keep you updated.

Code shack describes issue as 'moderate' security flaw, plans to disable risky commands gradually Google's bug-hunting Project Zero team has posted details of an injection vulnerability in GitHub Actions after refusing a request to postpone disclosure. The issue arises due to the ability to set environment variables that are then parsed for execution by GitHub Actions. According to the Project Zero disclosure: "As the runner process parses every line printed to STDOUT looking for workflow commands, every Github action that prints untrusted content as part of its execution is vulnerable. In most cases, the ability to set arbitrary environment variables results in remote code execution as soon as another workflow is executed." The problem was discovered in July and reported to GitHub, which issued an advisory deprecating the vulnerable commands, set-env and add-path. GitHub also posted a description of the issue which means that the information posted by Project Zero, while more detailed and including examples, is not such a big reveal. The security hole was assigned CVE-2020-15228 and rated as medium severity. It's hard to fix, as Project Zero researcher Felix Wilhelm noted: "The way workflow commands are implemented is fundamentally insecure." GitHub's solution is to gradually remove the risky commands. The trade-off is that removing the commands will break workflows that use them, but leaving them in place means the vulnerability remains, so folks will be eased off the functionality over time. The Project Zero timeline indicates some frustration with GitHub's response. Normally bug reports are published 90 days after a report is sent to the vendor, or whenever a problem is fixed, whichever is sooner, though this can be extended. On 12 October Project Zero said it told GitHub "that a grace period is available" if it needed more time to disable the vulnerable commands. The response from GitHub was to request a standard 14-day extension to 2 November. On 30 October, Google noted: "Due to no response and the deadline closing in, Project Zero reaches out to other informal Github contacts. The response is that the issue is considered fixed and that we are clear to go public on 2020-11-02 as planned." The implication of that statement is that the post might have been further delayed, yet when GitHub then requested an additional 48 hours "to notify customers," Project Zero said there was "no option to further extend the deadline as this is day 104 (90 days + 14 day grace extension)." Mark Penny, a security researcher at nCipher Security, said on Twitter: GitHub has not ignored the problem, but rather has taken steps towards eventually disabling the insecure feature and providing users with an alternative, so it is hard to see the benefit in disclosure other than in the general sense of putting pressure on vendors to come up with speedy fixes. November has not started well for GitHub. The second day of the month saw the site broken by an expired SSL certificate. Along with all the Twitter complaints, one user found something to be grateful for: "@github your certificate for the assets is expired today … Thanks for showing us that this can happen to everyone, small and big companies." ® Via theregister.com

Salut, bine ai venit. Pentu inceput ai nevoie sa inveti lucrurile de baza. Sunt multe si le-am enumerat in multe alte posturi: invata cate ceva despre fiecare: programare (HTML, CSS, JavaScript), SQL, un limbaj de programare (e.g. Java, PHP, ASP.NET, C++), networking (TCP/IP), protocoale (DNS, HTTP, SMTP, FTP), putina criptografie, sisteme de operare... Nu te gandi ca trebuie sa devii expert in toate, trebuie doar sa intelegi cum functioneaza. Apoi vei ajunge la partea de dezvoltare de exploit-uri. Avem si cate un tutorial in romana, dar cum zice si Gecko, engleza e de baza. Poti incepe de exemplu cu ceva de genul: https://repo.zenk-security.com/Magazine E-book/Penetration Testing - A hands-on introduction to Hacking.pdf

Atac EMOTET asupra CV19 admin_cv19 November 2, 2020 Securitate Cibernetica 0 EMOTET O Imagine de ansamblu a atacului asupra CV19 Analiză realizată de Alexandru Anghelus si Radu Stanescu Miercuri, 14 octombrie 2020, la 6 zile după prezentarea susținută de CERT RO împreună cu grupul Cyber Volunteers 19 despre securitatea cibernetică a spitalelor din România, am primit pe adresa de mail (contact@cv19.ro) un mesaj aparent inofensiv însă…alertele de securitate au explodat! Semnele de întrebare au apărut în momentul în care am un text legat de o factura emisă în baza… unui contract inexistent. S-a declanșat imediat procedura de Incident Response și am început investigația. Haideți să ”vedem” factura” La deschiderea fișierului putem observa un așa zis mesaj necesar pentru actualizarea sistemului de operare, unul ce ne informează că anumite aplicații au nevoie de update, menționând utilitarul Microsoft Word cu îndemnul de a acorda acces pentru editarea documentului. Putem spune că pentru vizualizarea acestui document era necesar să facem destul de multe operațiuni, deși în mod normal …ar fi trebuit să se deschidă și … atât! Avem de-a face cu un text scris la o scară foarte mică și total de neînțeles, dar dacă îl mărim putem vedea că este un text generat și…fără logică. Articol complet: https://cv19.ro/resurse/securitate-cibernetica/atac-emotet-asupra-cv19/